[keycloak-dev] Federated Identity and Authentication Broker

[Bill Burke]

On 12/5/2014 9:15 AM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Friday, December 5, 2014 12:07:37 PM
>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
>>
>>
>>
>> ----- Original Message -----
>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Friday, 5 December, 2014 2:57:46 PM
>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
>>>
>>> ----- Original Message -----
>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Friday, December 5, 2014 11:43:32 AM
>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>> Sent: Friday, 5 December, 2014 2:36:14 PM
>>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
>>>>> Broker
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>> Sent: Friday, December 5, 2014 10:59:08 AM
>>>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication
>>>>>> Broker
>>>>>>
>>>>>> Another related thing. We've had a few people ask to be able to login
>>>>>> to
>>>>>> Keycloak on mobiles using the native social login mechanism.
>>>>>>
>>>>>> I think the best way to do that is to use the direct grant api and
>>>>>> make
>>>>>> it
>>>>>> possible to call that endpoint passing a IdP id and a token instead
>>>>>> of
>>>>>> username and password.
>>>>>>
>>>>>> WDYT?
>>>>>
>>>>> The broker endpoint expects the idp id in order to start the
>>>>> authentication
>>>>> process. Today, the endpoint also expects KCs authorization code in
>>>>> order
>>>>> to
>>>>> validate requests from clients and use it as a state to validate
>>>>> responses
>>>>> from the trusted idps.
>>>>>
>>>>> This authorization code is a blocker for this use case, given that
>>>>> mobile
>>>>> don't have this code and just want to start the authentication.
>>>>>
>>>>> A possible solution would be to change the broker to also accept a
>>>>> client_id
>>>>> to reference the mobile app and perform some validations based on that.
>>>>> Something like that:
>>>>>
>>>>> 1) Mobile displays a Facebook button
>>>>> 2) User clicks the button and mobile sends a request to KC Broker with
>>>>> the
>>>>> idp id and his client_id.
>>>>> 3) KC Broker checks if the client_id is valid and creates a temporary
>>>>> authorization code.
>>>>> 4) KC Broker redirect mobile to the chosen IdP to perform
>>>>> authentication.
>>>>> 5) KC Broker receives a response from the IdP, generate its own token
>>>>> and
>>>>> send it back to mobile
>>>>>
>>>>> Makes sense ?
>>>>
>>>> No that's not the flow I had in mind. Basically the mobile app
>>>> authenticates
>>>> with Facebook through the native mechanisms. The app then has an access
>>>> token, which it would send to Keycloak on the direct grant api to obtain
>>>> a
>>>> Keycloak token.
>>>
>>> Ahh, now I get what you mean :)
>>>
>>> Yes, what you said is enough. Then we just need to validate the access
>>> token
>>> (eg.: using a tokeninfo endpoint).
>>>
>>> But I think we can also consider that use case I mentioned. You may want to
>>> login without forcing the user to redirect to KC login page.
>>
>> We could just add a query param to the login url that lets you pick the IdP
>> to use by alias?
>>
>>    For example auth/.../login?client_id=...&auth_method=google
>
> Yes, just like my previously example, we need the client_id. The idp id/alias is already there.
>
> Btw, regarding SAML. SAML does not provide a "validation" endpoint like oAuth2/OpenID providers usually provide. AFAIK, there is nothing on the specs for that. What can be done here is validate SAML assertions against a WS-Trust STS. Or just trust the assertion based on the signature and others standards info along it.
>
> We can also take a closer look at the oAuth2 SAML bearer token profile and see if it helps.
>

We can discuss this next week, but I've said before SAML should be 
delegated to an "interoperability/portability" protocol and used only 
with clients that can't install an adapter and don't want to use our 
HTTP security proxy.  We should focus on extensions to OIDC only.  It 
makes no sense to add our own extensions to both SAML and OIDC.

Same goes with bearer token formats.  We put our extensions into JWT.


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