On 12/5/2014 9:15 AM, Pedro Igor Silva wrote:
----- Original Message -----
> From: "Stian Thorgersen" <stian(a)redhat.com>
> To: "Pedro Igor Silva" <psilva(a)redhat.com>
> Cc: keycloak-dev(a)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(a)redhat.com>
>> To: "Stian Thorgersen" <stian(a)redhat.com>
>> Cc: keycloak-dev(a)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(a)redhat.com>
>>> To: "Pedro Igor Silva" <psilva(a)redhat.com>
>>> Cc: keycloak-dev(a)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(a)redhat.com>
>>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>>> Cc: keycloak-dev(a)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(a)redhat.com>
>>>>> To: "Pedro Igor Silva" <psilva(a)redhat.com>
>>>>> Cc: keycloak-dev(a)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