[keycloak-user] OpenID Connect support

[Bill Burke]

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> 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

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