Blog Viewer

Getting Back to Basics with Single Sign-On

By kumni04 posted Mar 01, 2017 03:49 PM


Making the Complex Simple: Non-Policy-Based Single Sign-On is the Wave of the Future


As we all know, single sign-on (SSO) permits a user to access multiple applications and Web services with a single set of login credentials, usually a user name and password. Organizations value SSO because their customers, employees and partners can access only those applications that the organization wants the particular user to have rights to, thus protecting the organization’s on-premise applications and those in the cloud. SSO increases employee and partner productivity by providing quick access to organizational data across an array of devices, eliminating the need for users to re-enter credentials when switching applications during a session and allowing employees and partners to collaborate and innovate within the network. SSO also helps the organization track user activity and monitor user accounts.

Let’s take a quick look at a typical, policy-based SSO deployment. Traditionally, the simplest method is to deploy agents on the application server or web server. Agents act as gatekeepers to applications and web services, but to do their job, agents must be told who can and can’t enter. Policies, which are created in SSO and stored in a policy store on a server, define the access that agents grant to various users, typically based on the user’s role.

When a user tries to access an app, the agent weighs the incoming request against policy. If the agent decides that policy allows access to the user, the user is authenticated and access is granted. The agent also determines whether there are restrictions on the user’s access. Is a user allowed only in public areas, or can he/she enter private areas—and if so, which private areas?

As tech leaders whose organizations use SSO know, the policy-based model can quickly become very complex, especially when you add more objects to control: more applications, more and different kinds of users, more agents and servers, more user repositories, and more capabilities. With each new addition, you have to rejigger the policies that drive the SSO platform—or worse, layer on new ones. There’s no end to the potential number of layers.

With more layers of policies, you get an increasingly complex labyrinth that’s more difficult to maintain and sustain. Those difficulties lead to cost increases due to additional resources and higher operational overhead.

What’s wrong with this picture? Sooner or later, the policy-laden SSO system becomes more complex to manage. It’s a scenario I’ve seen organizations come up against and in my next post (coming soon) I’ll propose a solution to this situation.

In the meantime, please add your comments if this scenario sounds far too familiar.  

1 comment