[keycloak-user] OpenID Connect support

Mon Nov 3 03:27:00 EST 2014

+1 To changing iss to https://<KEYCLOAK-SERVER>/auth/realms/<REALM-NAME>

Realm name isn't very unique (for example all KC servers comes with a master realm by default), but a URL would be. Should also be a relatively easy fix to make adapters use the last bit of iss as the realm name.

----- Original Message -----
> From: "Iván Perdomo" <ivan at akvo.org>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-user at lists.jboss.org
> Sent: Friday, 31 October, 2014 4:49:52 PM
> Subject: Re: [keycloak-user] OpenID Connect support
> 
> 
> Wouldn't just using the
> https://<KEYCLOAK-SERVER>/auth/realms/<REALM-NAME> a way to meet the
> specification but also enable the multi-tenant behavior in Keycloak ?
> 
> Just an idea
> 
> On Fri, 31 Oct 2014 11:41:34 -0400
> Bill Burke <bburke at redhat.com> wrote:
> 
> > 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/>
> > >
> > >
> > 
> 
> 
> 
> --
> Iván
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user