Why Single Sign-On Isn’t Enough
Single sign on has it's place but leaves a lot of IAM un-managed. Learn where it's strong, and where it's weak.
Single Sign On or SSO
User credentials for this application. Too many passwords. Lost passwords. Writing passwords on yellow stickies. Setting up user accounts again and again. You can understand why IT administrators breathed a sigh of relief when single sign-on platforms like Okta came along. Suddenly, users could login once, be authenticated, and have those credentials automatically applied to all the applications, websites, portals, and other IT services they needed to access in any department or location.
One set of credentials to remember. Instant access to everywhere a user needs to go.
Life got a lot easier for users. It got a lot easier for security administrators, too. What’s not to like?
Without question, single sign-on technology is a major advance in identity and access management and for IT security generally. There are fewer credentials for users to keep track of or accidentally disclose, and the IT departments gains centralized control over where user credentials are applied.
No wonder so many companies have adopted single sign-on solutions, propelling the market overall to nearly $1 billion in 2020.
But single sign-on security models have some serious shortcomings too. Let’s review those shortcomings, and then I’ll tell you how we’re addressing those shortcomings with a new software offering called Trustle.
Problems That Single Sign-On Doesn’t Fix
First, let’s agree on a few security principles.
Users should have access to everything they need to do their jobs. They should not have access to things they don’t need for doing their jobs.
In general, access should approximate a so-called zero trust model: users should get access just what they need, and by default, nobody should get anything unless explicitly approved.
If you want to minimize the risk of insiders misusing access or of hackers gaining access to a user’s credentials and doing the maximum amount of damage with them, then you want to limit a user’s access as much as possible, providing, of course, that you’ve provided the user with what they need to get work done.
These principles might seem obvious. But let’s look at the ways that single sign-on ignores them or outright contradicts them.
Persistent Access Rights Can Create a Persistent Problem
Sometimes users need access to something like a CRM application indefinitely. Other times, they need access to a database or application just for a limited period of time, such as for the days or weeks they’re working on a special project. Once the project’s over, they don’t need access. Letting them keep access after that point just creates an unnecessary security risk.
Think of the difference between permanent and temporary access rights as the difference between house keys and hotel keys. You always need keys to your house or apartment. You don’t always need a card key that opens the last hotel you stayed in. In fact, if the hotel gave guests card keys that worked indefinitely, they’d probably have a lot of problems with awkward intrusions and thefts far beyond the occasional towel tucked in a rollaway bag.
Security teams need the same flexibility in provisioning access rights for IT resources. Sometimes users just need temporary access to a resource. But there’s nothing in a single sign- on platform to handle this kind of time-based access. Temporary access has to be managed as a separate ad hoc process. It’s one more thing to go on a security administrator’s already cluttered calendar. As a result, time-based access rights usually don’t get managed at all, unnecessarily heightening the organization’s overall risk.
The need for security teams to manage temporary or optionally renewable access only makes sense in today’s enterprise with flexible team assignments, agile development projects, and increased reliance on contractors and other outsiders.
To manage this kind of access, though, security teams need something in addition to their single sign-on platforms. Current SSO solutions don’t do this. Something else needs to.
Rights and Roles Within Applications
Another shortcoming of single sign-on platforms is that they provide visibility and control over a user’s connection to an application or other IT resource, but no visibility into or control over a user’s rights within that application.
For example, Okta can provide the user Jim Smith with access to Salesforce. Using credentials managed through Okta, Jim can log in to Salesforce. But from there, the security team has lost sight of Jim and his access to data and application-specific privileges.
Salesforce, for example, supports the following roles, each with different access rights:
- Read Only
- Standard User
- Marketing User
- Contract Manager
- Solution Manager
- System Administrator
Which role did Jim log in as? Does he have read-only access, access to customer records for just the Eastern Region, or access to all customer records? If he’s normally a Standard User but temporary needs access to the Solution Manager role, is that change visible to anyone other than the Salesforce System Administrator? Will the System Administrator remember to rescind those special rights once Jim’s need for elevated access is over?
Knowing what rights a user has within an application or cloud environment is vitally important for managing risk and ensuring compliance across an organization. Unfortunately, these details are completely outside the purview of a single sign-on platform.
Introducing Trustle: Precise, Automated Entitlement Management
You can see now, I hope, why organizations desperately need something beyond single sign-on platforms for managing access rights. Single sign-on platforms streamline logins and the management of a user’s universal identity. But they do nothing to address the issue of temporary access or of access within an application or cloud platform.
The Trustle Platform complements single sign-on platforms with a needs-based approach to access rights. Trustle provides:
- Machine learning analysis and discovery of access activities across the organization, so security teams and business unit leaders can understand which users are accessing which resources and how. Acting on this analysis, security teams can revoke unneeded access rights and restrict rights that are overly broad.
- Easy-to-use workflows for requesting access, granting or revoking access, and ensuring that continued access to special resources is still needed and authorized. Trustle becomes “the place to go” to resolve access right issues, whether you’re an end user, a business unit manager, or a member of the security team. Trustle handles the busywork of remembering deadlines and coordinating emails and Slack notifications to streamline access management.
- Integration with applications, cloud platforms, and other IT resources, so that user rights within a resource can be monitored and managed in accordance with the organization’s policies and security best practices.
One area where access management is particularly critical is software development. Especially in agile DevOps environments, developers are expected to move quickly, building, testing, and deploying code. But when development requires access to special resources, agile development can become slow and halting while developers wait for the permissions they need. And after a development phase is complete, temporarily granted access might remain in place, unmonitored and eventually forgotten.
Trustle solves these problems by making it quick and easy for developers to request the access they need and for security teams to review and approve those requests, if appropriate. Development pipelines already have technology for storing, versioning, and deploying code. Now they finally get the solution they’ve been missing for entitlement management
How can Trustle help your organization reduce risks from poor visibility, manual processes for provisioning rights, and too much busywork for end users and security teams like?
Try Trustle and access the future of access management.
