Hi Greg,
You have both options: integrating 2FA as part of the old login flow, everything in the same form and in the same module, or having an additional module that deals only with 2FA in a separate page. The latter has several advantages, as it’s simpler to implement (you only need to implement the second factor, not the “first" authentication), does not require the modification of any existing page layouts (i.e. the login form) and is more flexible, as if you later want to add several 2FA methods to choose from, then it’ll be easier to do.
Personally, I’d go for the latter. In Feide we did a mix. We have our own module that deals with authentication, including the second factor as part of the authentication source. However, the second factor is authenticated in a separate form after username/password authentication, as we allow the user to choose from a list of 2FA methods, and that list depends on what the user has configured (and his organization allowed).
Regarding the technical details, that might be a bit more for the development mailing list. In any case, authproc filters (and auth sources, for that matter) will always have access to the state array. There you’ll have, among many other things, an array with the attributes of the user under the “Attributes” key (provided the user was already authenticated, of course). Use that and make it configurable so that you can define which attribute you want to use to univocally identity the user. Don’t rely on the “UserID” in the state array, as that will go away in future versions of SSP.
--
Jaime Pérez
UNINETT / Feide
jaime...@uninett.no
jaime...@protonmail.com
9A08 EA20 E062 70B4 616B 43E3 562A FE3A 6293 62C2
"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost