[keycloak-dev] Identity Broker login flow

Bill Burke bburke at redhat.com
Fri Nov 20 10:05:49 EST 2015


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


More information about the keycloak-dev mailing list