[keycloak-dev] token exchange

[Stian Thorgersen]

I'm assuming the basic token exchange service comes from the way the CLI
tool works? I.e. you login to the tool then it allows exchanging the token
for a particular CLI client?

Would it not be better to obtain an ID token and use direct grant to obtain
a token for the client using the ID token as the authentication mechanism?

On 1 August 2017 at 19:10, Pedro Igor Silva <psilva at redhat.com> wrote:

> 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
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>