simplesamlphp / simplesamlphp-module-webauthn

A module implementing FIDO2 / WebAuthn as a second authentication factor
GNU Lesser General Public License v2.1
15 stars 8 forks source link

Allow per-user authentication based on attributes #5

Closed jaimeperez closed 4 years ago

jaimeperez commented 5 years ago

Currently, the module allows enforcing multi-factor for all users, or on a per-user basis. In the latter case, the second factor is enforced depending on a specific attribute for the user in the database. It would be useful though to control this in the user backend (e.g. LDAP, AD, etc) by looking for an attribute with a given value, since then the directory administrator can define groups and many other strategies to enable multi-factor for users, rather than directly touching the database.

restena-sw commented 4 years ago

I have a concrete use case for this in our own auth scenario.

We already do second-factor with OTPs. They are appended to the actual password in the normal ("1st factor") loginuserpass.php. The backend (in our case FreeRADIUS) checks if there is a OTP-looking suffix in the password and validates that against an OTP server (in our case, privacyIDEA). Upon successful second-factor validation, it adds an attribute stating that this was a two-factor auth. If there was no OTP, no attribute is added.

This should continue to work (e.g. as the backup if the FIDO2 token is lost). But the FIDO2 authprocfilter should activate if there was no OTP provided, bringing in the second factor in the second phase. That way, users can choose to use OTP or FIDO2 without having to express their choice in a separate UI.

I think the best way to steer activation is by leaving the "default_enabled" configuration item as-is, but adding two items "attribute_force_enable" = "urn:oid:..." and "attribute_force_disable" = "urn:oid:..." whose respective presence overrides the default. If both attributes are present, consider that as enabled - it is a misconfiguration, but let's err on the side of caution.

Ideally, the module would also be able to add an attribute by itself to indicate later authprocs or even the SAML assertion that WebAuthn was used. Due to the lack of any such OID in standardised space, it should be configurable where to put this, like: attribute_add_on_success = ["urn:oid:..." => "FIDO2" ]

jaimeperez commented 4 years ago

That sounds like a good approach, Stefan. The default_enabled should be in there, as enabling/disabling is done module-wise. Is this something you could work on?

restena-sw commented 4 years ago

I certainly could. Yesterday we had a VC with the GEANT T&I Incubator task, where volunteers for working on the open enhancement requests were participating. I consider the issue at hand as rather nicely suitable for getting started, so I would probably leave this to the people there.

melanger commented 4 years ago

This was addressed in #28