nifi-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From alopresto <...@git.apache.org>
Subject [GitHub] nifi issue #2047: NIFI-4210: Add support for OpenId Connect
Date Wed, 09 Aug 2017 23:55:35 GMT
Github user alopresto commented on the issue:

    https://github.com/apache/nifi/pull/2047
  
    I continued reviewing with a custom IdP from Auth0. This provider can integrate with other
providers, including Google, Facebook, etc. and also have its own custom users stored locally.
@mcgilman and I were able to receive a success response from Auth0 for a custom user, but
the token signature could not be validated. We traced this to determine that on startup, when
the `TokenValidator` is initialized, if no `nifi.security.user.oidc.preferred.jwsalgorithm`
is present in `nifi.properties`, the first value of `id_token_signing_alg_values_supported`
in the response from the OpenID Connect Discovery Document URI is used. In Auth0's case, this
was `HS256` as opposed to `RS256`, but the tokens returned were signed with `RS256`, resulting
in NiFi returning an error "Unable to exchange authorization for ID token: Unable to parse
the response from the Token request: Signed JWT rejected: Another algorithm expected, or no
matching key(s) found". 
    
    The Auth0 OIDC Discovery Document response:
    
    ```
    {"issuer":"https://apachenifi.auth0.com/","authorization_endpoint":"https://apachenifi.auth0.com/authorize","token_endpoint":"https://apachenifi.auth0.com/oauth/token","userinfo_endpoint":"https://apachenifi.auth0.com/userinfo","mfa_challenge_endpoint":"https://apachenifi.auth0.com/mfa/challenge","jwks_uri":"https://apachenifi.auth0.com/.well-known/jwks.json","registration_endpoint":"https://apachenifi.auth0.com/oidc/register","scopes_supported":["openid","profile","offline_access","name","given_name","family_name","nickname","email","email_verified","picture","created_at","identities","phone","address"],"response_types_supported":["code","token","id_token","code
token","code id_token","token id_token","code token id_token"],"response_modes_supported":["query","fragment","form_post"],"subject_types_supported":["public"],"id_token_signing_alg_values_supported":["HS256","RS256"],"token_endpoint_auth_methods_supported":["client_secret_basic","client_secret_post"],"claims_supported":
 ["aud","auth_time","created_at","email","email_verified","exp","family_name","given_name","iat","identities","iss","name","nickname","phone_number","picture","sub"]}
    ```
    
    We decided to change the initialization logic to default to `RS256` as it is required
by the [OpenID Connect Specification](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata)
to always be present in this response. 
    
    > id_token_signing_alg_values_supported
    > REQUIRED. JSON array containing a list of the JWS signing algorithms (alg values)
supported by the OP for the ID Token to encode the Claims in a JWT [JWT]. **The algorithm
RS256 MUST be included**. The value none MAY be supported, but MUST NOT be used unless the
Response Type used returns no ID Token from the Authorization Endpoint (such as when using
the Authorization Code Flow).
    
    I manually provided `RS256` as a configuration value for `nifi.security.user.oidc.preferred.jwsalgorithm`
in `nifi.properties` and was able to successfully sign in as the user. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message