Adding Multifactor Authentication to Federation
It should surprise few how rapidly two-factor authentication, or multifactor authentication (MFA), is being adopted. More and more organizations are deploying it to segments of their users (or to all of them) to protect critical systems and data from being breached due to a phished password. Root access to systems, privileged access to applications and databases, and remote access to critical systems by unauthorized persons are among the leading risks being addressed with MFA.
The range of systems and applications that can be protected by MFA is growing, too, as more technical integrations are built and more applications are updated to accommodate this need. Applications protected by federated authentication are better positioned to benefit since only the federated login must be integrated with MFA to protect downstream applications. The Shibboleth Identity Provider v3.3, in particular, has good built-in support for MFA.
But how should a federated service signal that it wants MFA? Federation protocols provide a way to send such signals, but one that means "MFA is required" was never defined! Absent a standard for that, each implementation must define its own unique signal. That means bespoke configuration must be made in each IdP and SP, which increases time, complexity, and cost to implement.
In 2016 the InCommon Assurance Advisory Committee chartered a working group to address this need. Their deliverables included an MFA Interoperability Profile, one that is extremely well thought through, as you would expect when some of R&E's best technical people converge on a problem. As of this writing their work is in the final step to adoption as a global standard by REFEDS, the organization to which all Research & Education Federations belong. This is expected in April 2017.
Bringing MFA protection to more applications often has additional challenges beyond how an application can signal that need, especially when it is desired to require users to exercise MFA only when needed. Some of those challenges can be avoided if MFA just happens at the start of each single sign-on session. That is, if a user has an MFA credential, then use it, always. With the MFA Interoperability Profile in place, a more-granular approach can proceed as vendors enhance their applications to signal MFA step-up when users exercise privileged functions.
Once the MFA profile has been adopted by REFEDS, InCommon will begin using it to request MFA for its Certificate Service. Stay tuned for more information on both the Profile and anticipated enhancements to our services.