[
https://issues.apache.org/jira/browse/SOLR-13734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16921302#comment-16921302
]
Jan Høydahl commented on SOLR-13734:
------------------------------------
The proposed solution can be exemplified with this {{security.json}} snippet:
{code:javascript}
{
"authentication": {
"class": "solr.JWTAuthPlugin",
"wellKnownUrl": "https://idp1/.well-known/openid-configuration";,
"aud": "https://solr-cluster/";,
"scope": "solr:read solr:write solr:admin",
"issuers": {
"idp2": {
"wellKnownUrl": "https://idp2/.well-known/openid-configuration";,
"iss": "https://idp2/";,
"jwkUrl": ["https://idp2/jwk-endpoint";,
"https://other.domain/jwk-endpoint";]
},
"idp3": {
"wellKnownUrl": "https://idp3/.well-known/openid-configuration";
}
}
}
}
{code}
The new parameter is the *{{issuers}}* key which can take a dictionary of JSON
objects, each representing an additional issuer (IdP). Each issuer
configuration will support a small subset of the existing configuration options:
* {{wellKnownUrl}} - discovery endpoint. This will often be the only parameter
needed since the plugin will resolve JWK, 'iss' etc from it.
* {{iss}} - to explicitly configure issuer id for this issuer. This is
different from the name given in the "issuers" dictionary.
* {{jwkUrl}} - to explicitly configure JWKS endpoint(s) supported by this
issuer
All other settings, such as timeout values, scopes etc, will be configured as
before, and the 'primary' issuer must still be configured with top-level
properties as today.
The reasoning behind a named dictionary instead of an array for the new
'issuers' property is to be able to address each issuer for later removal or
modification using REST API. Such REST api support for multiple issuers will
also be deferred to future JIRAs.
When a request comes in for authentication, the plugin will follow this flow:
# When validating the 'iss' claim of the JWT, pass if it matches one of the
configured issuers (today must match main 'iss')
# When validating the signature of the JWT, use an extended
{{JwksVerificationKeyResolver}} with the following logic
## Select an issuer based on the 'iss' string from the JWT header of the
incoming token
## Validate the JWT using the (cached) JWKs of that issuer
> JWTAuthPlugin to support multiple issuers
> -----------------------------------------
>
> Key: SOLR-13734
> URL: https://issues.apache.org/jira/browse/SOLR-13734
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
> Reporter: Jan Høydahl
> Assignee: Jan Høydahl
> Priority: Major
> Labels: JWT, authentication
>
> In some large enterprise environments, there is more than one [Identity
> Provider|https://en.wikipedia.org/wiki/Identity_provider] to issue tokens for
> users. The equivalent example from the public internet is logging in to a
> website and choose between multiple pre-defined IdPs (such as Google, GitHub,
> Facebook etc) in the Oauth2/OIDC flow.
> In the enterprise the IdPs could be public ones but most likely they will be
> private IdPs in various networks inside the enterprise. Users will interact
> with a search application, e.g. one providing enterprise wide search, and
> will authenticate with one out of several IdPs depending on their local
> affiliation. The search app will then request an access token (JWT) for the
> user and issue requests to Solr using that token.
> The JWT plugin currently supports exactly one IdP. This JIRA will extend
> support for multiple IdPs for access token validation only. To limit the
> scope of this Jira, Admin UI login must still happen to the "primary" IdP.
> Supporting multiple IdPs for Admin UI login can be done in followup issues.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
