----- Original Message -----
From: "Marek Posolda" <mposolda(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>, "Pedro Igor Silva"
<psilva(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Friday, February 27, 2015 9:22:13 AM
Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
On 27.2.2015 07:09, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Pedro Igor Silva" <psilva(a)redhat.com>
>> To: "Bill Burke" <bburke(a)redhat.com>
>> Cc: keycloak-dev(a)lists.jboss.org
>> Sent: Thursday, February 26, 2015 8:48:43 PM
>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
>>
>> ----- 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: Thursday, February 26, 2015 4:45:02 PM
>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
>>>
>>>
>>>
>>> On 2/26/2015 2:04 PM, Pedro Igor Silva wrote:
>>>> ----- 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: Thursday, February 26, 2015 3:41:21 PM
>>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
>>>>> tokens
>>>>>
>>>>>
>>>>>
>>>>> On 2/26/2015 1:16 PM, Pedro Igor Silva wrote:
>>>>>> ----- 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: Thursday, February 26, 2015 2:09:09 PM
>>>>>>> Subject: Re: [keycloak-dev] apps access to and refresh of
facebook
>>>>>>> tokens
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2/26/2015 11:09 AM, Pedro Igor Silva wrote:
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Bill Burke"
<bburke(a)redhat.com>
>>>>>>>>> To: keycloak-dev(a)lists.jboss.org
>>>>>>>>> Sent: Thursday, February 26, 2015 12:42:19 PM
>>>>>>>>> Subject: [keycloak-dev] apps access to and refresh
of facebook
>>>>>>>>> tokens
>>>>>>>>>
>>>>>>>>> At least for openid connect, I think we hashed this
through on our
>>>>>>>>> dev
>>>>>>>>> call today.
>>>>>>>>>
>>>>>>>>> * There will be a Protocol Claim Mapper that can add
a facebook
>>>>>>>>> token
>>>>>>>>> and expiration claim to the application's access
token.
>>>>>>>> I would create a specific claim set for that instead of
individual
>>>>>>>> claims.
>>>>>>>> Something like:
>>>>>>>>
>>>>>>>> "k_act" : {
>>>>>>>> "identity-provider": {
>>>>>>>> "id" : "facebook",
>>>>>>>> "access_token":
"12312312",
>>>>>>>> "expires": "12312321"
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> (k_act : keycloak authentication context)
>>>>>>>>
>>>>>>>> That way we can use this k_act for exchange information
regarding
>>>>>>>> the
>>>>>>>> authentication context when issuing access tokens or
even id tokens.
>>>>>>>>
>>>>>>> Yeah, token mapping be able to generate any json you want.
>>>>>>>
>>>>>>>>> * the refreshToken endpoint will accept a
"scope" parameter. The
>>>>>>>>> application can then request the refresh of any
external token by
>>>>>>>>> specifying this token in the "scope parameter.
>>>>>>>> I was thinking about adding a refreshToken endpoint to
the identity
>>>>>>>> broker.
>>>>>>>> Isn't better ?
>>>>>>>>
>>>>>>> A different endpoint would require the identity broker to
know if the
>>>>>>> app has permission to request it. Also, with my idea, you
can refresh
>>>>>>> multiple things with one request.
>>>>>>>
>>>>>>> From an application perspective we can provide a
>>>>>>> KeycloakSecurityContext.refreshToken(String... scope)
method, then
>>>>>>> the
>>>>>>> app has one place to request the refresh of one or more
claims.
>>>>>>>
>>>>>>> i.e.
>>>>>>>
>>>>>>> token = context.refreshToken("facebook",
"google");
>>>>>>>
>>>>>>> String facebookToken =
token.getClaim("broker.facebook.token");
>>>>>> I'm still not sure if this is right. Specially when using
scopes for
>>>>>> that.
>>>>>>
>>>>>> Regarding app permissions, know if an app has an identity
provider
>>>>>> enabled
>>>>>> and has access to retrieve its tokens is not enough ?
>>>>>>
>>>>> What does "app has an identity provider enabled" mean
again?
>>>> Currently, you can enable/disable identity providers for each
>>>> application.
>>>> I'm also going to add another option to enable/disable token
retrieval,
>>>> as
>>>> Stian suggested.
>>>>
>>> What does enable/disable entity provider per application mean? A
>>> disabled "facebook" would mean that a "facebook" user
couldn't visit the
>>> app?
>> It means that an application does not supports Facebook login. We just
>> hide
>> the Facebook button from the login page for a particular application.
> As we agreed on the call we need to remove that.
+1, Keycloak is SSO. Even if "application1" doesn't support Facebook
button on login screen, user can still login via Facebook with
"application2" and then go back to "application1", which will
authenticate him automatically due to SSO. So disabling Facebook button
on login screen really doesn't prevent user from login into Keycloak
through Facebook.
I was thinking a little bit more about that.
The user is able to login because his identity was *federated*. So, from a SSO perspective
this is fine even if "application1" does not provide facebook login.
However, only users authenticating in "application2" will be able to *federate*
users from facebook. This might be useful if you want to perform additional logic in
"application2" right after the user is federated. For instance, show a terms
& conditions page, populate an internal database with data from facebook or make
"application2" to act as a portal for other apps.
Marek
>
> We also need to add support to selecting what apps can retrieve the token.
>
>>>>>> And we can also provide a single place to request refresh for
multiple
>>>>>> claims.
>>>>>>
>>>>> Err...that's the same thing I was suggesting. IMO, most apps
won't
>>>>> have
>>>>> to manually do a refresh, they can just rely on the adapter to do
it
>>>>> for
>>>>> them. The way I'm proposing requires no changes to adapter code
and
>>>>> the
>>>>> user can let the adapter refresh things as appropriate.
>>>> Sorry, what I meant is the broker being the single place to refresh
>>>> tokens.
>>>> And not some where else.
>>>>
>>>> How are you going to specify which providers the user wants to
>>>> automatically refresh tokens ? keycloak.json ?
>>> In admin consonle, admin would configure the app to add the facebook
>>> token claim to the JWT access token. When the application invokes
>>> refreshToken, this claim will be updated if needed. It will all be a
>>> callback through the ProtocolMapper SPI I'm creating.
>>>
>>> If the application wants to refresh only one claim, then it would
>>> specify a "scope" with the refreshToken request.
>>>
>>> All this refreshing would happen between one API. Then there is nothing
>>> broker specific for the application, only one URL to refresh everything.
>> Ok.
>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>>
http://bill.burkecentral.com
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev