[keycloak-dev] Release status

[Bill Burke]

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

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com