WebAuthn: Issue with Fido metadata?

Philip Smart Philip.Smart at jisc.ac.uk
Sun Nov 3 16:33:12 UTC 2024


Quick note: orchestrating it in this way, if you do ‘downgrade', it would no longer satisfy an MFA request (or similar) from the SP.

Phil

On 3 Nov 2024, at 15:04, Mats Luspa <mats.luspa at irf.se> wrote:


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.

I tested with activationCondition (activate authn/Password only if no passkey is regsistrated) according to below configuration but it didn't work that either.

<bean id="authn/Password" parent="shibboleth.AuthenticationFlow"
                p:passiveAuthenticationSupported="true"
                p:forcedAuthenticationSupported="true"
                p:activationCondition-ref="checkWebAuthnAvailability"/>


<bean id="checkWebAuthnAvailability" parent="shibboleth.Conditions.Scripted" factory-method="inlineScript">
                    <constructor-arg>
                                    <value>
                                                        <![CDATA[
                                                                var webauthnRegCtx = profileRequestContext.getSubcontext(WebAuthnRegistrationContext.class);
                                                                var result = webauthnRegCtx == null || !webauthnRegCtx.isWebAuthnAvailable();
                                                                result;
                                                                ]]>
                                                    </value>

                       </constructor-arg>

 </bean>

Ok, I wait.

/Regards Mats

Den 2024-11-03 kl. 10:41, skrev Philip Smart:


On 3 Nov 2024, at 09:35, Philip Smart via dev <dev at shibboleth.net><mailto:dev at shibboleth.net> wrote:



On 2 Nov 2024, at 20:19, Mats Luspa <mats.luspa at irf.se<mailto:mats.luspa at irf.se>> wrote:


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.

I've tested and it works to do that.

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.

Yes, this should be covered by the ‘AccessByCurrentUser’ policy as shown in https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3879206915/WebAuthnRegistration#%5BinlineExtension%5DAccessPolicy-Configuration. Let me know if that is not working (it is working for me), as that is pretty fundamental.

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

Phil

Phil


/Regards Mats

Den 2024-11-01 kl. 14:04, skrev Philip Smart:
Excellent.

Phil

On 1 Nov 2024, at 12:01, Mats Luspa <mats.luspa at irf.se><mailto:mats.luspa at irf.se> wrote:


Hello!

Thanks, it works now as I want it to work with this configuration in mfa-authn-config.xml (nearly straightforward from documentation):

<util:map id="shibboleth.authn.MFA.TransitionMap">
                <entry key="">
                        <bean parent="shibboleth.authn.MFA.Transition" p:nextFlowStrategy-ref="checkPasswordOrWebAuthn" />
                </entry>

                <entry key="authn/WebAuthn">

                        <bean parent="shibboleth.authn.MFA.Transition">
                                <property name="nextFlowStrategyMap">
                                        <map>
                                                <entry key="NoRegisteredWebAuthnCredentials" value="authn/Password" />
                                        </map>
                                </property>
                        </bean>
                </entry>

        <!-- An implicit final rule will return whatever the final flow returns. -->
</util:map>

    <bean id="checkPasswordOrWebAuthn" parent="shibboleth.ContextFunctions.Scripted" factory-method="inlineScript">
        <constructor-arg>
            <value>
            <![CDATA[
                nextFlow = "authn/WebAuthn";

                // Go straight to second factor if we have to, or set up for an attribute lookup first.
                webauthnRegCtx = input.getSubcontext("net.shibboleth.idp.plugin.authn.webauthn.context.WebAuthnRegistrationContext");
                if (webauthnRegCtx != null) {
                        if (!webauthnRegCtx.isWebAuthnAvailable()){
                            nextFlow = "authn/Password";
                        }
                }
                nextFlow;   // pass control to second factor or end with the first
            ]]>
            </value>
        </constructor-arg>
    </bean>

and of course NoRegisteredWebAuthnCredentials is configured in authn-events-flow.xml.

Thanks for the advice!

/Regards Mats

On 2024-10-31 12:22, Philip Smart wrote:


On 31 Oct 2024, at 07:58, Mats Luspa <mats.luspa at irf.se><mailto:mats.luspa at irf.se> wrote:


Maybe I should rephrase the question.

I wonder if it's possible to use webauthn/MFA always even if the SP is not requiring that?

Yes, if that is your only configured authentication flow.


I was thinking this scenario:

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 if the SP is not requiring webauthn, otherwise if SP is requiring webauthn the resource is not accessible for the user. If the user has passkey registered the login is proceeding in the usual way for passkey login.

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.

Noting, you decide if you want to assert WebAuthn authentication as multi-factor. There are some warnings about that on this page: https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3878256667/WebAuthnAuthentication#%5BinlineExtension%5DAuthentication-Context-Classes-(Supported-Principals). 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.


Phil


/Regards Mats

On 2024-10-30 10:48, Philip Smart wrote:


On 30 Oct 2024, at 09:22, Mats Luspa via dev <dev at shibboleth.net><mailto:dev at shibboleth.net> wrote:


Hello again!

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

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 https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/3878256667/WebAuthnAuthentication#%5BinlineExtension%5DSignalling-custom-events-when-the-user-has-no-registered-credentials. Please note the warning about enabling that feature (in the yellow box).

Or maybe you meant something else?

Phil


/Regards Mats

On 2024-10-30 07:24, Mats Luspa via dev wrote:

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.

Thanks for pointing med to the right direction :)

/Regards Mats

On 2024-10-29 21:35, Michael Grady via dev wrote:


On Oct 29, 2024, at 2:46 PM, Cantor, Scott via dev <dev at shibboleth.net><mailto:dev at shibboleth.net> wrote:

I think it has to do with that irfAuthorizedService is a multi
-value attribute.

It doesn't.

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.

--
Michael A. Grady
IAM Architect, Unicon, Inc.






--
--
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: matsl at irf.se<mailto:matsl at irf.se>
Visiting/Delivery address: Bengt Hultqvists väg 1, SE-981 92 Kiruna
Postal address: Box 812, SE-981 28 Kiruna
--
PGP Public Key: https://www.irf.se/pgp/matsl
Digital vcard: https://www.irf.se/vcard/mats.luspa



--
--
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: matsl at irf.se<mailto:matsl at irf.se>
Visiting/Delivery address: Bengt Hultqvists väg 1, SE-981 92 Kiruna
Postal address: Box 812, SE-981 28 Kiruna
--
PGP Public Key: https://www.irf.se/pgp/matsl
Digital vcard: https://www.irf.se/vcard/mats.luspa

--
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net<mailto:dev-unsubscribe at shibboleth.net>



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.


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.


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.


For more details on how Jisc handles your data see our privacy notice here: https://www.jisc.ac.uk/website/privacy-notice

--
--
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: matsl at irf.se<mailto:matsl at irf.se>
Visiting/Delivery address: Bengt Hultqvists väg 1, SE-981 92 Kiruna
Postal address: Box 812, SE-981 28 Kiruna
--
PGP Public Key: https://www.irf.se/pgp/matsl
Digital vcard: https://www.irf.se/vcard/mats.luspa


--
--
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: matsl at irf.se<mailto:matsl at irf.se>
Visiting/Delivery address: Bengt Hultqvists väg 1, SE-981 92 Kiruna
Postal address: Box 812, SE-981 28 Kiruna
--
PGP Public Key: https://www.irf.se/pgp/matsl
Digital vcard: https://www.irf.se/vcard/mats.luspa


--
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net<mailto:dev-unsubscribe at shibboleth.net>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20241103/6925ce59/attachment-0001.htm>


More information about the dev mailing list