Layer7 Access Management

A Primer on Non-Policy-Based SSO

By kumni04 posted 03-13-2017 02:51 PM


In my first post I outlined the problems inherent in a traditional policy-based SSO model. Here, I’ll give a general overview of an SSO model that doesn’t require policies—a refreshing and liberating change that solves a multitude of problems that arise in policy-based SSO models.


You’re probably thinking that a non-policy-based SSO model is best suited to legacy and simpler web applications. You can use this model in those circumstances, but my experience tells me that you will be pleasantly surprised by how easily this model adapts to newer, more advanced and complex enterprise applications. These applications’ mature authentication and authorization security framework allows integration of SSO with portals, SAP, ERP and commerce platforms, most of which have modules for managing and delivering records, transactions, data, users and content. (For the sake of convenience, I’ll refer to these apps collectively as integrated apps, or IApps.)


These integrations require a security framework that manages access to the IApps’ modules. The good news is that most IApps have their own pre-defined security framework for authentication and authorization. An IApp’s security framework is generally closed, which means it has a built-in model for enforcing access control and controlling the user’s digital experience, an underlying security database against which it provides fine-grain access in the IApp. As a result, there’s no need to create policies in SSO to regulate access; in fact, it’s simply not feasible for a third party to create accessibility policy models for IApps. If you did, you’d essentially be plunking a security model on top of an already effective security model, thus creating myriad challenges at the design and integration levels for Development, Operations and other teams. It’s simply not worth your time or money, and it will make your enterprise security framework more complex, less manageable and more difficult to maintain.


In this non-policy-based SSO model, SSO’s access control capabilities are not enforced. In other words, while SSO controls authenticating users to the IApps, it does not control access of the users within the IApps, because the IApps already have that capability, which I call native authorization.


Decoupling SSO from an IApp’s native authorization doesn’t mean that SSO can’t augment access control. Integrating SSO with risk analytics can determine if a user session carries risk, and this information is passed to the IApp, which either by itself or using other integrations, acts upon the risk. In fact, SSO can terminate the user session if it deems it too risky, thereby increasing overall security and protecting applications.


For example, let’s say a commerce portal is integrated with CA SSO, CA Advanced Authentication, CA API Gateway and CA Payment Security. When a user tries to access your platform from a not-so-secure environment, such as an airport kiosk, CA SSO and CA Advanced Authentication pass that knowledge to the IApp, in this case perhaps an airline ticket portal, banking app or social media platform. In effect, CA Security solutions are communicating to the IApp, “This request comes from a high-risk user session.” The IApp integration with CA Security solutions either denies access, allows the user to complete only low-risk activities, or asks the user to take actions so that he/she can experience more capabilities.


That’s the beauty of a non-policy-based SSO model: It integrates SSO with advanced risk analytics and supports native authorizations and APIs without requiring its own complex set of policies.


Questions? Comments?



04-14-2017 10:47 AM

Hi Richard,


Good observation. Non-Policy-Based SSO does not negate depth-in-defense, instead it augments it. With advent of progress in application security the objective here is to eliminate redundant work for creating operational efficiency without compromising security posture for a quicker and successful digital transformation. A SSO policy as an firewall rule isn't always required, and when mandated it must be used.


My next blog, Designing a Non-Policy-Based #SSO: Secure #DevOps, in this series provides answers to your observations and discusses how to design such a solution.




03-23-2017 11:08 AM

In my opinion the presence of fine-grained authorization within apps does not negate the need for the course grained authorization provided by policy-based SSO.

One of the main tenets of security is having multiple layers of security, controlled and implemented by different organizations. Having course-grained authorization at the SSO level implemented by security administrators in conjunction with product owners provides an additional layer of security in case a mistake is made by developers implementing fine-grained authorization.

It has the additional benefit of stopping hackers who have stolen or otherwise hacked credentials from probing application code, and/or the frameworks that the application code is executing within, that the credentials would not normally have access to from a course-grained authorization perspective.

When SiteMinder was developed the problem of developers either not implementing authorization protection at all, or doing it poorly, was one of the top drivers for developing policy-based authorization at the SSO level. New authorization frameworks may have improved the reliability and robustness of fine-grained authorization, but I would be very skeptical of any claims that they are totally bullet-proof and obviate the need of course-grained, policy-based authorization at the SSO level.

I know that for years some companies have only been using CA SSO (SiteMinder) for authentication only, but in today's high risk environment I maintain that having the extra layer of security provided by SSO level, policy-based authorization is worthwhile.

03-13-2017 03:17 PM

Thank you for sharing this great info with the community Nikhil!

A Primer on Non-Policy-Based SSO