Beyond Single Sign-On

This article appeared in the March 2021 issue of the Information Systems Security Association (ISSA) journal. You can unlock full access to the journal here: https://www.members.issa.org/page/ISSAJournal.

An in-depth look at single sign-on capabilities, how they work, and how they can be improved.

 The recent security advisory [1] by the US National Security Agency (NSA) and the alert [2] provided by the US Cybersecurity & Infrastructure Security Agency (CISA) document an extraordinary amplification of the SolarWinds attack [3] on US systems, leveraging vulnerabilities in VMware’s Access and Identity Manager products that provide single sign-on (SSO) capability. At the time of writing, it is too early to tell how far the damage [4] has spread.

This is not the first time SSO systems have been hacked. In late 2018, Facebook made worldwide news due to its SSO implementation having caused the breach [5] of an estimated fifty million user accounts and theft of their personally identifiable information. Similarly, vulnerabilities [6] in SSO implementations have compromised accounts at Google, Oracle, Microsoft, Atlassian, Zoom, etc. with protocol attacks [7] discussed at peer-reviewed technical conferences.

As futile as it might seem to advocate for ripping out SSO technology from an IT infrastructure, a confluence of events makes this the most opportune time to do so. And, in doing so, it can eliminate risks within the infrastructure, reduce access control complexity, and eliminate unneeded software and associated Operations, Administration and Maintenance (OAM) costs while delighting users with the new experience. This paper describes how to do so.

Background
An early implementation of SSO was realized as Kerberos [8] in the late 1980s as part of MIT’s Athena Project. In the following decades, SSO was implemented in Security Assertion Markup Language [9] (SAML), OAuth [10] and OpenID [11] to address requirements for the web. All were predicated on the same premise: to help users deal with the burden of passwords when accessing multiple systems, and uniformly enforce enterprise password policy. The architecture of SSO can be generalized to what is depicted in the following two diagrams. The difference between the two is that after authenticating users, some implementations choose to have unique authorization tokens for each application after authenticating users (Figure 1), while others combine all application authorizations into a single token (Figure 2):

Figure 1: SSO with separate tokens for each application

Figure 2: SSO with a single token for all authorized applications

Users who access multiple applications within an enterprise are registered with the SSO Service. Their credentials and authorizations to access specific application are stored either within the SSO Database or, typically, within a Lightweight Directory Access Protocol (LDAP) Directory Server that can manage their privileges independently.

Users must, typically, pass through a Checkpoint, which may be an explicit component provided by the SSO provider on the network, or integrated within the application, before they access an application. The Checkpoint is responsible for ensuring Users have an Authorization Token from the SSO Service before they are granted access to the application. If they do not have such a Token, they are redirected to the SSO Service where they must be authenticated, usually with a username/ password, one-time PIN (OTP), and/or a knowledge based authentication (KBA). Upon successfully authenticating, Users are issued a Token, generally stored within the browser header, and returned to the Checkpoint. Upon retrieving and verifying the Token’s authenticity and integrity, and having verified the User’s authorization, the Checkpoint directs them to the desired application.

The Token is usually cryptographically generated to ensure its security, but it depends on the key-management controls deployed within the SSO Service, as the SolarWinds breach highlighted. If the security controls are inadequate, attackers can bypass the SSO Service for user accounts and generate Tokens with the right privileges by compromising upstream systems in the authorization process. The attack vector used in magnifying the SolarWinds breach leveraged an SSO vulnerability in VMware® Workspace ONE Access used to provide SSO access to hypervisors of cloud environments. The advisory [12] published by NSA notes:

• They eliminated the need to authenticate to each application separately.
• They eliminated the need to remember distinct pass-words for each application.
• They centralized authentication and authorization within one or two infrastructures; the authentication infrastructure consisting of a userid/password database, and the authorization infrastructure consisting of the SSO Service, making it possible to mitigate vulnerabilities associated with not revoking an ex-employee’s credentials.
• They simplified reporting such as listing all applications a specific employee had access to; or listing all employees who were authorized to access a specific application.
• They enabled new authentication capabilities more easily at the centralized SSO Service by allowing sites to bolt on the newer authentication capability as a precursor to the SSO Service receiving the signal that a specific user was successfully authenticated.

• Having to integrate SSO protocol(s) to all applications. Generally a complex effort, depending on the SSO product, usually involving:
  • Modifying business applications to accommodate SSO protocols and ensuring consistent application behavior. This is usually not a one-time effort; each change in the application and/or in the SSO product requires analysis, engineering, quality assurance, and OAM work.
  • Training employees to work with new workflows and technology, also not a one-time effort.

• Complying with regulatory requirements for multi-factor authentication (MFA) into SSO infrastructure where necessary, while managing integration complexity without straining budgets and schedules.
• Investing in the cost of the SSO product and its ongoing maintenance and support. If the SSO Service needs to be integrated with a distinct MFA solution, the cost of the MFA solution is a separate line-item.
• Managing the security and availability of the SSO Service for “single-point-of-failure” scenarios.

• Enabling customizing PKI for business use-cases with diverse security needs, from basic levels of security to military-grade protection.
• Enabling “non-repudiation” of business transactions within a legal context, created with digital signatures on documents.
• Enabling o%-line verification of digital signatures without the need to be connected to the PKI or even a network.
• Enabling confidentiality through message-level encryption in electronic mail [13] and other protocols.
• Enabling authentication to operating systems using smartcards. [14]
• Enabling secure cryptographic authentication of chip-based traveler [15] information.
• … and many more use cases.

• To be an open specification, and royalty-free to anyone to build open-source or commercial implementations.
• To enable physical devices called Authenticators to generate cryptographic key-pairs, a Public Key and a Private Key, for each company’s site that has User registration.
• To protect User privacy by having the Authenticators generate unique key-pairs for each company’s site, Rely-ing Party (RP) in FIDO terminology, to authenticate Users. FIDO Authenticators are mandated to ensure that an RP never learns of another RP’s keys at any time even when the User uses the same Authenticator to register with dozens of web sites.
• To store raw Public Keys on the server and generate digital signatures within the Authenticator using the Private Key, for unique challenges sent by FIDO servers.
• To prevent man-in-the-middle (MITM) attacks on User accounts visiting RP sites. FIDO mandates a test of user presence with a “human gesture” at the computer attempting to connect to the RP site. The “human gesture” may consist of any action supported by the Authenticator:
  • touching a contact point on the Authenticator,
  • typing in a personal identification number (PIN) known to the User,
  • selecting a pattern drawing known to the User,
  • supplying a biometric reading through a !nger-print, voice, facial recognition, etc.; or
  • any other gesture that requires physical possession of the Authenticator and performing some action with it.

• To, optionally, support user verification on the computing device or Authenticator with biometrics, a PIN, or a pattern drawing known to the legitimate User.
• To support the use of Trusted Execution Environment (TEE) or cryptographic hardware components – known as secure elements – when available in Authenticators or computing devices to protect [18] Private Keys from theft and unauthorized use.
• To prevent replay attacks of legitimate and successful User authentication sessions, through the use of a counter maintained on the Authenticator and verified by the FIDO server for non-repetition.
• To support the use of FIDO with any modern browser using portable Authenticators called Security Keys using universal serial bus (USB) ports, or when paired with computing devices using near field communications (NFC) or Bluetooth low-energy (BLE) protocols.
• To support embedded Authenticators in computing devices. Currently, Microsoft Windows 10 supports using a Trusted Platform Module (TPM) on personal computers, while Android supports using the TEE and/ or a hardware secure element on mobile devices.
• To eliminate password phishing attacks on users by verifying the web origin (uniform resource locator aka URL) of the RP web application, and providing that information to the Authenticator at the time of User registration or authentication. Authenticators are required to respond to challenges only if they are communicating with the verified web origin of the RP site.
• To support using multiple Authenticators to the same RP account to enable “account recovery” in the event of a lost or forgotten Authenticator, in which case, Users use another, previously registered Authenticator to login into their account.

FIDO deployments generally resemble the following diagram:
Figure 3: General FIDO web-application architecture

Much as applications are required to be modified to work with the SSO Service, web applications must be programmed to take advantage of the FIDO protocol.

SSO with FIDO
Given that FIDO is an authentication protocol, the question arises: how can it be used to replace SSO capability? There are two different capabilities within the infrastructure, with the former focused on authentication and the latter on determining authorization to use applications. Based on past SSO implementation, it would seem that it should be possible to implement FIDO in conjunction with SSO and preserve the bene!ts of SSO while leveraging the newer authentication capabilities of FIDO (as shown in the following architecture diagram):

Figure 4: FIDO strong authentication within an SSO architecture

While this is true on first glance, a deeper analysis shows that if an organization has to modify its applications to leverage new security controls that mitigate risk, it could go further and solve multiple problems with one solution. The organization could reduce its attack surface by leveraging FIDO servers that combine SSO capability in them, to eliminate the external SSO infrastructure. This also has the bene!ts of saving the organization money on SSO related costs.

Replacing SSO with FIDO
The following User “journeys” depict how such a modified infrastructure might work. Note: We assume a fictional company whose domain name is company.com and three distinct applications accessed as green.company.com, red.company.com, and yellow.company.com. In such an architecture, the Relying Party ID (RPID) that will be used for the FIDO protocol will be company.com.

There are two ways in which FIDO can support replacing external SSO infrastructure while preserving the “perception” of SSO:

Applications Generate their own Session Tokens
When the User first registers with any of the three applications, say green.company.com, using their FIDO Authenticator, they are registered with a new key-pair associated with company. com. Since the registration process will have authenticated the User to green.company.com, the application will generate its own session token and place it in the User’s browser.

This establishes the User’s session with green.company.com and authorizes him to the business role assigned to him within the application as shown in the following diagram:

Figure 5: FIDO strong authentication replacing SSO with application-generated session Tokens

When the User navigates to use the red.company.com application, the application attempts to authenticate him. Upon recognizing that a Token exists in his browser for company.com, the application automatically gets a FIDO challenge from the FIDO server and presents it to the Authenticator.

The Authenticator recognizes the RPID provided by the challenge and uses the Private Key for company.com to authenticate the User. Upon providing the appropriate authentication gesture with the Authenticator, the User is successfully authenticated by the FIDO server.

When red.company.com receives a success response from the FIDO server, it updates the session Token in the User’s browser to include the authorization for the User to use the red.company. com application or adds a new Token to the browser authorizing the User to use the application at red.company.com.

This process is repeated for yellow.company.com and every other application integrated by the site to their FIDO server. When a User’s session ends or terminates on an explicit logout, the User’s Token is updated to reflect that state.

It is important to note that the User is strongly authenticated with FIDO to every application with a passwordless protocol that only requires a human gesture with the computing device or the Authenticator. Every application relies on its own authentication of the User with a common FIDO service within the infrastructure, thus distributing the workload to each application in accordance with its business requirements.

It is also important to note that each application is also responsible for verifying the User’s authorization to use the application; this is identical to the SSO architecture, but without the SSO protocol and additional infrastructure.

To achieve further economies, companies can choose to create a common library for session Token creation and verification. This ensures that common functionality is shared across the enterprise without each application having to burden itself.

FIDO Server Generates Session Tokens
In this second method of replacing SSO with FIDO, where a FIDO server supports built-in SSO capabilities, it is possible for the FIDO server to create the cryptographic session Token upon successful FIDO authentication of the User, and returns the Token to applications, as shown in the following architecture diagram:

Figure 6: FIDO strong authentication replacing SSO with FIDO server generated session Tokens

When the FIDO server subsumes the creation of the session Token, it is responsible for authenticating the User and generating the session Token as an atomic operation. This not only eliminates the application burden, but also any potential vulnerability gaps that might arise between the two operations. This is conceptually identical to the SSO infrastructure but without the SSO infrastructure.

When the session Token is generated as a JSON Web Signature (JWS) object with an X509 digital certi!cate embedded in it to create a JSON Web Token (JWT), the FIDO server would avoid the need to share a secret key with applications to verify the JWT. This makes the infrastructure more secure because digital certificates do not possess secrets. With such a JWT, the application is equipped with the necessary resources to verify the authenticity and integrity of the session Token, similar to the SSO architecture but without the SSO infrastructure. 

Organizations who understand the benefits of FIDO and choose to implement the capability will need to acquire FIDO capabilities and modify their applications to integrate it. When they do so, they have the option of integrating FIDO with their current SSO infrastructure or, potentially, choosing to leverage SSO capabilities in a FIDO server where it exists. While it might seem a simple decision to overlay the new authentication capability on existing infrastructure, companies have an opportunity of taking a proactive approach to reducing complexity and risk within their organization by collapsing the two capabilities during this once-in-a-generation shift in technology.

Summary
FIDO is one of the most innovative authentication technologies the industry has created in three decades. Learning from past lessons, FIDO solutions balance simpler user experience with the “highest assurance” authentication protocols [19] at lower cost.

Organizations may believe their existing multi-factor, single sign-on enabled solution is more than adequate for managing authentication and authorization risk. However, recent attacks have shown the vulnerability of preserving SSO capabilities even as authentication technologies and capabilities vault past the reason why SSO was necessary in the first place.

The industry is at an inflection point where an investment must be made to incorporate FIDO to eliminate lingering vulnerabilities; it presents an added opportunity to simplify applications and infrastructure by eliminating SSO along with older authentication technologies. They should grasp the opportunity.

References:
1. Russian State-Sponsored Actors Exploiting Vulnerability in VMware Workspace ONE Access Using Compromised Credentials – NSA Cybersecurity Advisory - https:// media.defense.gov/2020/Dec/07/2002547071/-1/-1/0/ CSA_VMWARE ACCESS_U_OO_195076_20.PDF
2. Cybersecurity & Infrastructure Security Agency Alert (AA20-352A) - https://us-cert.cisa.gov/ncas/alerts/aa20-352a
3. An Understanding of Russian Hacking Grows, So Does Alarm – New York Times, January 2, 2021 - https://www. nytimes.com/2021/01/02/us/politics/russian-hacking-gov-ernment. html
4. Cloud Services From Major Providers Including Amazon and Microsoft Vulnerable to the Widespread SolarWinds Hack – CPO Magazine, January 4, 2021 - https://www. cpomagazine.com/general/cloud-services-from-ma-jor-providers-including-amazon-and-microso#-vulnera-bleto-the-widespread-solarwinds-hack/
5. Facebook Breach: Single Sign-On of Doom – Bank Info Security, October 2, 2018 - https://www.bankinfosecurity. com/blogs/facebook-breach-single-sign-on-doom-p-2668
6. Search for “sso vulnerabilities” on DuckDuckGo - https:// duckduckgo.com/?q=sso+vulnerabilities&t=%ab&ia=web
7. On Breaking SAML: Be Whoever You Want to Be – Juraj Somorovsky, Andreas Mayer, Jorg Schwenk, Marco Kamp-mann, and Meiko Jensen – USENIX Security Conference - https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91-8-23-12.pdf
8. Kerberos: "e Network Authentication Protocol – MIT - http://web.mit.edu/kerberos/
9. OASIS Security Services (SAML) Technical Commit-tee - https://www.oasis-open.org/committees/tc_home. php?wg_abbrev=security
10. The OAuth 1.0 Protocol – IETF RFC 5849 - https://tools.ietf. org/html/rfc5849 "e OAuth 2.0 Authorization Framework – IETF RFC 6749 - https://tools.ietf.org/html/rfc6749
11. OpenID Authentication 2.0 – Final - https://openid.net/ specs/openid-authentication-2_0.html
12. Russian State-Sponsored Actors Exploiting Vulnerability in VMware Workspace ONE Access Using Compromised Credentials – NSA Cybersecurity Advisory - https:// media.defense.gov/2020/Dec/07/2002547071/-1/-1/0/ CSA_VMWARE ACCESS_U_OO_195076_20.PDF
13. Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Speci!cation – RFC 5751 - https://tools. ietf.org/html/rfc5751
14. Guidelines for enabling smartcard logon with third-party certi!cation authorities – Microso# - https://docs.microso#. com/en-us/troubleshoot/windows-server/windows-security/ enabling-smart-card-logon-third-party-certi!cation-author-ities
15. Public Key Directory – ICAO Security and Facilitation - https://www.icao.int/Security/FAL/PKD/Pages/default.aspx
16. FIDO: Fast Identity Online – ISSA Journal, December 2020 - https://www.members.issa.org/page/journal-2020 StrongKey CryptoEngine is FIDO Certi- !ed®- https://www.linkedin.com/pulse/ strongkey-cryptoengine-!do-certi!ed-arshad-noor
17. Alliance Overview – FIDO Alliance - https://!doalliance. org/overview/
18. Notwithstanding the security protocol, speci!c imple-mentations can be compromised as described in this recent research paper of the cloning of a well-known FIDO Authenticator’s security chip by observing its electromagnet-ic radiation – also known as a side-channel attack – Ninja Lab - https://ninjalab.io/wp-content/uploads/2021/01/a_side_ journey_to_titan.pdf
19. NIST Special Publication 800-63 Digital Identity Guidelines - https://www.nist.gov/itl/tig/projects/ special-publication-800-63 

About the Author
Arshad Noor is the CTO of StrongKey since 2001. With 34+ years of experience in the Information Technology sector, he has spent the last 21 years of his career focused on solving data-protection problems using applied cryptography. He has designed and constructed Public Key Infrastructures (PKI) for companies in the banking, defense, telecommunication, pharmaceutical, biotechnology and e-commerce sectors. He wrote the first open-source enterprise-scale symmetric key-management system in 2006, and adapted it to build an appliance to solve cryptographic key-management problems for companies complying with PCI-DSS, GDPR and the upcoming CCPA regulations.

He has written articles and spoken at dozens of conferences around the world on data-protection. Having authored protocols at OASIS in the past, he currently collaborates with NIST National Cybersecurity Center of Excellence (NCCoE), and is an active contributor to the FIDO Alliance to eliminate passwords from the internet. In 2019, he served as one of 20 members on the California Blockchain Working Group helping to craft recommendations to the State Legislature on how the 5th largest economy in the world should deal with blockchain. When not advocating for application level security and strong authentication, he encourages everyone to live the “Blue Zones” life. You can also find him at https://www.linkedin.com/in/arshadnoor/.