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 (SSO), authorization, and/or federation also requires consideration.
The SolarWinds attack bypassed MFA using 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 MFA and a move away from credentials that can be stolen, as motivated by recent attacks. This blog post will dive into authorization and SSO to aid in technology selection and deployment considerations. It provides a foundation for the following blog post that introduces emerging standards that learnt from the challenges of past protocols, reducing points of vulnerability where possible.
Using SSO 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, to protect both their own and their organization’s assets, including data. Environments where users have individual logins for each application are not only more difficult for the end user but also add complexity when onboarding new employees, moving employees into new roles, and terminations. A system that unifies logins to an SSO, 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 SSO methods.
SSO 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 (such as 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 with 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 and is often coupled with authentication. In many systems, you must first prove who you are (authentication) 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 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 PKI.
Directory services enable access to information associated with 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 publicly, or to an access-controlled set of data. The access controls could be a combination of users and 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
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. While this blog post is intended to introduce the topics and current considerations at a higher level, NIST Special Publication 800-63C provides detailed and technical explanations on Federation and assurance.
Kathleen Moriarty is Chief Technology Officer at the Center for Internet Security and the former IETF Security Area Director. She has more than two decades of experience working on ecosystems, standards, and strategy.
Adapted from this post on CIS Blog.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.