[
https://issues.apache.org/jira/browse/NIFI-14061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17903017#comment-17903017
]
Chris Sampson commented on NIFI-14061:
--------------------------------------
All good points [~exceptionfactory]. My ticket was raised after integrating
NiFi (along with other tools) with [LogTo](https://logto.io) (self-hosted
within a Kubernetes cluster). It presents its {{.well-known}} details with a
single set of domain details, but I know that several of the endpoints used for
the auth mechanism don't actually need to be exposed outside of the cluster
(e.g. /token), while others do (e.g. /auth).
What gave me the idea for this approach was configuring [Elasticsearch for
OIDC](https://www.elastic.co/guide/en/elasticsearch/reference/current/oidc-guide.html),
where it doesn't rely on/use the {{.well-known}} endpoint but instead requires
the RP and OP endpoints to be configured individually.
I'm not aware of any IdP that fits the Oauth2 without OIDC (off the top of my
head) that would need such configuration on the NiFi side currently.
As you suggest, a proxy could be used to modify the {{.well-known}} blob coming
from the IdP before being read by NiFi, albeit that's another component to
manage within such a cluster. Of course, a change could be reequested for the
IdP to allow finer control over the {{.well-known}} contents too. Multiple
possibilities, and different tools unsurprisingly handling things in different
ways.
For my use case, exposing all endpoints via the same domain won't (shouldn't)
be a problem, albeit it's more external network traffic than strictly necessary.
> Allow override of individual OIDC endpoints
> -------------------------------------------
>
> Key: NIFI-14061
> URL: https://issues.apache.org/jira/browse/NIFI-14061
> Project: Apache NiFi
> Issue Type: Improvement
> Affects Versions: 2.0.0
> Reporter: Chris Sampson
> Priority: Minor
>
> NiFi allows for the use of OIDC for User authentication and authorisation.
> This is currently configured via the
> {{nifi.security.user.oidc.discovery.url}} property (amongst others), which
> relies on the OIDC IdP to present its endpoints via the standard
> {{.well-known/oidc-configuration}} endpoint JSON document.
> In many cases, this is sufficient and works. However, in some network setups
> it might be that one can and would prefer to use internal vs. external
> connectivity for some of the OIDC endpoints (e.g. the token, userinfo,
> JWKSet) whereas others need to remain external (e.g. Auth and Session End)
> for the users to be directed to during login/logout.
> The OIDC IdP is (most likely) not able to be configured to communicate this
> via the {{.well-known}} endpoint as most would likely expect the endpoints to
> be accessed via the same domain by default.
> NiFi could allow users to override these endpoints individually, for example
> the {{.well-known}} document could be the default way to obtain the necessary
> OIDC configuration, but then individual endpoints could be overriden by
> additional (optional) {{nifi.properties}} settings.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
