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 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 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.