The practice of Identity and Access Management (IAM) introduces many questions about an organization’s business processes and technology solutions. The decision to use a particular Single Sign-On (SSO) technology takes into account concerns such as:
- Is the technology secure?
- Is the organization affected by data privacy laws such as General Data Protection Regulation (GDPR)?
- What is the organization’s rollout plan?
- Do the cost savings from centralizing authentication into a single location outweigh the sunk cost of implementing SSO?
The decision is not only made in the context of a MindTouch site deployment, but also takes into account how all user identities and applications across the organization will be affected. As an integration point for both SAML SSO and OpenID Connect, MindTouch provides recommendations regarding which of these two supported SSO technology paths are best suited for a MindTouch solution.
The definition of the SAML SSO (Security Assertion Markup Language) specification predates OpenID Connect by many years. SAML SSO was developed to provide an authentication workflow that centralizes the sign-in experience into a single portal, while establishing trust between the portal and all applications through strong cryptography and digital signatures. The result is an identity and access management solution that reduces an organization’s IT costs and minimizes potential breach points.
SAML SSO has some significant limitations. The specification was developed before the proliferation of native mobile applications, therefore the authentication workflow is limited to locations that only web browsers can access such as websites and web applications. SAML SSO also lacks an intrinsic data transfer and storage consent mechanism.
Applications redirecting users to an organization’s Single Sign-On portal cannot include the details of which user identity items need to be shared with the application. As a result, a user is not informed of what identifiable information is being shared with the application. This lack of transparency may be acceptable between an organization’s employee and the applications deployed for the workforce but quickly becomes problematic when handling consumer identities.
SAML SSO is an arguably complex and extremely verbose specification to implement. It is possible to implement the specification incorrectly, leading to long development cycles or poor application security. It is never recommended to build your own SAML SSO identity provider software, but rather deploy a solution from a reputable identity provider vendor such as Okta, OneLogin, or Ping Identity.
Pros of SAML SSO
- Open standard
- Highly reliable and secure when implemented correctly
- Most common solution available in the market
- Provides an encryption and signature verification mechanism in the event that an HTTPS connection is unavailable or compromised
Cons of SAML SSO
- Complex XML-based schema and specification
- Limited to websites and web applications
- Lack of user identity data transfer and storage consent
OpenID Connect is the latest Single Sign-On specification of the OpenID Foundation. The OpenID Foundation’s earlier SSO specification, the OpenID Authentication Protocol, failed to succeed as an adopted standard as it shared some of the complexities that SAML SSO has been criticized for, while not delivering any improvements.
The current specification, OpenID Connect, is built upon a proven authorization protocol: OAuth 2.0. By leveraging the OAuth 2.0 protocol, OpenID Connect provides the mechanism allowing applications to include the details of which user identity items need to be shared with the application. As a result, an OpenID Connect-powered single Single Sign-On portal can provide an identity data transfer and storage consent agreement, privacy policies, or terms of service for the user to review before continuing the Single Sign-On flow.
The OAuth 2.0 protocol is not limited to websites or web applications, therefore OpenID Connect is not either. If your desire is to personalize the consumer experience, based on consumer identity, across web-connected products and applications, OpenID Connect would be a sound future-facing technology decision.
Though the specification is less verbose and simpler than SAML SSO, it is not recommended that you build your own OpenID Connect identity provider software. Consider deploying a solution from a reputable identity provider vendor such as Okta, OneLogin, or Ping Identity.
Pros of OpenID Connect
- Open standard
- Works with native mobile applications or IoT devices
- Includes a mechanism for user identity data transfer and storage consent
- Relies on HTTPS for encryption and trust which greatly simplifies implementation
- Uses industry standard JSON Web Tokens (JWT) to store and verify identity data
Cons of OpenID Connect
- Less common solution in the market (as of 2019) resulting in less industry knowledge of best practices
- HTTPS is the only layer of encryption and trust between an application and identity provider. In the exceptional case of a compromised TLS/SSL certificate authority, the Single Sign-On integration should not be trusted
Choose Single Sign-On Technology Wisely
Adopting an open standard for a Single Sign-On solution is never a bad technology decision. In general, a successful Single Sign-On rollout across an organization greatly enhances the workforce’s productivity by removing the burden of multiple application username and password combinations.
An organization’s IT department can spend less time meeting security compliance and identity governance requirements by reducing the surface area of systems that require auditing. Reducing the number of systems that store user identity data or credentials also reduces potential breach points if these systems are ever under attack from malicious actors.
Finally, centralizing the storage of consumer identities, and providing this data to applications such as MindTouch, provides both an opportunity to personalize the end-user experience of the application as well as an audit trail of where and how consumer identity data is shared.
With the shadow of GDPR falling over nearly all aspects of an organization, the ability to know where consumer identity is stored within an organization’s systems can result in faster responses to consumers’ GDPR subject access requests.