Federated authentication – Background

Authentication for a cloud-based SaaS application can be accomplished using one of two ways: entering a user ID and password in the user’s browser or using identity federation. The former method is pretty well known (and increasingly reviled). The latter method is well established and has superior security.
If your institution is allowing users (staff, students, external users) to access your cloud SaaS applications by inputting their passwords on such applications, then you are taking on substantial security and compliance risk. When it comes to information security, the harsh reality is that end users are often the weakest link in the chain. It’s no surprise then that end users are often the first point of call to be exploited by attackers. In recent years, the overwhelming majority of security breaches have involved some form of credential loss or theft, resulting in unauthorized access and information disclosure.

As institutions use more and more cloud applications there is the issue of password management. The average employee is tasked with managing between six to 15 passwords daily, and is expected to reset them every 90 days. Complexity quickly increases with the number of applications. Each application has different password requirements and expiration cycles. The variety of requirements multiplied by the variety of expiration cycles equals diminished user productivity and increased user frustration as they spend time trying to reset, remember, and manage these constantly changing passwords across all of their applications. Perhaps of even greater concern are the security risks caused by the same users who react to this “password fatigue” by using the obvious/weak or reused passwords written down on Post-it notes or saved in Excel files on laptops leading to further vulnerability. What is needed is a way to eliminate passwords altogether and provide Single Sign-On (SSO) to cloud applications, while maintaining high security levels. Federated identity was developed by the industry to solve these challenges.

Federated authentication process takes place between a Service Provider (SP), an application that provides functionality that the user must sign into to use, and an Identity Provider (IdP), a service whose job is to authenticate and verify the identity of the user to the requesting application. Users sign on once with a standard institutional login and when they click a SaaS application link, the SaaS application (i.e. “Service Provider”) passes the authentication request back to the identity provider (IdP). Once the identity provider authenticates the user, it provides a token back to the SaaS application. No passwords are included in this token. The SaaS application knows the token is really from the identity provider because it’s been digitally signed for authenticity.
Since the institution authenticates the user and the SaaS application can verify the authenticity of the provided federated identity, application passwords are not needed and users enjoy SSO access to the SaaS application. Identity federation is a huge win for users and institutional IT alike: Users love federation because the SSO enables them to use external/cloud applications as easily as internal applications while freeing them from remembering (and resetting) a battery of passwords. IT loves federation because it simultaneously enhances security, decrease risk and reduces the support burden.

Federated Authentication Protocols There are several widely adopted protocols in use including SAML, LDAP, CAS and OAuth:
SAML – Security Assertion Markup Language, or SAML for short, is an XML-based, open-standard defined by the Organization for the Advancement of Structure Information Standards (OASIS). The goal of the standard is to create a framework for sharing security information between online business partners, with a focus on use in Identity Federation, Single Sign-On, and integration with other Web services and industry standards. SAML v1.0 was certified as a standard in November of 2002, and updated in September 2003 as v1.1. After input from organizations implementing and customizing SAML, v2.0 was standardized in March of 2005 (OASIS 2005). Over the years, SAML gained a lot of popularity and SAML 2.0 is the most mature federation specification being adopted today. This is evidenced by its use in an overwhelming majority of established federations, and its ever-expanding adoption by vendors providing user authentication, access management, virtual directory and networking products.
LDAP – The Lightweight Directory Access Protocol (LDAP) is an application protocol for accessing and maintaining distributed directory services that share information about users, services and applications in the network. It is commonly used for implementing a SSO solution for users in a domain, so that a single set of user credentials are shared across several services in the network. LDAP is often used in combination with an active directory.
OAuth – OAuth is an open-standard authentication protocol developed by the Internet Engineering Task Force (IETF). The most recent draft version of 2.0 (version 25) was submitted on March 8, 2012. The main goals of OAuth are to create a layer between IdPs and SPs, this is done using tokens. Its primary advantage as a standard is its wide adoption rate across many mobile and web applications today. If you have ever logged-in to a website using Facebook or Google, you have used one of OAuth 2.0’s many authorization flows.
CAS – Central Authentication Server (CAS) is an open source authentication system originally written at Yale University that provides a trusted way for a web application to authenticate a user. CAS is now maintained by JASIG and is widely used in higher education. In May 2014, CAS Protocol specification 3.0 was released.

Different Options of IdP’s Institutions can choose to deploy on-premises Identity Providers and cloud-based Identity Providers. Each type has its own advantages and disadvantages. Some example of these IdP options include:
Shibboleth IdP – was first designed by Internet2’s Middleware Architecture Committee for Education, with the goal of creating an open-source federation protocol to allow research and higher education institutes to share information more easily. Shibboleth 1.0 was first released in June of 2003, and was based on SAML v1.1. The most recent version, 2.0, was released in 2008, and leverages the better security of SAML v2.0. Shibboleth has proved to be very popular among higher education institutes, and federations based on the protocol have been created around the world.
Active Directory Federation Services (ADFS) IdP – is an identity management service for Windows Server that uses a claims-based authentication to allow users to gain single sign-on access across trusted domains. Microsoft began providing SAML 2.0 support in 2010 with the release of ADFS 2.0. ADFS is a mainly used in institutions with identity management based on Microsoft’s Active Directory.
Azure Active Directory (Azure AD) is a cloud-based identity management solution from Microsoft that offers comprehensive identity and access management tools for single sign-on login procedures to cloud and on-premises applications. Azure AD supports several different authentication protocols, including SAML, OAuth and WS-Federation.