Scrutinizing Single Sign On: Superior Security, but with Stipulations
When facing the question of how to manage identity and access control for an entire organization composed of thousands (or even just dozens) of users and a similarly large number of enterprise applications, the idea of centralizing that management through the establishment of Single Sign On authentication against a central identity provider is quite attractive. But there are some caveats worth considering. Some specific single sign on stipulations, if you will.
A Scenario
Assume there’s a large organization of over 10,000 users with nearly 1,000 total separate applications to which different groups of users in the organization need access. Let’s consider some different approaches to identity and access management (IAM) that could be taken by the organization’s IT department.
The Free for All Approach
On the one hand, IT could let every user manage their own login credentials for all the apps that they use, and simply trust that they are doing things like setting up multi-factor authentication for each of their accounts, not reusing their passwords across applications, storing those passwords somewhere securely, and generally using secure, high-entropy passwords that are hard to crack. If the average user needs to manage a ton of different credentials for all the applications they use, they’re more likely to reuse credentials for the sake of convenience, particularly if they’re not using a password manager (e.g., LastPass) that abstracts that problem away from them. Moreover, IAM has no central way of enforcing any standardized settings or policies on the accounts if each user is independently responsible for their own and each service uses its own local store for identities and roles. It’s also worth noting that this distributed, user-trusting approach also implies a need to trust the service providers (the various applications) to provide secure authentication mechanisms like MFA, but this is not always a guarantee. These factors inherently increase the risk of compromise not just for each user account but for the organization since a crack in a user’s online identity is a crack in the organization’s online security. Repeating for emphasis:
A single-user vulnerability is an organization vulnerability.
With this model, each application or service into which users in the organization need to authenticate needs to be independently managed. Someone needs to own and be responsible for managing users, groups, and access for each service; it may be the case that each one has its own technical application manager(s) from the organization’s IT department and that person manages those things as well as other settings for the service. Even if a service does have a technical owner who manages it, they need to stay on top of provisioning new users, deprovisioning users who no longer need access, assigning proper roles to users, helping users with authentication and authorization problems, and more, all on top of any other IT responsibilities they may have. It’s easy to see how, especially when scaled to a full organization of many users and many services, this fragmented approach to IAM easily allows for each service to potentially diverge from the central identity store for the organization. This manifests as users maintaining access to things they should not have access to, users who can no longer access their accounts because their account service request hasn’t been addressed by an overwhelmed application manager, users who don’t have the right role(s) assigned so they can log in but not do their job, etc.
A byproduct of fragmented IAM is the front-facing service desk for the organization’s IT department receiving calls and support requests which then need to be processed and routed to IAM (or the application manager for the app in question), where that time could instead be spent addressing other less avoidable problems.
In the long run, distributing account and security management across the user base doesn’t come with the expected time-saving advantage of distribution; rather, it opens the door to a lot of potential service requests and tickets around addressing the effects of irresponsible, independent account management. More importantly, one can think of distributing that account security control as widening the attack surface of the whole organization without any counterbalancing benefits, since allowing more users to generate and/or reuse insecure passwords across their accounts equates to allowing more vulnerabilities to manifest that external attackers can exploit. There’s also the factor of the users themselves having poorer experiences overall since they have to stay on top of securing all of their accounts.
The Centralized Approach
Now, assume the organization is beginning a project focused on migrating all of its enterprise applications to Single Sign-On (SSO) with a cloud identity provider like Azure Active Directory, such that rather than each user managing their own various sets of credentials (however secure, insecure, or reused they may be) for each of their apps, each user will now use a single set of account credentials associated with their central identity stored in Azure AD to log into every SSO-enabled application (the key phrase being SSO-enabled).
Advantages
With this approach, the IAM team can leverage Azure AD, the identity provider, to enforce policies around password security ensuring that every user is using a password that meets some set of criteria. They can also enable a policy requiring MFA on every user account to add an additional layer of security around each user’s identity, and consequently around the organization. Moreover, by setting up the applications to use SSO with Azure AD, the IAM team can also leverage audit reports and alerting to query and know about potentially compromised identities and take appropriate defensive actions. For example, they can now look at the sign-in logs for an SSO-enabled financial data application from within Azure AD and see that user X, an employee of the organization who is based in South Carolina, appears to have logged in from an Indonesian IP address mere minutes after logging in from Charleston, SC. The timing of the strange login plus the nature of the application in question would indicate a problem, so in response, the IAM team could take appropriate action to secure that account.
An additional major component of establishing and maintaining SSO configurations within a central IdP is the ability to easily manage access control through the simple assignment of users and groups to the applications (formally service principals in Azure AD) to which they need access. Part of that assignment also includes the mapping of roles to those users and groups being assigned such that we can achieve more robust role-based access control (RBAC) for each application, which ultimately contributes to better alignment with the principle of least privilege. For example, a small group of application administrators (“ExampleApp-Admins”) might be given the “Admin” role for an “ExampleApp” application, whereas a more general group of users (“ExampleApp-Users”) might be given a “View” role with read-only permissions for the same app. Azure AD would allow the IAM team to define custom roles as required by each individual application, and these roles would be sent over as claims for each user during their authentication process, which the service provider would consume to behave accordingly.
On that same note, deprovisioning users — that is, removing users’ access to resources upon their leaving the organization — becomes much easier when all or most applications are tied to a central identity provider. Assuming that user account deletion or deactivation is part of the offboarding process for the organization, then when a user leaves the organization, their access to the apps and services behind SSO gets revoked. If the user is simply moving between departments or offices rather than leaving the organization, and changes like this are reflected by updated group memberships in the IdP, then the user’s current access is always reflective of their current role in the organization. There’s no need for an army of app managers to go out into each of their applications and independently update disparate lists of users every time the org chart changes.
By connecting all or most enterprise applications to a centralized identity provider like Azure AD through SSO, the IAM team obtains benefits like increased control over individual account security and increased actionable visibility of identity-related problems and compromises across the organization. However, this also implies the need for much more extensive management and monitoring of identities and access control. This isn’t really a bad thing, of course; large organizations should certainly be managing those things well to stay secure.
Catches to Consider
In some cases, particularly when staffing is low, it can be difficult for a central IAM team to stay on top of setting up and managing a complex environment of identities, enterprise applications (service principals), roles, and SSO configurations. The setup process often involves time-intensive tasks like:
- Correspondence with the vendor development and support teams behind applications and services being integrated with the IdP
- Possible financial negotiations with those vendors. Some SaaS vendors actually charge outrageously to enable SSO integration on behalf of the organization, which then turns the situation into a financial question that may even lead to SSO being skipped for certain apps. On that note, check out this SSO Wall of Shame maintained by Rob Chahin; it lists “vendors that treat single sign-on as a luxury feature, not a core security requirement”
- Custom in-house development of SSO integrations for applications or services that were built and deployed in-house (contrary to SaaS)
- Building out the RBAC map for the app as well as creating and populating new groups in Azure AD based on that map — What are the resources and roles? Are they documented? If not, someone with semantic knowledge of the app and how it works needs to provide the roles. Who in the organization needs access to which resources in the app? Are the groups static? If they’re dynamic, what’s going to drive the memberships? When should they be updated?
- Extensive testing; speaking from experience, this is especially true if migrating from another form of authentication (e.g. CAS) — you don’t want to mess up any existing accounts or active business processes relying on the app. This should involve a lot of communication with the functional users of the app, with specific focus on users with uncommon account properties, e.g., usernames or email addresses that have changed. We’ve seen enabling SSO create problems for such users on multiple occasions. It primarily comes down to knowing which IdP claims on the user are being mapped to which local user attributes within the application during the sign-on process.
Of course, in some cases, especially when legacy software services are still in use by the organization, the vendor may not even offer an SSO integration. If one considers that the point of enabling SSO through a central identity provider is to provide end users with a consistent, uniform login experience across many different applications, it can get confusing for users when some apps are using SSO and others are not.
To provide another catch, the underlying idea of SSO — each user managing one set of account credentials to authenticate into all SSO-enabled apps — implies that if a user’s central identity does happen to get compromised, all of their accounts on SSO-enabled applications are at immediate risk. This really shines a light on the value of MFA requirement policies and active monitoring of identity-related logs within the identity provider whenever SSO is enabled.
The funny thing about powerful tools that offer tons of visibility and control (e.g., Azure Active Directory) is that they require a lot of attention. Uncle Ben said it best when he said “with great power comes great responsibility.” For some organizations, the amount of responsibility involved in managing a complex environment of many different apps, users, groups, and roles may be too much to centralize on a single IAM team; if so, Azure Active Directory makes it pretty straightforward to let each app manager be responsible for the managing their app’s service principals in the IdP. This model makes more sense in my opinion (rather than funneling all access-related tasks into one team) since an app manager is going to know more about the specific access requirements for their app(s). In my experience working in higher education IT, the technical app manager assigned to a given app generally configures Single Sign On initially in collaboration with the IAM team such that all of the appropriate groups are granted appropriate access to the app via the central identity provider. In doing so, the app manager is able to offload the responsibility of user provisioning and deprovisioning, and both the app manager and the IAM team have central control and visibility of the app’s access settings. Of course, the app manager still may need to dig into the app’s local configuration for some things, but the app no longer has its own IAM silo. To provide a more abstract take on this,
It’s usually better for a system using data to feed from the authoritative source of that data than to maintain its own local copy.
