By Mikkel Hald, 17/10/24
A growing number of service providers have a business need to know how securely the user was logged in at her institution (e.g., was it with more than a single “factor”: “MFA”). And luckily, an established technical standard exists for specifying exactly that kind of information in the “token” the institution's login system issues to the service the user attempts to access: the way the organisation authenticated the user is expresssed in a string within the token's AuthnContext element.
However, with many of WAYF's user organisations, it has turned out that the software used in the organisation's login service towards WAYF doesn't implement the standard. Which is undesirable as information about the login's quality (as it were) is increasingly important for the users to be able to access the services they need.
Instead of sending the login quality information in accordance with the specification, an organisation could, as a kind of work-around, send it as one of the values of the eduPersonAssurance attribute. Sending it there actually makes sense anyway – as eduPersonAssurance is meant to express any aspect of the assurance level of a digital identity, including how securely the identity was authenticated in the session at hand. This way the organisation is able to at least get the information across to the service provider, albeit not in the standardised way.
The safest choice, however, is to comply with the standard, sending the string as part of the AuthnContext element – or at least sending it there as well. For instance – and perhaps particularly critically – the international profile for MFA within research and education requires the use of this signal. And from now on, this will be easier for user organisations in WAYF to do – with a newly developed feature:
We exploit the fact that identity provider software in general is able to send, in the login tokens, any attributes the organisation wants, with any names and any values it wants – i.e. the very same feature that empowers the organisation to at least send the login quality information as part of eduPersonAssurance. It's extremely simple: the user organisation can simply send WAYF the value in an attribute named AuthnContextClassRef – the value will then figure in the AuthnContext element of the corresponding login token WAYF issues to the service the user is attempting to access.
It is, of course, a precondition that the organisation's identity provider software is at all aware how it authenticated the user, and can be made to express this as a value of an attribute. And this is the case with Microsoft's ADFS and EntraID, at least. Consequently, the many institutions using this software vis-à-vis WAYF can benefit from this feature straight away.