Single Sign-On (SSO) and Federated systems appear the same to the end user – with each, he logs in once and can then use multiple systems or applications without having to log in again. However, SSO and Federation work quite differently behind the scenes and, therefore, call for different authentication protocols. Both SSO and Federation can leverage multi-factor authentication; however, each solution has advantages and disadvantages as it relates to strong authentication.

Single Sign On

With SSO, a user is uniquely recognized by each of the organizations that leverage SSO, but they all agree to trust a single sign-on.  The user’s identity is enrolled in each of the systems (directories) to which the SSO provides access; the user has credentials (and therefore roles and authorities) for each system behind the SSO.  his can be accomplished in several different ways – by having a user log in to one system through a gateway in another system, thus creating a token in the gateway system, or through a creation of a separate account that ties together the gateway system and the systems behind the SSO. When the user logs into the gateway system, the SSO solution replays the login information for every subsequent system the user accesses without the user knowing the replay is occurring. 

Federation

OpenID, Info Card, and other available commercial programs provide Federation rather than SSO. While this looks and feels like SSO to end users, Federation is different in how it works and what type of authentication it provides. In federated systems the user is known only to the front-end system. All organizations within the Federation agree when they join the alliance that they will accept the credentials and the identity that is passed to them (through SAML typically) from a log-on, but they have no awareness of the end-user identity in the access manager or directory before it is passed. In such solutions, the Federation recipient trusts the user and the authentication process because the authenticating organization does.

Federation does not mean that the user is not known to the downstream system, it simply means that he was not enrolled in the access manager for that system. For example, a patient might use a federated identity to access health information stored in a hospital system. The hospital records management system certainly knows who the patient is and can find the data when queried for it; however, the patient never enrolled in the hospital Web information management system and consequently does not have a unique external identity to the hospital (typically stored in a directory and leveraged by an access manager). The user logs into the federated identity system, and their identity is passed to the hospital system that trusts the identity Federation standards and identity proofing, and then accepts the identity as presented.

The Challenge

The challenge for many federated systems is that most well-known commercial SAML assertion providers offer no identity proofing or strong authentication and therefore have weak (if any) identity associated with the login credentials. As a result, a fraudulent user who can pass through the authenticating organization then has access to all the systems within the federation without any subsequent login processes.

The goal for Federation is then the establishment of trust between the credentialing provider/authority and the relying party. In order to protect customer data and federated enterprise systems, Federation members should always insist that the authenticating organization/credential provider have a strong identity proofing and strong authentication. If weak user credentials are permitted and compromised – if a fraudster  gets in through the “front door” pretending to be a legitimate user – no amount of encryption and anonymization on the back end will prevent that fraudulent user from accessing the information within the Federated systems. Federated sites accepting a SAML assertion invoked with two-factor authentication can work inside or outside a single security enclave.

SSO platforms can perform two-factor authentication with OTP solutions or tokens at the beginning of a session, but when they transfer a user to a protected site, they cannot replay an OTP or token code because by the time the replay takes place, the token will have expired. Consequently sites that accept SSO behind multi-factor authentication should be protected within the same security enclave as the SSO platform since leaving the security enclave would allow replay of only single factor credentials unless the user is required to re-authenticate. 

Conclusion