Skip navigation
All Places > CA Security > CA Single Sign-On > Blog > Authors kumni04

CA Single Sign-On

4 Posts authored by: kumni04 Employee

So far, my posts have covered various aspects of non-policy-based SSO. Today, I’ll share a real-world example of non-policy-based SSO in action at a CA Technologies customer, one I consider a visionary pioneer in digital transformation. One proof point for my opinion is that the company embarked on its digital transformation journey more than eight years ago, well ahead of most other organizations.


While the user experience was the cornerstone of this digital transformation, security and release management were also top of mind for the company. It all started with an idea to provide SSO for an IApp while simultaneously decoupling the IApp from SSO policy. As you know, SSO policy requires a policy enforcement point (PEP), which is typically an SSO agent. The question became how to ensure session security without a policy-based SSO and its attendant PEP.


As we developed non-policy-based SSO, we came to see that it was a blessing in disguise—and that it can be the same for other organizations. It forced everyone to think differently and beyond just user experience. Energized by cross-pollination of teams and collaboration, we knew we were onto something bigger than just SSO. We were building and living what the industry now calls digital transformation, essentially DevOps and Agile. In this case, business was the driver, and non-policy-based SSO was the transformer.


Like the pioneers of old, we transformed the company’s landscape. We set up camp by building a completely new, modern user registration and sign-on process that simplified the user experience. We accomplished this by integrating CA SSO and CA Identity Manager with the company’s IApps. SSO allows seamless, secure navigation across the company’s web applications for its consumers, partners and employees. Even minor interface design elements, such as validating authentication codes, were held to the highest user experience standards and provide the right balance to the underlying development and operations effort. To improve business availability, we eliminated dependencies between release sprints and operations for runtime deployments, with no change in security posture.


Because SSO without session security is worthless—even dangerous—the customer, CA and IBM collaborated on building a strategy to ensure session security at all integration layers. CA and IBM enhanced their products to help our customer achieve success in its business initiative. The customer’s IApp developers worked closely with CA Services to:

  • Build an in-line web session filter to validate SSO tokens.
  • Update IApp login modules that call SSO to obtain SSO tokens.
  • Ensure that an IApp server session is generated and updated based on an SSO token and the user’s type of access.


If your organization needs assistance with its digital transformation, non-policy-based SSO may be the transformer you’re seeking. With CA SSO, an enterprise infrastructure product, you can enable centralized, secure web access management, user authentication, single sign-on, policy-based authorization and identity federation. Please comment on this post if your organization is undergoing a digital transformation—or if you have any observations you’d like to make.

Now that I’ve provided an overview of a non-policy-based SSO in my previous two posts (links below), let’s talk about designing the solution. As with any software deployment, enterprises need to make numerous design decisions with an #SSO architecture and consider the benefits and tradeoffs of each decision. Paramount to making wise decisions is that the underlying technical design, security and DevOps meet your business objectives. For successful digital transformation tied to an SSO-enabled IApp, I put design decisions into three categories:


User Experience: A great user experience is key to digital transformation. Depending on the business and type of IApp, the user’s login process could be interactive (the user enters credentials), non-interactive (the user’s computer’s credentials are applied behind the scenes) or transitive (access to one application gives access to other applications). The benefit is a login process that is greatly simplified by integrating an identity management solution such as CA Identity Manager (CA IDM) with the IApp and CA SSO. Such integration also allows a common password service for all IApps. To ensure a good user experience (not to mention increase productivity and reduce operating costs), Identity Management, SSO and the password service must always be integrated.


Release Management: You want to ensure that the IApp release sprint is as independent of SSO infrastructure changes (components and policies) as possible while meeting required security and other business demands. That’s easily done by extending the IApp package to include the required SSO-enabling libraries such as CA SSO SDK. The benefit is that IApp code is SSO-ready and release sprints (#Agile) are independent of agent deployments and SSO policies, enabling IApp scalability without dependence on agent scalability.


Security: Focusing on session security, if no valid SSO token is available, there must be a login action (interactive or non-interactive) to generate a valid application session and access private areas. For public areas, the application session is upgraded to a private area application session when a valid SSO token is available, enhancing the user experience and personalization. In the design we must consider mitigating against security attacks such as session replays, cookie forging, velocity attacks, cache poisoning, SQL injection, etc. And by the way, a good and complete logoff, referred to as single logout (SLO), is equally important.


Another benefit of the non-policy-based model is that it forces us to be more vigilant about session security—to close the loop and adjust application code for security. We must know the IApp’s native security and the underlying application server’s security framework. In a non-policy-based SSO model:

  • A light session filter can be written to validate SSO tokens.
  • Application login modules can be updated for calling SSO to obtain SSO tokens.
  • Application server properties can be configured to generate a valid user session contingent on the presence of a valid SSO token.


Developing and implementing the above with CA SSO is even easier, since CA SSO SDK, CA SSO Application Server Agent and CA SSO Session Linker can be combined to tighten security. Implementing a session store and integrating CA SSO with CA Advanced Authentication can help mitigate session replay and velocity attacks. Using CA’s #Veracode suite of products, you can scan your IApp code to identify code issues that may otherwise expose you to cache poisoning and SQL injection attacks.


A tradeoff: The first time an IT organization moves to a non-policy-based model, it’s a challenge to adopt it, because the model involves teams beyond the IT organization’s local control. Organizations need to make a conscious commitment to the change, and they need to work with developers they may not have worked with before. To be successful, non-policy-driven SSO requires code-level customization for the IApps, which is not very complex. Once you do it the first time, you have a method and a framework unique to your organization, and you can replicate it for 90% of your apps. The most difficult part of the journey is getting over the first speed bump; after that, it’s a much smoother ride.


But even with that tradeoff, given the focus on #SecDevOps and the need for organizations worldwide to take ownership of internal cyber security, a non-policy-based SSO model provides a more flexible, agile, secure and scalable approach for enabling digital transformation.


Post #1: Getting Back to Basics with Single Sign On 

Post #2: A Primer on Non-Policy Based SSO 

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?

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.