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-unsubscr...@solr.apache.org

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



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

Reply via email to