[keycloak-dev] Identity Broker login flow
Marek Posolda
mposolda at redhat.com
Mon Nov 23 09:52:40 EST 2015
Created https://issues.jboss.org/browse/KEYCLOAK-2124 with fix version
1.7.0.CR1 for now. For now, I didn't assign to myself, but I hope to
start on it later this week after finish implicit flow.
Marek
On 23/11/15 15:08, Bill Burke wrote:
> We need a full post-IDP flow. Marek just added a flow that if it was
> a new user.
>
> On 11/23/2015 4:03 AM, Stian Thorgersen wrote:
>> We need to support use-cases where OTP is required after login with
>> external IdP. This should be built-in IMO. We should have a easy way to
>> set if OTP is required for a realm or not. Then an option on each IdP to
>> configure if it can skip the OTP requirement or not. Ideally we'd also
>> have an option to check if a user used OTP on the external IdP or not,
>> and require using OTP in Keycloak if not.
>>
>> In the past we had the option of requiring OTP for a realm, but that's
>> now gone and instead we set required on the otp authenticator in the
>> browser flow. However, that's no longer used in brokered logins. This is
>> a regression and needs fixing.
>>
>> On 23 November 2015 at 08:54, Marek Posolda <mposolda at redhat.com
>> <mailto:mposolda at redhat.com>> wrote:
>>
>> On 20/11/15 18:46, Dane Barentine wrote:
>>> I can look at the IdentityProvider Mapper and see. As you said
>>> it's a workaround though and now requires me to create a mapper and
>>> an authenticator to handle both types of authentication.
>>>
>>> Regarding this: "Isn't it the more proper option for your
>>> usecase to use OTP on the second server side instead?"
>>>
>>> In a lot of cases it would probably be more proper. But it's not
>>> always practical as we don't always control the IDPs. So the use
>>> case for OTP is if we are using an IDP that either doesn't support,
>>> or the team that is running it doesn't want to support, something
>>> like OTP but we still want to require it when logging in through
>>> Keycloak. The other use case is when we are making
>>> authentication/authorization decisions based on some other sort risk
>>> assessment or user required action. This may involve using services
>>> or code that we will never be able to plug into an IDP. In those
>>> cases a post broker login flow would allow us to add on a consistent
>>> layer across all the brokered IDPs regardless of what they can
>>> technically support.
>> You can use requiredAction SPI after broker authentication. That is
>> triggered after each authentication (classic or broker) . See some
>> docs here :
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html#d4e3420
>> .
>>
>> Maybe using RequiredAction SPI for OTP authentication is even better
>> than IdentityProviderMapper (even if it's still seems to be a
>> workaround). In your RequiredActionProvider.evaluateTriggers(), you
>> will check that user was authenticated through broker and if yes,
>> you put some requiredAction like "authenticate_otp" to
>> clientSession. Then in requiredActionChallenge() you will redirect
>> to OTP form and in processAction() you will check if OTP was
>> successful. The code in requiredActionChallenge and processAction
>> methods might be very similar to the code in OTPFormAuthenticator.
>> You can likely inspire from here.
>>
>> If you still have issues, feel free to create JIRA and we will try
>> to look at improve things in Keycloak.
>>
>> Regards,
>> Marek
>>> Dane
>>>
>>> -----Original Message-----
>>> From:keycloak-dev-bounces at lists.jboss.org
>>> <mailto:keycloak-dev-bounces at lists.jboss.org>
>>> [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Marek
>>> Posolda
>>> Sent: Friday, November 20, 2015 8:58 AM
>>> To: Bill Burke<bburke at redhat.com>
>>> <mailto:bburke at redhat.com>;keycloak-dev at lists.jboss.org
>>> <mailto:keycloak-dev at lists.jboss.org>
>>> Subject: Re: [keycloak-dev] Identity Broker login flow
>>>
>>> Yes, however the new "First Broker Login" flow I've added is
>>> triggered just when there is no Keycloak user already linked to
>>> IdentityProvider.
>>> In case that there is already some Keycloak user linked to
>>> identityProvider identity, the flow is not executed. Should it be
>>> changed to trigger flow after each broker login? I didn't want to do
>>> that as there were no use-cases (until now) . And always trigger the
>>> flow might require another browser redirect..
>>>
>>> Marek
>>>
>>> On 20/11/15 17:41, Bill Burke wrote:
>>>> 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
>>>>> workarhttps://issues.jboss.org/browse/KEYCLOAK-2124ound 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.
>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-2124
>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> Thanhttps://issues.jboss.org/browse/KEYCLOAK-2124ks
>>>>>>>>>
>>>>>>>>> Dane
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-dev mailing list
>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>> <mailto:keycloak-dev at lists.jboss.org>
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-dev mailing list
>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>> <mailto:keycloak-dev at lists.jboss.org>
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> <mailto:keycloak-dev at lists.jboss.org>
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
More information about the keycloak-dev
mailing list