[keycloak-dev] token exchange

[Bill Burke]

On 7/31/17 12:18 PM, Bill Burke wrote:
>
>
>
> On 7/31/17 11:35 AM, Pedro Igor Silva wrote:
>> On Fri, Jul 28, 2017 at 5:24 PM, Bill Burke <bburke at redhat.com 
>> <mailto:bburke at redhat.com>> wrote:
>>
>>     I've implemented a simple token exchange API [1] that allows you to
>>     exchange an access token created for one client to another
>>     client.  The
>>     REST API follows the oauth token exchange api [2] very loosely.
>>
>>     subject_token: a keycloak access token
>>
>>     audience: takes a client id
>>
>>     It then converts the access token created for one client and
>>     converts it
>>     to another.  It lives under the token endpoint.
>>
>>     The security model is as follows:
>>
>>     * Authenticate calling client the same way as password grant.
>>
>>     * The calling client must have service account enabled
>>
>>     * Service account must have a realm role "token-exchanger" grant
>>     edto it
>>     or, it must have a client role "token-exchanger" granted to it.  This
>>     exchanger client role is a role defined by the target client you are
>>     exchanging the token to.
>>
>>
>>     Is this a good security model?  I'm thinking of not creating
>>     these roles
>>     right now and to enable support for exchange would require
>>     defining the
>>     roles specified above.
>>
>>
>> I think roles are too coarse-grained to represent this kind of 
>> policy. A better option would be to explicitly define the clients 
>> that are allowed to exchange tokens for a particular resource server. 
>> Eg.:
>>
>> RS A allows Client B, C and D to exchange their tokens where the 
>> target audience is RS A (or if using "resource", a specific resource 
>> in RS A).
>
> I changed it a little.  actors are:
>
> * Authenticated client asking for change
> * Clients that are the audience of the token being exchanged
> * Client you want the token to be exchanged to
>
> So, the authenticated client must be in the audience of the token 
> being exchanged, or, have permission to exchange from that particular 
> audience.  The authenticated client also must have permission to 
> exchange to the audience it wants to exchange to.
>
Good idea to change it to use the fine grain admin permissions. There's 
a couple of issues/problems with doing this that I think are easily done:

* public clients can't have service accounts.
* Client Policy looks at kc_client_id attribute which is pulled from the 
issuedFor claim in the token.  This isn't correct as we permission 
checks based on the authenticated client, not the token.

So I'll have to create a new Identity type that either wraps the service 
account or ClientModel and sets the "kc_client_id" property.

Bill