[keycloak-user] OpenID Connect support

[Bill Burke]

realm name by itself is a valid URL, its just not a url with a scheme.

On 10/31/2014 8:41 AM, prab rrrr wrote:
> Read the spec once again and agree to your point that access code can
> only be used once. Regarding "iss", as long as realm name is replaced by
> URL, it should be good. I will do some more testing today, mostly on
> validating the signature of the token and will let you know if I find
> any discrepancies.
>
> Thanks once again, for the response and explanation.
>
>
> On Thursday, October 30, 2014 8:53 PM, Bill Burke <bburke at redhat.com> wrote:
>
>
> Section 3 does mention that the issuer is a URL using HTTPS, but this
> URL does not have to match the token endpoint URL.  It is just a unique
> identifier for the issuer.  That's it.
>
> Maybe I'm just not understanding OIDC, but what you are describing for
> "aud" and "azp" doesn't make sense to me.  An ID Token is not an access
> token.  Its not something you pass around to use for authz.  Neither do
> you pass around access codes.  Access codes are only usable once.
>
> Keycloak just doesn't support multiple audiences.  When an oauth client
> is registered, a set of valid redirect uri patterns are associated with
> it.  You cannot associate a client with another client.  The ID Token
> will only ever contain one client_id in the "aud" and the "azp" will
> always be blank because its an optional setting.
>
> We support narrowed "trust" by role scope mappings.  When an access
> token is created for a specific client, it is only granted permissions
> that are configured for that client's scope.  For example:
>
> * Service 'A' has roles of "user" and "admin"
> * Service 'B' has roles of "admin" and "analyst"
> * User has a role mapping of A.user, A.admin, B.admin, B.analyst
> * Oauth client "C" is registered with a role scope mapping of A.user
> * Oauth client 'C' initiates a token request on behalf of the User, it
> gets an access token only with a permission of 'A.user' even though the
> user has other permissions. So it wouldn't be able to access Service 'B'
> at all.
>
>
>
> On 10/30/2014 6:42 PM, Raghuram wrote:
>  > Hi Bill -  here is my understanding  of the spec:
>  >
>  > Section 3.1.3.7 of the core spec says that clients must validate the
> id tokens. The third point of the same section says that "aud" can
> contain more than 1 element in which case the fourth point says that the
> client should verify that "azp" is present and the fifth point says azp
> should be verified against the client id
>  >
>  > Now when an oauth client registers, it can specify multiple redirect
> Uris, corresponding to diff oauth clients that wish to participate in a
> single sign on. When a user tries to access first client and he is
> authenticated, the client just gets a code. If the code is passed to the
> second client ( the first client could be web app and the second client
> could be a database service) then the second client could get an
> Idtoken. The auth server (key cloak in this case) would then list all
> the client ids in "aud" and specify the second client in "azp" which
> will be validated by the second client.
>  >
>  > The above is a valid use case in our organization ( authentication
> delegation). It gives flexibility to the apps ( especially sensitive
> ones) to pick the apps they trust rather than just participate in an
> organization wide single sign on.
>  >
>  > Section 3 (openID provider metadata) of the discovery spec mentions
> that issuer is a url using https.
>  >
>  > Hope I make sense.
>  >
>  > Thanks.
>  > Sent from my iPhone
>  >
>  >> On Oct 30, 2014, at 4:58 PM, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>  >>
>  >> Ivan, btw, looking at the library you are using, validation of the
> ID token is optional.
>  >>
>  >>> On 10/30/2014 4:15 PM, Raghuram wrote:
>  >>> I tested with libraries based on Apache Oltu and even I noticed
> that realm name is being sent in the Idtoken under "iss". "aud" is null
> when I included multiple redirect Uris which is breaking the validation
> (as per openid spec). "azp" is not being sent (it is optional unless
> more than 1 client is registered) - expect that to be sent once I
> register two clients.
>  >> "aud" has been fixed in master.
>  >>
>  >> "iss" still is the realm name.  This is just a unique identifier for
> the realm.  And there is nothing in the spec that I could find that
> states that it must match the token endpoint URL.  It just has to be a
> URL that uniquely identifies the issuer.  It is something that is
> configured, or, found during OIDC discovery.
>  >>
>  >> "AZP
>  >> Your interpretation of AZP is not my interpretation of AZP.  #1.
> AZP is optional, we don't have to include it at all.  #2 It would only
> have the value of the client that requested the token.  In Keycloak, ID
> Tokens are generated and only given to one audience.
>  >>
>  >>
>  >>> Used /account for userinfo end point that didn't work. Will provide
> more feedback as I continue to test
>  >>
>  >> As I said before, we do not support userinfo yet.  Our access tokens
> are Json Web Signatures signed by the realm and the content is an
> extended version of ID Tokens that contains additional keycloak metadata.
>  >>
>  >>> Fyi -My libraries were tested completely against a server
> implementation based on Mitre's open Id connect and they are good.
>  >>
>  >> It's on the roadmap to expand our OIDC support beyond the minimal
> requirements and to validate it against other implementations.  Just
> haven't gotten to it yet.
>  >>
>  >>
>  >> --
>  >> Bill Burke
>  >> JBoss, a division of Red Hat
>  >> http://bill.burkecentral.com <http://bill.burkecentral.com/>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com <http://bill.burkecentral.com/>
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com