WebAuthn: Issue with Fido metadata?
Mats Luspa
mats.luspa at irf.se
Sun Nov 3 15:04:07 UTC 2024
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> wrote:
>>
>>
>>
>>> On 2 Nov 2024, at 20:19, Mats Luspa <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>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>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>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>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
>>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> todev-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
>>>>>>> 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
>>>>> 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
>> todev-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20241103/6ea9bda5/attachment-0001.htm>
More information about the dev
mailing list