----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Friday, February 20, 2015 1:50:41 PM
Subject: Re: [keycloak-dev] Claims Mapping and Identity Federation
On 2/20/2015 10:46 AM, Pedro Igor Silva wrote:
> Regarding what you said about claims, going to think on what you said
> during the weekend. Get back to you on Monday :)
>
> I'm glad that you are already considering making internal code more
> flexible so we can deal with access tokens, id tokens, saml assertions or
> whatever is issued by KC prior to return them to service providers. This
> is also one of the things in my requirements list.
>
I'm a bit nervous about this as we end up having to expose the entire
SAML document model to users. I don't see any way around it though.
There are so many esoteric SAML features that we won't be able to
support due to time constraints, yet I want to be able to allow users to
apply their own extensions to support them.
Don't be. Only in extreme cases users should deal with that. Most of things we can
support in OOTB fashion.
And yes, that would bring a lot more flexibility, with a cost. IMO we just need to
highlight the consequences to users as they can end up introducing security gaps if they
don't know exactly what they are doing.
> Some comments in line.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: keycloak-dev(a)lists.jboss.org
>> Sent: Friday, February 20, 2015 1:36:31 PM
>> Subject: Re: [keycloak-dev] Claims Mapping and Identity Federation
>
> What about the ID token. I think this guy is the most important in this
> context.
>
AccessToken extends ID Token. ID Token is created from the access token.
Yeah, but at the end they are different tokens. Exposed separately to clients. That is why
I asked. But I understood what you meant.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com