To prevent attacks, there's a push for multi-factor authentication. This is a vital step and should be considered if your organisation hasn't yet made the transition. But while MFA adds protections, how you implement single sign-on, authorisation, and/or federation requires consideration.
The SolarWinds attack bypassed multi-factor authentication (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 authorisation 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 authorisation 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 organisation’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 organisation, 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 synchronised across platforms using Lightweight Directory Access Protocol (LDAP) servers.
- In the case of public key infrastructure (PKI), an authorised 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.
Authorisation and Authentication
Authorisation 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 (authorisation). Authorisation is the access a user or role is granted to, or within, an application tied to access control models. Stated simply, authorisation is about what you can do.
How is authorisation to resources accomplished?
In the case of OAuth, a user may authenticate to an application and a second application may accept an authorisation 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 authorised login to another application such as from Facebook, Gmail, or other services.
Guidance on Authentication and Authorisation
Authorisation 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, organisations or separated groups within an organisation. 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 authorisation are based on the originating organisation’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 authorisation framework. Directory Services such as the Lightweight Directory Access Protocol (LDAP) and X.500 are supporting technologies to authentication and authorisation frameworks, but are not in themselves authentication, authorisation, or federation technologies. They are directory services capable of managing password authentication stores for services as well as synchronisation 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 publicly, 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.
Originally published over on the CIS blog.
Comments 0
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.