[keycloak-dev] Release status
bburke at redhat.com
Wed Apr 1 10:42:28 EDT 2015
Also, a bunch of things about this Token Exchange service bug me making
me think we shouldn't expose it at this time.
* External tokens shouldn't be stored in user storage. While social
tokens are often long living, brokered tokens aren't. They should
instead be stored in the UserSession.
* The current implementation of this service stores the entire
SAMLREsponse document for SAML, and the entire AccessTokenResponse for
OIDC. Probably not the most user friendly or greatest idea.
* OIDC has two tokens. IDToken and Access token. Both might be needed
by client app or user.
On 4/1/2015 10:32 AM, Bill Burke wrote:
> On 4/1/2015 10:29 AM, Stian Thorgersen wrote:
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, 1 April, 2015 4:22:42 PM
>>> Subject: Re: [keycloak-dev] Release status
>>> No, I don't. I"ll look into it after I finish this one thing.
>>> Probably should be implemented differently anyways. Token exchange
>>> service should be an application with a role that can be assigned to
>>> user or applied via a protocol mapper.
>> Yes, token exchange service as app and role sounds much better. That would let you control what users (role-mapping) and apps (scope) that are allowed to access it. Would also work with existing grant features if an "oauth client" request access. Shame we don't have time to change it now, as it'll probably be a bit of work?!
> Can't be done by tomorrow. Should I just disable the identity provider
> tab until we do this? Or are users asking for access to external tokens?
JBoss, a division of Red Hat
More information about the keycloak-dev