lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl (Jira) <>
Subject [jira] [Commented] (SOLR-13734) JWTAuthPlugin to support multiple issuers
Date Tue, 03 Sep 2019 10:11:00 GMT


Jan Høydahl commented on SOLR-13734:

The proposed solution can be exemplified with this {{security.json}} snippet:
  "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"
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:
>             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|] 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message