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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>

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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >

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.ht... . 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(a)lists.jboss.org [mailto:keycloak-dev-bounces@lists.jboss.org <keycloak-dev-bounces(a)lists.jboss.org>] On Behalf Of Marek Posolda Sent: Friday, November 20, 2015 8:58 AM To: Bill Burke <bburke(a)redhat.com&gt; <bburke(a)redhat.com>; keycloak-dev(a)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 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 listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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(a)redhat.com > <mailto:mposolda@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.ht... > . > > 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@lists.jboss.org >> <mailto:keycloak-dev-bounces@lists.jboss.org> >> [mailto:keycloak-dev-bounces@lists.jboss.org] On Behalf Of Marek >> Posolda >> Sent: Friday, November 20, 2015 8:58 AM >> To: Bill Burke&lt;bburke(a)redhat.com&gt; >> <mailto:bburke@redhat.com>;keycloak-dev@lists.jboss.org >> <mailto:keycloak-dev@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(a)lists.jboss.org >>>>>>>> <mailto:keycloak-dev@lists.jboss.org> >>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>> _______________________________________________ >>>>>>> keycloak-dev mailing list >>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>> <mailto:keycloak-dev@lists.jboss.org> >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev(a)lists.jboss.org >>>>>> <mailto:keycloak-dev@lists.jboss.org> >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >

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.ht... . 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.