Single Sign-On (SSO): Techniques, Security, and Implementation

Introduction to Single Sign-On

Users frequently face the onerous burden of juggling multiple password and username combinations when working across disparate platforms and applications, being prompted for credentials at each new instance. Emerging Single Sign-On (SSO) technology has largely eased that workflow. SSO has evolved considerably and continues to do so, addressing the challenges faced by workers in IT and the applications they use. "Real" SSO is not a single entity; it is a general term for all techniques, devices, or combinations that aim to reduce the burden of multiple login instances within a session.

SSO is more of an arrangement that helps both end-users and system administrators access their work seamlessly, with the added benefits of security and enterprise consistency—making it easier to accomplish tasks without the dangers of hacking, data theft, or impersonation. However, navigating web browsing, different platforms, and legacy applications through a single point of entry is not a straightforward task to secure. Each environment has its own set of queries, requirements, and security parameters that may vary greatly from another.

At its most minimal, SSO can simply reduce the number of times a user must enter a username-password combination during a session. SSO does carry an obvious drawback: unauthorized access to a single, genuine SSO credential set could be disastrous for an entire organization, with far-reaching ramifications. This inherent security predicament is, however, overshadowed by the advantages SSO offers, and a well-designed SSO system can make unauthorized access extremely difficult, if not impossible (PistolStar, Inc., 2006). Each organization must examine its requirements and complexities carefully to select the right SSO application from the many possibilities available in terms of deployment, design, and use.

SSO vs. Biometric Authentication

Biological attributes cannot be impersonated, reproduced, or replaced, as they are unique to each individual. The use of biometrics has long captured the imagination, as depicted in films and fiction. It is also widely applied in fingerprint scanning, audio signal processing, facial recognition, and iris scanning for security and authentication in academic, commercial, and organizational settings.

The drawbacks of biometric systems are significant. An injury or burn to the thumb or fingertips may be sufficient cause to deny a user access to an entire system for the duration of healing. Stained or soiled fingers are equally likely to be rejected by machine scanners. Even as fingerprint techniques find wider acceptance, limitations in device calibration and checking can become serious concerns.

Voice-based authentication—verifying a person using their unique voice, tone, and speech patterns—has been used in high-security zones for some time. However, this approach has not translated well to general commercial use. The most apt application is perhaps on mobile phones, which are already designed to transmit and receive audio and incorporate advanced signal conditioning and noise-filtering by default. Voice authentication is nonetheless hampered by accent, tone, and external factors such as pressure and temperature variations. Physiological conditions like a cold or cough can cause an authorized individual to be rejected. Another concern is the potential use of voice recordings by an impostor to gain unauthorized entry. Voice recordings have also been noted to reveal a speaker's ethnicity, gender, emotional state, and age—all information that is best kept private.

Facial recognition relies on measurable attributes such as cheekbone and jaw structure, nose shape, and eye features, particularly the iris. Measurable quantities include color, size, shape, and precise distances between facial features. Some advanced systems account for moles and wrinkles, while others generate a three-dimensional model of the face. Commercial applications perform far better than consumer deployments such as social media photo-tagging, yet still fail to match the precision found in controlled environments. Parameters such as lighting intensity, side-on postures, eyewear, facial expressions, headgear, haircuts, and beards all impede verification. Age, injury, and changes in health can further render these devices unable to reliably verify authorized users.

In terms of uniqueness and difficulty to impersonate, the iris of the eye compares favorably with fingerprints—recognition depends not on color but on the texture of the iris. However, this method also has drawbacks: the scanning device must be held very close and very steadily to the user's face, and lighting must be stable, monochromatic, and bright. Medications and drugs can cause pupil dilation or contraction, distorting the pattern stored under normal conditions. Irises can also be faked using contact lenses, much as voice recordings can be used to impersonate a speaker. These concerns have restricted the use of iris recognition to human-supervised environments, where it serves as an aid rather than a conclusive standalone verification device (Duncan, 2013).

SSO solutions offer protection against credential loss. IT security experts caution against using a single entry point for multiple platforms and legacy applications, since access to one username-password combination could compromise multiple accounts. That concern is, however, not entirely rational, because SSO in practice is not singular in the strict literal sense. SSO is used in coordination with SAML (Security Assertion Markup Language), which is based on XML, to provide access through a user's Active Directory (AD) or Lightweight Directory Access Protocol (LDAP) profile. This authentication and verification procedure thus adds a layer of security to existing layers and also functions as an IT security auditing mechanism, tracing paths, features, programs, and directories accessed by the user. Any instance of unauthorized access can therefore be identified and addressed (Lawton, 2015). The misuse of credentials is thus a remote possibility when SSO is deployed in combination with SAML, which acts as a handshake protocol for data authorization and authentication between two clients (Lawton, 2015).

Both passwords and biometric authentication measures fall short of providing the total security increasingly sought in the digital world. Passwords and SSO techniques are weak defenses against increasingly sophisticated methods of data theft and circumvention, while physical attributes are subject to change and can be rendered useless as verification credentials. In the case of a forgotten or compromised password, it can simply be replaced. The finality of a permanently compromised physiological change is altogether different—what can be done, for instance, if a user loses the thumb used for biometric evaluation? (Duncan, 2013).

Background: SAML and Security Protocols

The basic concept behind SSO is to replace complex, multi-tiered security architectures with a streamlined approach, relieving the system of contentious security management. SSO uses cookies and SAML deployments to provide security. A validation token is received and transmitted over an exclusive, secure channel. Conventionally, many service providers employ SSL-certified server endorsements, and a corresponding cryptographic deciphering program is made available to clients via browsers. Security domains create artifacts that act as tokens, which are sent through channels to other security domains to guarantee verification. Once authentication is achieved, the tokens are removed and identification signatures are transmitted to the URL to release data, allowing client-end access to commence (Yu & Asia Pacific Web Conference, 2004).

Security Assertion Markup Language, an accepted standard for validating and authenticating data across domains, has been formalized by the non-profit organization OASIS. Through this language, security can be established between clients, domains, and devices—referred to collectively as subjects. SAML uses XML features to seek an "assertion" from one of three defined types for the data transmitted: Authentication, Authorization, and Attribution. Authentication establishes the validity of a subject through a prior encounter, which may have been realized through a hardware token, a password, or a public key (X.509). Authorization concerns whether access to data or a channel is granted or denied. Attribution denotes that the subject in question is associated with particular system attributes.

SAML is not rigid in its definitions and allows sufficient flexibility for independent systems to decide whether their security measures are effective and to deploy countermeasures in cases of unauthorized breaches arising from assertion conflicts. This approach is more accommodating in nature, allowing each domain to assert its own security strategy without disrupting the security measures of another entity with which it cooperates. Additionally, SAML can be bound together with SOAP (Simple Object Access Protocol) over HTTP (Yu & Asia Pacific Web Conference, 2004).

Authentication, Authorization, and Attribution are the three most vital assertions sought by web service providers, and SSO technology revolves around empowering clients and domains to access multiple instances safely using a single key obtained via Public Key Infrastructure (PKI). Currently, all services involving Internet Service Providers (ISPs) and Internet Protocols (IPs) validate recognition through username-password combinations. In centrally controlled administrations, Remote Authentication Dial-In Service (RADIUS) and Terminal Access Controller Access Control System (TACACS+) are used to authorize access and provide authorization information to verified users. The ideal solution would be a single access key for all web-based instances and services. That sweeping authentication has yet to be fully realized; what exists instead are largely independent, often standalone PKI solutions for each application. Despite TSL/SSL being capable of providing such features, very few services implement PKI-based user authentication. A PKI-based authentication system could be made more widely deployable by allowing ISPs to perform both validation and authorization functions (Rossebo & Olnes, 2003).

SSO Types: Web, Enterprise, and Beyond

Shibboleth is one example of an SSO implementation. It is flexible, robust, widely accepted, and favored for managing SSO. When a client attempts to access resources protected by a Service Provider (SP) for the first time, authentication is required. The SP may redirect the client to a WAYF (Where Are You From) procedure, presenting the list of credentials needed to access the requested resources. If the client selects a credentialed organization from the list provided by the SP, they are directed to the corresponding Identity Provider (IdP). Using this IdP, the client follows the SSO procedure specified by that organization. Upon successful authentication, the client is attested to certain attributes—such as username and organizational affiliation—and the browser is reconnected with the originally requested resource, now authenticated through the IdP. The SP filters these attributes against organizational access controls and, if matched, authorizes access to the client (De, 2012).

SSO is a significant driver of authentication frameworks. Simply stated, SSO is the process by which a user authenticates once and gains entry to multiple instances without further credential verification. It is of immense benefit to both system administrators and end-users. Working procedures become much simpler as recurring entry barriers are removed: only one login per day is required, and each user maintains only one set of credentials. This is bound to reflect in improved efficiency. Security administrators and support staff must manage a much smaller database of user credentials, and all authentication data is placed under central control, with identical tools, techniques, and routines for administration (Clercq & Grillenmeier, 2007).

That centralized access does introduce a vulnerability—knowledge of one data entry point could, in theory, allow an intruder to access the entire database using the same logic that made the system convenient. SSO is not advantageous solely for its simplicity, however; it also improves security. Centralization facilitates uniformity in policy across an organization. A decentralized structure is more difficult to monitor and maintain. If users must remember many username-password combinations, they are more likely to write them down or reuse weak passwords, inadvertently compromising the system. The probability of compromise is proportional to the number of credential combinations every user must manage. A quality SSO arrangement is independent of the application or platform it protects, shields its procedures from end-users, and provides the feedback required by centralized security administration (Clercq & Grillenmeier, 2007).

A common concern is that SSO credentials become the "key to the kingdom"—obtaining them grants access to all secured data. This risk can be mitigated by combining credential types. The three prevalent credential categories are: knowledge-based (passwords), attribute-based (biometrics such as fingerprints), and possession-based (smart cards or tokens). A combination of these credential types strengthens the SSO deployment considerably, and multifactor authentication solutions reduce this risk further (Clercq & Grillenmeier, 2007).

Contemporary SSO implementations treat Web and Enterprise SSO differently. Web SSO deployments provide a straightforward logon for clients accessing applications and databases through the Web via HTTP. Integrating an application with a Web SSO framework requires the application to be Web-compliant, typically meaning a multi-layered front-end architecture. This requirement is impractical for centralized legacy applications with user-controlled front ends. Web Access Management Systems (WAMS) and related global efforts now focus increasingly on Web SSO security solutions. Enterprise SSO solutions offer wider coverage, extending from Web-compliant applications to terminal service-based applications, client-side applications, and a broad range of Web-independent instances, including legacy applications and mainframes (Clercq & Grillenmeier, 2007).