WebAuthn: Issue with Fido metadata?

[Philip Smart]

> On 5 Nov 2024, at 06:41, Mats Luspa via dev <dev at shibboleth.net> wrote:
>
> It sounds logical.
>
> I, as said, want a user to always use passkey when the user has a passkey registrated and not be able to use authn/Password.
>
> But there is a problem when SP allows authn/Password. It works as I want when the SP requires authn/MFA so there it's no problem.
>
> In the passwordless flow you collect the username that wants to login to an SP allowing authn/Password. If the username don't have a passkey registrated then the user will get an authn/Password dialogue with username (which is prefilled with the collected username) and password. The issue is that you can change username input to a username that has a passkey registrated and succeed to login with password. There I mean the authentication has been downgraded for that user.

Yes, I see what you mean. But from the SP's perspective, it is not downgraded. They are happy to accept that.

>
> I want it to work like in registration flow where you have an access control policy AccessByCurrentUser which stop the change of username. I see that it should be possible to accomplish that as in the authn/Password dialogue the username is prefilled so the username is known when entering authn/Password. I mean then a check could be done so that the username entered to authn/Password is the same as the username leaving authn/Password. However I don't simply know how to do that. Probably you have some advice to give in this matter.

I am not sure there is a way to prefill and prevent username input in the authn/Password flow, I will speak to Scott about it.

The only other thing I can think of that has access to all the information post c14n (and that is just because the WebAuthn context is not removed) would be a postAuthenticationFlow. I tested this quickly, and it seems plausible. I could look to add one into the plugin for somebody to enable. There may be some caveats I am unaware of though, so I will also discuss that internally.

Phil

>
> /Regards Mats
>
> On 2024-11-04 19:47, Cantor, Scott via dev wrote:
>>> I do not think your activation condition will work because the
>>> actual authentication flow is authn/MFA. So it is that
>>> activation condition the IdP will check and not the password
>>> flow condition.
>> Actually the MFA flow doesn't check a flow's activation condition when it runs login flows because you're the one telling it to run them. There are some things it checks/enforces, but not that.
>>
>> The decision logic governing when/whether to run Password is up to your MFA flow logic entirely.
>>
>> -- Scott
>>
>>
>>
>>
> --
> --
> 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 to 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