[keycloak-user] OpenID Connect support

Fri Oct 31 11:49:52 EDT 2014

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