From: "Iván Perdomo" <ivan(a)akvo.org&gt; To: keycloak-user(a)lists.jboss.org Sent: Wednesday, 24 September, 2014 12:44:30 PM Subject: Re: [keycloak-user] OpenID Connect support Hi again, Just a quick follow up. I would like to know if Keycloack can be used as IDP [1] or the current support is just as RP level? [1] http://openid.net/connect/faq/ Thanks, On Thu, 18 Sep 2014 10:59:29 +0200 Iván Perdomo <ivan(a)akvo.org&gt; wrote: > > Hi all, > > I'm looking for a SSO solution that can help me with the need of > having a single set of user credentials for several applications (Web > and mobile - Android) > > Looking at the list of features in Keycloack I see that there is > support for OpenID Connect. > > I would like to know your opinion if Keycloack could be used for > handling SSO on several applications built on different technology > stacks, e.g. Wordpress [1], Django Web app [2], Android [3], Java > > [1] https://github.com/jumbojett/Wordpress-OpenID-Connect-Login > [2] https://github.com/intelie/django-oidc-auth > [3] https://github.com/learning-layers/android-openid-connect-sample > > > Thanks, > -- Iván _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

I'll do some testing using third-party libs/clients and will share my findings.

Can't really tell, but maybe your library doesn't like the token format we send back? Just looking at the 1st exception in the log... Log a jira and we can look into it. Our queue is pretty full at the moment though.

I thought the issuer was the realm. I guess its not....Also looks like we'll need to have one URL to process all realm oidc requests as the ISS is validated. Does this library offer any encryption/signature options for the ID Token?

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.

Used /account for userinfo end point that didn't work. Will provide more feedback as I continue to test

Fyi -My libraries were tested completely against a server implementation based on Mitre's open Id connect and they are good.

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(a)redhat.com&gt; 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

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(a)redhat.com&gt; 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(a)redhat.com <mailto:bburke@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/>

From: "Iván Perdomo" <ivan(a)akvo.org&gt; To: "Bill Burke" <bburke(a)redhat.com&gt; Cc: keycloak-user(a)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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com > > <mailto:bburke@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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user