<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hello again!</p>
    <p>Maybe I don't quite understand. Isn't the activateCondition
      implemented on the idp side? The condition I use is that if the
      user has a passkey then the authn/Password can not be used (i.e.
      not downgrading). That check is done on the idp side as I
      understand. If the SP requires MFA and gets only authn/Password
      (if the user hasn't a passkey) then the request will be rejected
      anyway. Am I correct?</p>
    <p>/Regards Mats<br>
    </p>
    <div class="moz-cite-prefix">On 2024-11-03 19:13, Mats Luspa via dev
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:5d569af4-327d-4f5b-879f-f5788a7b72d7@irf.se">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <p>Ok, understand. I remove it.</p>
      <p>/Regards Mats<br>
      </p>
      <div class="moz-cite-prefix">Den 2024-11-03 kl. 17:33, skrev
        Philip Smart:<br>
      </div>
      <blockquote type="cite"
        cite="mid:3CC176E6-9422-42C4-AE87-9C488BB9F93F@jisc.ac.uk">
        <meta http-equiv="Content-Type"
          content="text/html; charset=UTF-8">
        Quick note: orchestrating it in this way, if you do ‘downgrade',
        it would no longer satisfy an MFA request (or similar) from the
        SP. 
        <div><br>
        </div>
        <div>Phil</div>
        <div><br>
          <blockquote type="cite">
            <div>On 3 Nov 2024, at 15:04, 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>Yes, you are correct. In the registration process it
                  works but not in the authentication flow where you for
                  those without passkeys registrated go to
                  authn/Password. <br>
                </p>
                <p>I tested with activationCondition (activate
                  authn/Password only if no passkey is regsistrated)
                  according to below configuration but it didn't work
                  that either.</p>
                <p><bean id="authn/Password"
                  parent="shibboleth.AuthenticationFlow"<br>
                                 
                  p:passiveAuthenticationSupported="true"<br>
                                  p:forcedAuthenticationSupported="true"<br>
                                 
                  p:activationCondition-ref="checkWebAuthnAvailability"/></p>
                <p><br>
                </p>
                <p><bean id="checkWebAuthnAvailability"
                  parent="shibboleth.Conditions.Scripted"
                  factory-method="inlineScript"><br>
                                      <constructor-arg><br>
                                                      <value><br>
                                                        <![CDATA[<br>
                                                                var
                  webauthnRegCtx =
                  profileRequestContext.getSubcontext(WebAuthnRegistrationContext.class);<br>
                                                                var
                  result = webauthnRegCtx == null ||
                  !webauthnRegCtx.isWebAuthnAvailable();<br>
                                                                result;<br>
                                                                ]]><br>
                                                                     
                  </value></p>
                <p>                       </constructor-arg></p>
                <p> </bean></p>
                <p>Ok, I wait.</p>
                <p>/Regards Mats<br>
                </p>
                <div class="moz-cite-prefix">Den 2024-11-03 kl. 10:41,
                  skrev Philip Smart:<br>
                </div>
                <blockquote type="cite"
cite="mid:3A5AE902-82C6-4E77-91A9-8BFD5CE1D85E@jisc.ac.uk"> <br
                    id="lineBreakAtBeginningOfMessage">
                  <div><br>
                    <blockquote type="cite">
                      <div>On 3 Nov 2024, at 09:35, Philip Smart 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
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; 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;">
                          <br class="Apple-interchange-newline">
                          <br>
                          <blockquote type="cite">
                            <div>On 2 Nov 2024, at 20:19, Mats Luspa
                              <<a href="mailto:mats.luspa@irf.se"
                                moz-do-not-send="true"
                                class="moz-txt-link-freetext">mats.luspa@irf.se</a>>
                              wrote:</div>
                            <br class="Apple-interchange-newline">
                            <div>
                              <div>
                                <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>
                              </div>
                            </div>
                          </blockquote>
                          <div>Yes, this should be covered by the
                            ‘AccessByCurrentUser’ policy as shown in <a
href="https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3879206915/WebAuthnRegistration#%5BinlineExtension%5DAccessPolicy-Configuration"
                              moz-do-not-send="true"
                              class="moz-txt-link-freetext">https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3879206915/WebAuthnRegistration#%5BinlineExtension%5DAccessPolicy-Configuration</a>.
                            Let me know if that is not working (it is
                            working for me), as that is pretty
                            fundamental. </div>
                        </div>
                      </div>
                    </blockquote>
                    <div><br>
                    </div>
                    Sorry, I might have answered this too quickly. I
                    guess you mean in the authentication flow, not for
                    registration. Yeah, this is why there is a warning
                    about that. I will get back to you next week.,</div>
                  <div><br>
                  </div>
                  <div>Phil</div>
                </blockquote>
              </div>
            </div>
          </blockquote>
        </div>
      </blockquote>
      <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" href="mailto:matsl@irf.se">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">https://www.irf.se/pgp/matsl</a>
Digital vcard: <a class="moz-txt-link-freetext" href="https://www.irf.se/vcard/mats.luspa">https://www.irf.se/vcard/mats.luspa</a></pre>
  </body>
</html>