<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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"><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>
</body>
</html>