[keycloak-dev] Identity Broker login flow

[Marek Posolda]

I wonder if we should address this together with reducing number of 
redirects ( https://issues.jboss.org/browse/KEYCLOAK-2098 ) and also 
support for "authentication levels" . We can encapsulate all the state 
of authentication in ClientSession. If someone refreshes the page, we 
will retrieve the ClientSession from the code and the current state of 
execution will be retrieved from ClientSession itself.

ClientSession will also encapsulate all the state of authentication 
after authentication is finished. For example there will be "cookie" if 
ClientSession was authenticated through cookie, "password, otp" if 
clientSession was authenticated through password + otp or 
"broker-facebook" if it was authenticated through Facebook. There will 
be also timestamps of when each successful authentication happened. The 
state will be partially saved in UserSession, so if clientSession was 
authenticated through cookie, it can retrieve from userSession when the 
"real" authentication happened etc.

This will allow us to support periodic re-authentication, authentication 
levels and different requirements for "authentication level" for 
individual application. For example at each SSO login or refresh, we 
will be able to:
- ask user for re-authenticate through OTP every 30 minutes
- ask user for re-authenticate through OTP if he was authenticated 
through Facebook broker
- ask user for re-authenticate through OTP if application required that 
with some magic parameter (AFAIK both OIDC or SAML has some parameters 
for specify authentication levels)

Marek

On 20/11/15 08:41, Marek Posolda wrote:
> You're right, we don't have this right now. I don't know if it's 
> something we should support OOTB. The idea of broker login is, that 
> you delegate authentication to another SSO/social server. Once the 
> second server say "Ok, user is authenticated", we treat him as 
> authenticated on Keycloak side too. Isn't it the more proper option 
> for your usecase to use OTP on the second server side instead?
>
> Another option is to implement IdentityProviderMapper and in 
> "updateBrokeredUser" method, you will redirect user to OTP login. 
> Could you try this?
>
>
> If we want to support another login flow triggered after each broker 
> login (which I am not convinced TBH), we can either:
>
> 1) Introduce "post-broker-login" flow, which will be configurable per 
> IdentityProvider. By default, it will be empty .
>
> 2) Use just one flow, which will be triggered after each broker login 
> (current "first broker login" flow is triggered only if 
> federatedIdentity doesn't yet exist in Keycloak). In this case, the 
> current "first broker login" flow will need to be renamed to "broker 
> login" and more logic will need to be moved from IdentityBrokerService 
> to the flow itself. The disadvantage of this option is, that it may 
> always require another redirect to trigger authentication flows. But 
> we're trying to reduce the number of redirects ( 
> https://issues.jboss.org/browse/KEYCLOAK-2098 )
>
> Marek
>
> On 20/11/15 00:06, Dane Barentine wrote:
>>
>> Hi all,
>>
>> I’m trying to add a custom authenticator and it appears that that 
>> there is no way to insert it in the flow if it’s a brokered IDP login 
>> where the linked Keycloak account already exists.
>>
>> If it’s a local Keycloak user I can use the Browser flow and if it’s 
>> a new brokered user the First Broker Login flow will execute. But I 
>> don’t see a flow that would allow me to insert something like OTP 
>> after a brokered login of an existing user.
>>
>> If I’m just missing it let me know but I think there needs to be some 
>> sort of flow for brokered logins that runs on both existing and new 
>> users. For new users it would run after the First Broker Login flow. 
>> Or better yet maybe a flow that would allow things such as OTP to 
>> happen after any brokered or local login. That way it wouldn’t have 
>> to be configured in multiple flows.
>>
>> Thanks
>>
>> Dane
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151120/c5c8c24e/attachment-0001.html