[keycloak-dev] token exchange

[Pedro Igor Silva]

On Mon, Jul 31, 2017 at 1:54 PM, Bill Burke <bburke at redhat.com> wrote:

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

Our policy evaluation engine is based on the claims within the token. The
"issueFor" is basically the "azp" claim from OIDC. In fact, we don't even
need that "kc_client_id". We could make this configurable though, and let
users decide whether they want to check the "authenticated client" or "azp"
?

Btw, I'm about to finish UMA Grant Type, one of the changes I'm doing for
UMA 2.0. My changes will conflict with yours. Are you going to merge your
changes soon ?

Another thing I noticed is that maybe we could have a SPI for custom grant
types. What you did and what I'm doing may justify a specific SPI for
plugging custom grant types. Maybe too much, but maybe a nice to have.


>
>
> Bill
>