[keycloak-dev] Identity Broker login flow

[Bill Burke]

Oh, I thought our broker flows happened after the user logged into the 
external IDP?

On 11/20/2015 11:18 AM, Marek Posolda wrote:
> 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
>>>
>

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