<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>However I discovered the known issue that the username (that has
      no passkey) collected in the initial step is possible to alter in
      the authn/Password step. That means that a user with passkey can
      be degraded to username/password authentication.</p>
    <p>I've tested and it works to do that.</p>
    <p>Is it possible to secure that the username in the authn/Password
      step is the same as the username in the initial step? The optimal
      would be to only allow password input in the authn/Password step.</p>
    <p>/Regards Mats</p>
    <div class="moz-cite-prefix">Den 2024-11-01 kl. 14:04, skrev Philip
      Smart:<br>
    </div>
    <blockquote type="cite"
      cite="mid:B4B685A4-398E-46C2-A22D-D904A38380A1@jisc.ac.uk">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      Excellent. 
      <div><br>
      </div>
      <div>Phil<br id="lineBreakAtBeginningOfMessage">
        <div><br>
          <blockquote type="cite">
            <div>On 1 Nov 2024, at 12:01, Mats Luspa
              <a class="moz-txt-link-rfc2396E" href="mailto:mats.luspa@irf.se"><mats.luspa@irf.se></a> wrote:</div>
            <br class="Apple-interchange-newline">
            <div>
              <div>
                <p>Hello!</p>
                <p>Thanks, it works now as I want it to work with this
                  configuration in mfa-authn-config.xml (nearly
                  straightforward from documentation):</p>
                <p><util:map
                  id="shibboleth.authn.MFA.TransitionMap"><br>
                                  <entry key=""><br>
                                          <bean
                  parent="shibboleth.authn.MFA.Transition"
                  p:nextFlowStrategy-ref="checkPasswordOrWebAuthn" /><br>
                                  </entry><br>
                  <br>
                                  <entry key="authn/WebAuthn"><br>
                  <br>
                                          <bean
                  parent="shibboleth.authn.MFA.Transition"><br>
                                                  <property
                  name="nextFlowStrategyMap"><br>
                                                          <map><br>
                                                                 
                  <entry key="NoRegisteredWebAuthnCredentials"
                  value="authn/Password" /><br>
                                                          </map><br>
                                                  </property><br>
                                          </bean><br>
                                  </entry><br>
                  <br>
                          <!-- An implicit final rule will return
                  whatever the final flow returns. --><br>
                  </util:map><br>
                  <br>
                      <bean id="checkPasswordOrWebAuthn"
                  parent="shibboleth.ContextFunctions.Scripted"
                  factory-method="inlineScript"><br>
                          <constructor-arg><br>
                              <value><br>
                              <![CDATA[<br>
                                  nextFlow = "authn/WebAuthn";<br>
                  <br>
                                  // Go straight to second factor if we
                  have to, or set up for an attribute lookup first.<br>
                                  webauthnRegCtx =
input.getSubcontext("net.shibboleth.idp.plugin.authn.webauthn.context.WebAuthnRegistrationContext");<br>
                                  if (webauthnRegCtx != null) {<br>
                                          if
                  (!webauthnRegCtx.isWebAuthnAvailable()){<br>
                                              nextFlow =
                  "authn/Password";<br>
                                          }<br>
                                  } <br>
                                  nextFlow;   // pass control to second
                  factor or end with the first<br>
                              ]]><br>
                              </value><br>
                          </constructor-arg><br>
                      </bean></p>
                <p>and of course NoRegisteredWebAuthnCredentials is
                  configured in authn-events-flow.xml.<br>
                </p>
                <p>Thanks for the advice!</p>
                <p>/Regards Mats<br>
                </p>
                <div class="moz-cite-prefix">On 2024-10-31 12:22, Philip
                  Smart wrote:<br>
                </div>
                <blockquote type="cite"
cite="mid:A299B515-507A-4047-A39E-7B0B884B778F@jisc.ac.uk">
                  <br id="lineBreakAtBeginningOfMessage">
                  <div><br>
                    <blockquote type="cite">
                      <div>On 31 Oct 2024, at 07:58, Mats Luspa <a
                          class="moz-txt-link-rfc2396E"
                          href="mailto:mats.luspa@irf.se"
                          moz-do-not-send="true">
                          <mats.luspa@irf.se></a> wrote:</div>
                      <br class="Apple-interchange-newline">
                      <div>
                        <div>
                          <p>Maybe I should rephrase the question.</p>
                          <p>I wonder if it's possible to use
                            webauthn/MFA always even if the SP is not
                            requiring that?</p>
                        </div>
                      </div>
                    </blockquote>
                    <div>Yes, if that is your only configured
                      authentication flow. </div>
                    <br>
                    <blockquote type="cite">
                      <div>
                        <div>
                          <p>I was thinking this scenario:</p>
                          <p>If the user enters the SP the user gets the
                            webauthn/MFA interface in passwordless flow.
                            Enters the username and if the user does not
                            have any passkey registered the user comes
                            to username/password flow<b> if the SP is
                              not requiring webauthn</b>, otherwise if<b>
                              SP is requiring webauthn the resource is
                              not accessible for the user</b>. If the
                            user has passkey registered the login is
                            proceeding in the usual way for passkey
                            login.</p>
                        </div>
                      </div>
                    </blockquote>
                    <div><br>
                    </div>
                    <div>I see. You should be able to make that switch
                      using the approach I mentioned (linked
                      previously): if no FIDO credentials are
                      registered, signal that to the MFA flow and then
                      switch to the username/password flow. If the SP
                      has signalled it wants MFA (I can not see an SP
                      would specifically request a WebAuthn
                      authentication method), but the user only uses a
                      password, the IdP would not be able to satisfy the
                      request, and so an error will be returned to the
                      SP. If the SP had not requested MFA (or anything),
                      and Password was sufficient, authentication will
                      succeed. You could, of course, allow a fallback to
                      username/password plus some other second factor
                      (TOTP, and Duo are some options in the IdP), which
                      could also satisfy a request for MFA from the SP. </div>
                    <div><br>
                    </div>
                    <div>Noting, you decide if you want to assert
                      WebAuthn authentication as multi-factor. There are
                      some warnings about that on this page: <a
href="https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3878256667/WebAuthnAuthentication#%5BinlineExtension%5DAuthentication-Context-Classes-(Supported-Principals)"
                        moz-do-not-send="true"
                        class="moz-txt-link-freetext">https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3878256667/WebAuthnAuthentication#%5BinlineExtension%5DAuthentication-Context-Classes-(Supported-Principals)</a>.
                      The authentication assurances of ‘passkeys’ are
                      changing all the time, e.g. they can be
                      synchronised between devices and, soon, exported
                      and transferred between providers (Credential
                      Exchange Protocol). Of course, you could restrict
                      users to certain ‘strong’ or trusted
                      authenticators, e.g., hardware security keys—you
                      can do that with the latest release candidate. </div>
                    <div><br>
                    </div>
                    <div><br>
                    </div>
                    <div>Phil</div>
                    <br>
                    <blockquote type="cite">
                      <div>
                        <div>
                          <p>/Regards Mats<br>
                          </p>
                          <div class="moz-cite-prefix">On 2024-10-30
                            10:48, Philip Smart wrote:<br>
                          </div>
                          <blockquote type="cite"
cite="mid:107760A1-7811-4DC4-9C97-84C8E319C4D4@jisc.ac.uk">
                            <br id="lineBreakAtBeginningOfMessage">
                            <div><br>
                              <blockquote type="cite">
                                <div>On 30 Oct 2024, at 09:22, Mats
                                  Luspa via dev <a
                                    class="moz-txt-link-rfc2396E"
                                    href="mailto:dev@shibboleth.net"
                                    moz-do-not-send="true">
                                    <dev@shibboleth.net></a>
                                  wrote:</div>
                                <br class="Apple-interchange-newline">
                                <div>
                                  <div>
                                    <p>Hello again!</p>
                                    <p>Is it possible to configure so
                                      the authentication process falls
                                      back to username/password if a
                                      passkey can't be discovered? Right
                                      now passkey is used only if the SP
                                      requires that. But most of the
                                      SP:s at least here don't require
                                      passkeys and hence
                                      username/password is used. I want
                                      the idp to decide that passkey
                                      should be used if possible
                                      (passkey is discovered).<br>
                                    </p>
                                  </div>
                                </div>
                              </blockquote>
                              <div>I guess this depends on what you mean
                                by ‘discovered’. If you mean; does the
                                user have a passkey registered with the
                                IdP, then there are some options to
                                signal ‘no passkeys’ to the MFA flow
                                during authentication. You can then use
                                MFA logic to decide what to do next. The
                                docs need work, but this should be
                                described in <a
href="https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3878256667/WebAuthnAuthentication#%5BinlineExtension%5DSignalling-custom-events-when-the-user-has-no-registered-credentials"
                                  moz-do-not-send="true"
                                  class="moz-txt-link-freetext">https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3878256667/WebAuthnAuthentication#%5BinlineExtension%5DSignalling-custom-events-when-the-user-has-no-registered-credentials</a>.
                                Please note the warning about enabling
                                that feature (in the yellow box). </div>
                              <div><br>
                              </div>
                              <div>Or maybe you meant something else?</div>
                              <div><br>
                              </div>
                              <div>Phil</div>
                              <br>
                              <blockquote type="cite">
                                <div>
                                  <div>
                                    <p>/Regards Mats<br>
                                    </p>
                                    <div class="moz-cite-prefix">On
                                      2024-10-30 07:24, Mats Luspa via
                                      dev wrote:<br>
                                    </div>
                                    <blockquote type="cite"
cite="mid:6653933c-f518-42be-8fa6-5f532163661e@irf.se">
                                      <p>You are absolutely correct.
                                        irfAuthorizedService is an ldap
                                        attribute not resolved. I have
                                        now made a scripted attribute
                                        that checks if
                                        irfAuthorizedService contains
                                        shibAdmin and it works now.</p>
                                      <p>Thanks for pointing med to the
                                        right direction :)</p>
                                      <p>/Regards Mats<br>
                                      </p>
                                      <div class="moz-cite-prefix">On
                                        2024-10-29 21:35, Michael Grady
                                        via dev wrote:<br>
                                      </div>
                                      <blockquote type="cite"
cite="mid:5DAF7CEE-21EC-4CCF-951A-8B2BDD7F140E@unicon.net">
                                        <br>
                                        <div><br>
                                          <blockquote type="cite">
                                            <div>On Oct 29, 2024, at
                                              2:46 PM, Cantor, Scott via
                                              dev <a
class="moz-txt-link-rfc2396E" href="mailto:dev@shibboleth.net"
                                                moz-do-not-send="true">
<dev@shibboleth.net></a> wrote:</div>
                                            <br
class="Apple-interchange-newline">
                                            <div>
                                              <div>
                                                <blockquote type="cite"
style="font-family: Helvetica; font-size: 20px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
                                                  I think it has to do
                                                  with that
                                                  irfAuthorizedService
                                                  is a multi<br>
                                                  -value attribute.<br>
                                                </blockquote>
                                                <br
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 20px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
                                                <span
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 20px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">It
                                                  doesn't.</span></div>
                                            </div>
                                          </blockquote>
                                        </div>
                                        <div><br>
                                        </div>
                                        Yes the example I supplied (and
                                        that is from a working
                                        deployment), the attribute we
                                        used could have dozens and
                                        dozens of values, so
                                        multi-valued is most definitely
                                        not the issue.
                                        <div><br>
                                          <div>
                                            <div>--<br>
                                              Michael A. Grady<br>
                                              IAM Architect, Unicon,
                                              Inc.</div>
                                            <div><br>
                                            </div>
                                            <br
class="Apple-interchange-newline">
                                          </div>
                                          <br>
                                        </div>
                                        <br>
                                        <fieldset
class="moz-mime-attachment-header"></fieldset>
                                      </blockquote>
                                      <pre class="moz-signature"
                                      cols="72">-- 
--
Mats Luspa
Phone: +46 (0)980 79 022
Cellular phone: +46 (0)725813330
Institutet för rymdfysik               Fax: +46 (0)980 79 050
Swedish Institute of Space Physics      email: <a
class="moz-txt-link-abbreviated moz-txt-link-freetext"
                                      href="mailto:matsl@irf.se"
                                      moz-do-not-send="true">matsl@irf.se</a>
Visiting/Delivery address: Bengt Hultqvists väg 1, SE-981 92 Kiruna
Postal address: Box 812, SE-981 28 Kiruna
--
PGP Public Key: <a class="moz-txt-link-freetext"
href="https://www.irf.se/pgp/matsl" moz-do-not-send="true">https://www.irf.se/pgp/matsl</a>
Digital vcard: <a class="moz-txt-link-freetext"
href="https://www.irf.se/vcard/mats.luspa" moz-do-not-send="true">https://www.irf.se/vcard/mats.luspa</a></pre>
                                      <br>
                                      <fieldset
class="moz-mime-attachment-header"></fieldset>
                                    </blockquote>
                                    <pre class="moz-signature" cols="72">-- 
--
Mats Luspa
Phone: +46 (0)980 79 022
Cellular phone: +46 (0)725813330
Institutet för rymdfysik               Fax: +46 (0)980 79 050
Swedish Institute of Space Physics      email: <a
class="moz-txt-link-abbreviated moz-txt-link-freetext"
                                    href="mailto:matsl@irf.se"
                                    moz-do-not-send="true">matsl@irf.se</a>
Visiting/Delivery address: Bengt Hultqvists väg 1, SE-981 92 Kiruna
Postal address: Box 812, SE-981 28 Kiruna
--
PGP Public Key: <a class="moz-txt-link-freetext"
                                    href="https://www.irf.se/pgp/matsl"
                                    moz-do-not-send="true">https://www.irf.se/pgp/matsl</a>
Digital vcard: <a class="moz-txt-link-freetext"
href="https://www.irf.se/vcard/mats.luspa" moz-do-not-send="true">https://www.irf.se/vcard/mats.luspa</a></pre>
                                  </div>
                                  -- <br>
                                  To unsubscribe from this list send an
                                  email to <a
class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:dev-unsubscribe@shibboleth.net" moz-do-not-send="true">
                                    dev-unsubscribe@shibboleth.net</a><br>
                                </div>
                              </blockquote>
                            </div>
                            <br>
                            <mc type="body"><font size="1"><font
                                  face="Corbel"><br>
                                  <p>Jisc is a registered charity
                                    (number 1149740) and a company
                                    limited by guarantee which is
                                    registered in England under company
                                    number. 05747339, VAT number GB 197
                                    0632 86. Jisc’s registered office
                                    is: 4 Portwall Lane, Bristol, BS1
                                    6NB. T 0203 697 5800.<br>
                                    <br>
                                  </p>
                                  <p>Jisc Services Limited is a wholly
                                    owned Jisc subsidiary and a company
                                    limited by guarantee which is
                                    registered in England under company
                                    number 02881024, VAT number GB 197
                                    0632 86. The registered office is: 4
                                    Portwall Lane, Bristol, BS1 6NB. T
                                    0203 697 5800.<br>
                                    <br>
                                  </p>
                                  <p>Jisc Commercial Limited is a wholly
                                    owned Jisc subsidiary and a company
                                    limited by shares which is
                                    registered in England under company
                                    number 09316933, VAT number GB 197
                                    0632 86. The registered office is: 4
                                    Portwall Lane, Bristol, BS1 6NB. T
                                    0203 697 5800.<br>
                                    <br>
                                  </p>
                                  <p>For more details on how Jisc
                                    handles your data see our privacy
                                    notice here: <a
                                      class="moz-txt-link-freetext"
href="https://www.jisc.ac.uk/website/privacy-notice"
                                      moz-do-not-send="true">
https://www.jisc.ac.uk/website/privacy-notice</a></p>
                                </font></font></mc></blockquote>
                          <pre class="moz-signature" cols="72">-- 
--
Mats Luspa
Phone: +46 (0)980 79 022
Cellular phone: +46 (0)725813330
Institutet för rymdfysik               Fax: +46 (0)980 79 050
Swedish Institute of Space Physics      email: <a
class="moz-txt-link-abbreviated moz-txt-link-freetext"
                          href="mailto:matsl@irf.se"
                          moz-do-not-send="true">matsl@irf.se</a>
Visiting/Delivery address: Bengt Hultqvists väg 1, SE-981 92 Kiruna
Postal address: Box 812, SE-981 28 Kiruna
--
PGP Public Key: <a class="moz-txt-link-freetext"
                          href="https://www.irf.se/pgp/matsl"
                          moz-do-not-send="true">https://www.irf.se/pgp/matsl</a>
Digital vcard: <a class="moz-txt-link-freetext"
                          href="https://www.irf.se/vcard/mats.luspa"
                          moz-do-not-send="true">https://www.irf.se/vcard/mats.luspa</a></pre>
                        </div>
                      </div>
                    </blockquote>
                  </div>
                  <br>
                </blockquote>
                <pre class="moz-signature" cols="72">-- 
--
Mats Luspa
Phone: +46 (0)980 79 022
Cellular phone: +46 (0)725813330
Institutet för rymdfysik               Fax: +46 (0)980 79 050
Swedish Institute of Space Physics      email: <a
                class="moz-txt-link-abbreviated moz-txt-link-freetext"
                href="mailto:matsl@irf.se" moz-do-not-send="true">matsl@irf.se</a>
Visiting/Delivery address: Bengt Hultqvists väg 1, SE-981 92 Kiruna
Postal address: Box 812, SE-981 28 Kiruna
--
PGP Public Key: <a class="moz-txt-link-freetext"
                href="https://www.irf.se/pgp/matsl"
                moz-do-not-send="true">https://www.irf.se/pgp/matsl</a>
Digital vcard: <a class="moz-txt-link-freetext"
                href="https://www.irf.se/vcard/mats.luspa"
                moz-do-not-send="true">https://www.irf.se/vcard/mats.luspa</a></pre>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
  </body>
</html>