[GitHub] [solr-operator] janhoy commented on issue #331: Support JWT authentication

[GitBox <gi...@apache.org>]

janhoy commented on issue #331:
URL: https://github.com/apache/solr-operator/issues/331#issuecomment-931761062


   > the operator could parse out the wellKnownUrl and other config from a security.json provided by the user
   
   Yes, a user provided `security.json` template is probably good to have. Note that the JWTAuthPlugin does not force users to use OIDC, and well-known endpoint, they may supply JWK directly (in which case the `bearerTokenSecret` may be nice to support). Also, there may be a list of several issuers in the same config, each having a different `wellKnownUrl`. The operator needs to care only about the `wellKnownUrl` of the IODC server where the operator itself is added as a client - so it can go fetch a token. We could require an issuer with a `wellKnownUrl`, and if there are multiple, they can be distinguished by  the `name` property.
   
   The [Well-Known endpoint](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationResponse) is an unprotected endpoint that lists all the other endpoints of the OIDC server. So to obtain the Token endpoint you use the `token_endpoint` of the well-known json. To obtain a token from the token endpoint, the operator needs to provide clientID and clientSecret. The token will have an `exp` claim to tell when it expires, which may be used to know when to fetch a new one.
   
   So here's another iteration, adding `issuer` as optional key:
   
   ```yaml
   spec:
     ...
     solrSecurity:
       authenticationType: Bearer
       bootstrapSecurityJson:
         configMap: <user-supplied config map>
         key: <defaults to security.json>
         issuer: <optionally name of issuer to pull wellKnownUrl from, if multiple>
       oidc:
         clientId: <operator client-id as registered with OIDC>
         clientSecret: <name and key of k8s secret where operator's client secret for OIDC is stored>
       bearerTokenSecret: <just a plain secret with a JWT token to use that is already setup by the user>
   ```
   
   I feel perhaps that the operator could help generate `security.json` like it does for BasicAuth, in order to get the permissions and exceptions for metrics and health right - those are complex beasts to hand-craft. Perhaps if `bootstrapSecurityJson` does not have an `authorization` section, it could be added?
   
   Also, what do you think about storing a very simple default `security.json` template that will be used if `bootstrapSecurityJson` is not provided? In that case the `oidc` section needs to have an explicit `wellKnownUrl`.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org