Why SSO is Only Part of Multi-Cloud Identity
Single sign-on — SSO — is still necessary, but it’s not enough on its own with multi-cloud
Over the past couple of decades, single sign-on (SSO) has become the de facto security solution for most companies. One reason is that it’s convenient for users (so they actually do it). Also, it improves organizational security by reducing account and password proliferation.
The need for SSO grew out of the growing struggle to manage identities for multiple applications. Each application had its own authentication system with its own user IDs and passwords. This redundancy caused unnecessary duplication for IT administrators and a lot of headaches for end-users.
SSO is also a great way to roll out advanced identity capabilities like multi-factor authentication (MFA) and self-service user management. While there’s no doubt that it is a critical pillar of identity management, SSO is only part of multi-cloud identity management.
What is SSO?
Single sign-on (SSO) is, in simple terms, authentication software that allows a user to sign in once and get in everywhere. It’s like having the code to unlock a door of a building and then all the other doors inside are open for you to enter. No key or code needed to access all the things you need.
Similarly, SSO allows you to log in one time with one set of credentials, and then you will not be asked to log in again for accessing applications typically with the same organization and same risk level. The objective of SSO is twofold: to make the authentication process easier for the end-user, and to ease the burden of managing authentication for IT teams.
Are there different types of SSO?
There are different types of SSO and even more choices for an SSO software vendor. Two broad categories of SSO are:
- Federated SSO (standards-based) SSO between multiple organizations
- Web access management SSO (Monolithic) which sits between the user and the application
- Enterprise SSO, includes SSO with desktop apps
- Cross-domain SSO authenticating different application domains using the same session without re-authenticating
Most commonly, SSO refers to federated SSO, the process of enabling third parties to access secured passwords so that a user only has to log in once.
How does single sign-on work?
Single sign-on software works based on a trust relationship. One set of sign-in credentials, usually a username and password, once validated, gets the user access to all their accounts and applications because the authentication is trusted.
That’s because the companies providing the websites have infrastructure that SSO is a part of what’s called a federated identity management system — or identity federation. A federation solution is an intermediary that communicates between the user and the account. It provides access tokens asking the user to verify their identity.
How is SSO implemented?
Implementing SSO depends on the type of single sign-on solution you choose. To implement SSO, an open standard framework called Open Authorization (OAuth) is needed. OAuth uses a token-based authorization that allows third-party services, like social media accounts, to connect with the user account credentials but keeps the password from ever being exposed. Authorization flow refers to how the third party receives the token.
To implement single sign-on a trusted, central server is required. When the user signs in for the first time, the central server stores that cookie that has just been created. So each time that user needs to use an application, they are already logged in.
The pros and cons of SSO
SSO is built on trust. Users enter their credentials once and gain access to many applications without having to authenticate to each application. Solutions, such as Okta and Microsoft Azure Active Directory, have become well known for providing access management platforms that coordinate authentication across multiple SaaS applications.
Pros of SSO
Users authenticate once to the SSO portal and are presented with a menu of authorized applications. This solution has simplified authentication to multiple applications for both users and IT administrators.
There are many SSO solutions to choose from and implementation is straightforward and inexpensive. SSO has been integral to the growth of cloud computing because it keeps users and organizations safer by diminishing the number of access points bad cyber actors can get in.
Cons of SSO
However, the landscape for identity management has become more complex as the Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) markets have exploded in recent years. Amazon Web Services (AWS), Microsoft (Azure), and the Google Cloud Platform (GCP) now work side-by-side with a company’s existing IT infrastructure. The result is that nearly all organizations have become multi-cloud. With this new multi-cloud reality come new identity management challenges requiring a multi-cloud strategy.
What is SSO software vs an SSO solution?
Single sign-on is a framework, and it is also software. Generally, when people say SSO solution it means the same as software. However, if someone is talking about an SSO solution, it would be best to dig deeper into their intended meaning; they could also be talking about an SSO solution as in the concept of single sign-on solving their security challenges.
Is SSO secure?
People often ask if SSO is secure. Broadly speaking, yes, SSO is secure, but there are factors that can hamper the security prowess of the single sign-on process.
Multi-clouds present different challenges for identity management
We now have multiple silos of identity vendors and multiple cloud platforms. Each cloud comes with its own built-in identity system.
When companies adopt a cloud platform, most still have a mix of old on-premises apps and identities to work with. The conventional notion of centralized identity management doesn’t work across siloed multi-cloud environments. So the implementation of consistent policy and identity impossible.
Complex organizations often require specialized identity models that represent their user’s specific needs within the business. A one size fits all approach does not work and centralizing identities breaks that model. Additionally, mergers and acquisitions (M&A) often require specialized identity management use cases through the merger integration.
Technology constraints for multi-cloud identity
From a technical perspective, organizations often choose different technology platforms, like Java or .Net, that become deeply entrenched in the organization. Forcing developers to use one platform over another because of identity constraints is not practical. It can also introduce delays and additional costs to software development.
Another consideration is that legacy SSO predates many of today’s standards like SAML. This means there are many applications that are locked into their current legacy SSO architecture.
We’ve seen that 75% of on-prem Java/.Net custom apps are integrated with CA SiteMinder or Oracle Access Manager (OAM). Applications that are hardcoded to use these identity systems must be rewritten if they want to use newer SSO identity solutions.
The need for distributed identity management
Distributed multi-cloud architectures require distributed identity across multiple clouds. Apps that work across Azure and GCP, for example, need consistent identity across both domains to provide secure access to all users.
With so many identity silos and domains, it’s really hard to get a handle on the best approach for multi-cloud identity. The use cases are different for multi-cloud versus traditional SSO. There is a need to manage consistent identity and access policies across platforms. Yet, today’s SSO solutions are limited to the apps that have been integrated with a particular identity system. There’s no easy way to set policies across all identity domains, making multi-cloud identity management impossible.
The answer to this coexistence challenge lies in extending secure access from on-prem apps to the cloud by linking on-prem identity with cloud identity. The solution must span across SaaS applications to on-premises applications. Today, SSO only works in the cloud OR on-prem — not both. The solution must also gracefully migrate on-prem apps to the cloud without rewriting or touching them. In other words, an app must be decoupled from its old identity system and layered onto a new identity system — all transparently for users.
The solution is distributed identity via an Identity Fabric
An Identity Fabric is a distributed identity management framework. An identity fabric orchestrates, abstracts, integrates, and discovers identity data across multiple systems (identity domains). It orchestrates identities and policies in distributed identity domains. Then, it presents that identity data consistently to hybrid identity Infrastructures and multi-cloud infrastructures.
SSO & multi-cloud identity: key points to know about an Identity Fabric
Here are some other key points to remember. An Identity Fabric:
- is an abstraction layer that lets you build and run your apps on the cloud of your choice using the identity system of your choice
- isn’t another Identity Provider (IdP) or SSO solution
- uses zero code integration that avoids custom coding
SSO is an important part of your multi-cloud operation. However, new challenges have come up when trying to manage multi-cloud and hybrid cloud environments. This is because of the difficulties of succeeding with secure hybrid access. Each cloud platform has its own identity system. Each application has its own identity system. SSO was designed to help manage multiple identities for multiple applications and is still relevant and needed.
Yet, the challenge of consistently managing identities and policies across multiple cloud platforms exceeds the scope of SSO. A new solution that moves away from a centralized identity approach to a decentralized approach is needed. A decentralized (or distributed) approach is made possible through an Identity Fabric and gives you the flexibility to migrate and manage identities on your timeframe.
Learn more about Identity Orchestration.
[Updated June 1, 2021]