Authentication and Authorization Using Single Sign-On

By: Kathleen M. Moriarty, CIS Chief Technology Officer

In order to prevent credential theft from phishing attacks, there is a push for multi-factor authentication (MFA). This is a very important step and should be considered if your organization has not yet made the transition. While MFA adds important protections, how you implement single sign-on, authorization, and/or federation also requires consideration.

The SolarWinds attack bypassed MFA through the use of a vulnerability in a federation technology, Security Assertion Markup Language (SAML), that allowed attackers to bypass end-user credentials entirely. Vulnerabilities in authorization frameworks like OAuth have led to compromise in the past as well. In the first blog of this series, we explored multi-factor authentication and a move away from credentials that can be stolen, as motivated by recent attacks. This blog will dive into authorization and single sign-on to aid in technology selection and deployment considerations. It provides a foundation for the following blog post that introduces emerging standards that have taken into account learnings from the challenges of past protocols, reducing points of vulnerability where possible..

Using Single Sign-on for Simple Authentication

Users want authentication to be simple, requiring less for them to remember and manage. But they also want it to be more secure, in order to protect both their own and their organization’s assets, including data. Environments where users have individual logins to each application are not only more difficult for the end user, but also add complexity when it comes to onboarding new employees, moving employees into new roles, and terminations. A system that unifies logins to a single-sign on, or one that ties the various accounts into an overarching access control system, eases the employee workflow processing. If an employee leaves the organization, the process to remove all account access is greatly simplified with some single sign-on methods.

Single sign-on or reduced sign-on is possible through several models where the user perception is the use of a single or reduced set of authentication methods to access applications:

Stored credentials are accessed using authentication to a cryptographic key or password store (e.g. WebAuthn or password containers). The credentials are then used to authenticate to the appropriate application or service.
Credentials are synchronized across platforms using Lightweight Directory Access Protocol (LDAP) servers.
In the case of public key infrastructure (PKI), an authorized authentication key and certificate are associated to individual services, where the public key is published in a directory service to validate use of the associated private key. For each application, the user account is associated to the appropriate user key and associated certificate.
One-time passwords (OTP) may be used in conjunction with password storage applications that proxy authentication for the user, providing the perception of single or reduced sign-on capabilities.

There are multiple methods that can be used to achieve single or reduced sign-on, with some methods being easier for an environment due to the set of applications and authentication technologies currently in play.

Authorization and Authentication

Authorization is used to grant access to resources. It is often coupled with authentication: in many systems, you must first prove who you are (authenticate) to gain access to capabilities (authorization).  Authorization is the access a user or role is granted to, or within, an application tied to access control models. Stated simply, authorization is about what you can do.

How is authorization to resources accomplished?

In the case of OAuth, a user may authenticate to an application and a second application may accept an authorization credential or token for that user from the first application. You’ve used OAuth if you have granted permissions for one application to ‘authenticate’ using your authorized login to another application such as from Facebook, Gmail, or other services.

Guidance on Authentication and Authorization

Authorization may tie to a more complex access control model where users could be assigned to roles and specific permissions are granted to particular roles.

Federation

Federation grants access across administrative domains. In other words, organizations or separated groups within an organization. An example of this is the use of the federation technology, Shibboleth, across university networks. This Federation technology allows students to use resources, such as library access, at other universities using their credentials from their own school. Federation bridges access across domains, where authentication and authorization are based on the originating organization’s policies. The Shibboleth federation uses the SAML standard to accomplish this today.

Other federation technologies include OpenID Connect, which is built on top of the OAuth authorization framework. Directory Services such as the Lightweight Directory Access Protocol (LDAP) and X.500 are supporting technologies to authentication and authorization frameworks, but are not in themselves authentication, authorization, or federation technologies. They are directory services capable of managing password authentication stores for services as well as synchronization of passwords across services. They are also necessary to enable access to public certificates and certificate revocation lists used in public key infrastructure (PKI).

Directory services enable access to information associated to an index. In the PKI example, properties of the issued certificate, such as the “common name” for a user, enable access to a user’s public encryption key. The functionality of a directory service is to provide an index to information made available publically, or to an access controlled set of data. The access controls could be a combination of users, roles, as well as parts of the directory structure. This distinction is important for understanding the supporting infrastructure and components in an identity and access management framework.

NIST Special Publication 800-63C

NIST Special Publication 800-63C provides detailed and technical explanations on Federation and assurance. This blog is intended to introduce the topics and current considerations at a higher level. In teaching Security Architecture and Design at Georgetown University, it has become apparent that more accessible documentation would be helpful as an introduction to these complex topics.

About the Author