11:18 a.m.
On 7/31/17 11:35 AM, Pedro Igor Silva wrote:
On Fri, Jul 28, 2017 at 5:24 PM, Bill Burke <bburke(a)redhat.com
<mailto:bburke@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.
Future work would be to have an additional subject_issuer and
requested_issuer parameters. "subject_issuer" would match to a broker
alias, so you could exchange a facebook token for a keycloak realm
token. Same thing goes for "requested_issuer". This would allow
you to
exchange a Keycloak token for a facebook token or some other
registered
broker.
I'm following your discussion in OAuth2 WG. Do we really need these
additional paramerters ?
My understanding from the specs is that:
* Facebook -> Keycloak Realm
If you pass a "subject_token_type" like
"urn:keycloak:params:oauth:token-type:broker-{ALIAS}", where {ALIAS}
is the alias of the broker configured to your realm. Assuming {ALIAS}
maps to a Facebook broker in your realm, you probably know how to
exchange the FB opaque access token to a Keycloak realm token.
* Keycloak -> Facebook
If you pass a "requested_token_type" like
"urn:keycloak:params:oauth:token-type:broker-{ALIAS}", where
{ALIAS} is the alias of the broker configured to your realm. Assuming
{ALIAS} maps to a Facebook broker in your realm, you probably know how
to exchange the Keycloak token to a FB token.
Or are you thinking about something else ?
I'm conversing with WG to get this new parameter included in the
specification. types and issuers shouldn't be mixed IMO. Especially
when you could standardize oauth to oauth cross-domain exchange pretty
easily if you had these new parameters where otherwise you'd be
dependent on the STS's proprietary type definitions. The spec is way
too vague for cross-domain exchange.
Bill