<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 23/11/15 10:03, Stian Thorgersen
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAJgngAcAiUfODgAQsB738yr8Fhc25ubrryHJOfSQimq2Ven8nQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">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.</div>
    </blockquote>
    Personally I wouldn't hardcode any OTP related options directly to
    IdentityProviders. Users may want something else than OTP (For
    example require Facebook users to reauthenticate with SMS etc). The
    configurable post-login flow per identity provider is more flexible.
    It also allows to support all the usecases above (If
    identityProvider itself used OTP, you can use empty post-login flow
    and not require users to authenticate through OTP again. Otherwise
    use flow with OTP required).<br>
    <blockquote
cite="mid:CAJgngAcAiUfODgAQsB738yr8Fhc25ubrryHJOfSQimq2Ven8nQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>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.</div>
      </div>
    </blockquote>
    Just checked how it worked in 1.2.0 when I was testing migration of
    something else... When OTP was in requiredCredentials for realm,
    then after first Facebook login we required user to setup OTP.
    However in all next Facebook logins of this user, we didn't require
    OTP login. So it's not regression. Despite first login required
    action, it was always like: broker OR (password AND otp).<br>
    <br>
    <br>
    Marek<br>
    <blockquote
cite="mid:CAJgngAcAiUfODgAQsB738yr8Fhc25ubrryHJOfSQimq2Ven8nQ@mail.gmail.com"
      type="cite">
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On 23 November 2015 at 08:54, Marek
          Posolda <span dir="ltr">&lt;<a moz-do-not-send="true"
              href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div text="#000000" bgcolor="#FFFFFF"><span class="">
                <div>On 20/11/15 18:46, Dane Barentine wrote:<br>
                </div>
                <blockquote type="cite">
                  <pre>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.</pre>
                </blockquote>
              </span> You can use requiredAction SPI after broker
              authentication. That is triggered after each
              authentication (classic or broker) . See some docs here :
              <a moz-do-not-send="true"
href="http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html#d4e3420"
                target="_blank">http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html#d4e3420</a>
              . <br>
              <br>
              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 <span
                style="background-color:#e4e4ff">requiredActionChallenge()

                you will redirect to OTP form and in </span>processAction<span
                style="background-color:#e4e4ff"></span>() you will
              check if OTP was successful. The code in
              requiredActionChallenge and processAction methods might be
              very similar to the code in <span
                style="background-color:#e4e4ff">OTPFormAuthenticator.
                You can likely inspire from here.<br>
                <br>
                If you still have issues, feel free to create JIRA and
                we will try to look at improve things in Keycloak.<br>
                <br>
                Regards,<br>
                Marek<br>
              </span>
              <div>
                <div class="h5">
                  <blockquote type="cite">
                    <pre>Dane

-----Original Message-----
From: <a moz-do-not-send="true" href="mailto:keycloak-dev-bounces@lists.jboss.org" target="_blank">keycloak-dev-bounces@lists.jboss.org</a> [<a moz-do-not-send="true" href="mailto:keycloak-dev-bounces@lists.jboss.org" target="_blank">mailto:keycloak-dev-bounces@lists.jboss.org</a>] On Behalf Of Marek Posolda
Sent: Friday, November 20, 2015 8:58 AM
To: Bill Burke <a moz-do-not-send="true" href="mailto:bburke@redhat.com" target="_blank">&lt;bburke@redhat.com&gt;</a>; <a moz-do-not-send="true" href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
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:
</pre>
                    <blockquote type="cite">
                      <pre>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:
</pre>
                      <blockquote type="cite">
                        <pre>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:
</pre>
                        <blockquote type="cite">
                          <pre>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:
</pre>
                          <blockquote type="cite">
                            <pre>I wonder if we should address this together with reducing number of 
redirects ( <a moz-do-not-send="true" href="https://issues.jboss.org/browse/KEYCLOAK-2098" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-2098</a> ) 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:
</pre>
                            <blockquote type="cite">
                              <pre>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 (
<a moz-do-not-send="true" href="https://issues.jboss.org/browse/KEYCLOAK-2098" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-2098</a> )

Marek

On 20/11/15 00:06, Dane Barentine wrote:
</pre>
                              <blockquote type="cite">
                                <pre>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
<a moz-do-not-send="true" href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a>
</pre>
                              </blockquote>
                              <pre>_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a>
</pre>
                            </blockquote>
                            <pre>_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a>

</pre>
                          </blockquote>
                        </blockquote>
                      </blockquote>
                    </blockquote>
                    <pre>_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a>
</pre>
                  </blockquote>
                  <br>
                </div>
              </div>
            </div>
            <br>
            _______________________________________________<br>
            keycloak-dev mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
            <a moz-do-not-send="true"
              href="https://lists.jboss.org/mailman/listinfo/keycloak-dev"
              rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>