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?