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
Kathleen Moriarty
Chief Technology Officer
Kathleen Moriarty, Chief Technology Officer, Center for Internet Security has over two decades of experience. Formerly as the Security Innovations Principal in Dell Technologies Office of the CTO, Kathleen worked on ecosystems, standards, and strategy. During her tenure in the Dell EMC Office of the CTO, Kathleen had the honor of being appointed and serving two terms as the Internet Engineering Task Force (IETF) Security Area Director and as a member of the Internet Engineering Steering Group from March 2014-2018. Named in CyberSecurity Ventures, Top 100 Women Fighting Cybercrime. She is a 2020 Tropaia Award Winner, Outstanding Faculty, Georgetown SCS.
Kathleen achieved over twenty years of experience driving positive outcomes across Information Technology Leadership, IT Strategy and Vision, Information Security, Risk Management, Incident Handling, Project Management, Large Teams, Process Improvement, and Operations Management in multiple roles with MIT Lincoln Laboratory, Hudson Williams, FactSet Research Systems, and PSINet. Kathleen holds a Master of Science Degree in Computer Science from Rensselaer Polytechnic Institute, as well as, a Bachelor of Science Degree in Mathematics from Siena College.
