Symantec SiteMinder

 View Only

Designing a Non-Policy-Based SSO: Secure-DevOps

By kumni04 posted Apr 05, 2017 05:16 PM

  

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 

0 comments
0 views

Permalink