[keycloak-dev] Identity Broker login flow

[Marek Posolda]

Yep. I know :-\

As usually, the most proper solution requires most of the changes and 
refactoring...

For this particular case, I wonder if Dane can use the approach with 
implement IdentityProviderMapper to redirect to OTP login. This is 
workaround though (IdentityProviderMapper is likely not designed for the 
usecases like this), however I think it should work. This won't require 
any changes in existing Keycloak code.

I can introduce "post-broker-login" flow, but not sure if it's something 
we should support OOTB. I don't know if it's useful for more people. So 
I would rather skip adding post-broker-login as "authentication levels" 
will be more proper and more generic solution IMO.

Marek


On 20/11/15 16:05, Bill Burke wrote:
> All something we want to do, but do we have time?  Very soon we need to
> start focusing on cleaning up the APIs/SPIs, documentation, improving
> UI, performance, and the tons of minor problems people are experiencing.
>
> On 11/20/2015 3:45 AM, Marek Posolda wrote:
>> 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
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>