[keycloak-dev] Release status

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 1 April, 2015 4:42:28 PM
> Subject: Re: [keycloak-dev] Release status
> 
> Also, a bunch of things about this Token Exchange service bug me making
> me think we shouldn't expose it at this time.

Agree there's some kinks we should work out, so let's hide the "store tokens" option for an identity provider as well as the identity provider tab under applications.

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

Brokered tokens can be long living, for example offline tokens which we should add support for in KC. As I've said before there's two use-cases for brokering one is authentication the other is access. For access you quite likely want an offline token to permanently get access to an external service after linking the account.

However, offline tokens will most likely be the exception not the rule, so I agree we should store most tokens in user-session, but also have the ability to store offline tokens in user storage (or another permanent store). By the way for a user session it would only make sense to store a single token, which is the token used to authenticate with, but when you're linking an account you may want to store an offline token.

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