Now that we have evaluated the existing solution, mapped requirements and performed a gap analysis as described in my first post, Factors to Consider When Pondering a New Single Sign-On Solution, you’ll want to make sure that the solution has the best possible chance of adoption—and success. This post shares some of leading practices for SSO migrations.
Here’s a simplified reference architecture to build out the new solution:
With the latest version of CA SSO, administration tasks can be done using REST API calls. Also, new capabilities of CA SSO include REST API-based Authentication and Authorization as well as being an OpenID Provider.
Develop Co-Existence Strategy
Almost all enterprises have some form of Single Sign-On services. Will you need to support single sign-on in the interim between the “legacy” solution and CA SSO? The answer to this question will determine how the two worlds will co-exist during the parallel migration period.
If there is no need for session sharing between the two solutions, users can log in to each environment independently and use applications protected by each solution; however, users will need to authenticate multiple times—a less than optimum experience. It’s not surprising that this option is rarely chosen.
The more likely scenario is some form of single sign-on while applications are being migrated to CA SSO. This could take one of a few forms: federation using SAML, dual protection, or single protection.
Federation with SAML
One of the environments acts as the identity provider while the other is the service provider. To minimize changes to the legacy environment, it typically acts as the identity provider.
· Applications are protected by only one solution—legacy or CA SSO.
· Apps protected by CA SSO use a SAML authentication method to leverage the legacy session or login methods.
· If a user spends a long time in one legacy session, the other session may expire due to inactivity, forcing a login.
· Once all applications are migrated to CA SSO, login methods can be changed to non-SAML.
Both the legacy and CA SSO environments protect all applications. This usually means the legacy agent/web gate and the CA SSO agent/CA Access Gateway are configured to protect each application. Initially, the CA SSO policies are very basic and enforce SMSESSION (CA SSO session management cookie) validation and refreshes. The legacy policies enforce access control.
· Login processes are customized to generate legacy and CA SSO sessions, such as use of login servers with redirects.
· Policies equivalent to legacy policies are migrated to CA SSO.
· Once all policies exist in CA SSO, legacy agents can be removed. Login can switch over to CA SSO login methods.
· Both sessions are maintained during application access.
The legacy and CA SSO environments protect different sets of applications. This usually means that an application is protected by the legacy agent/WebGate or the CA SSO agent/CA Access Gateway, not both.
· Login is customized to generate both legacy and CA SSO sessions.
· Session timeouts create challenges if a user spends a long time in one session. The other session may expire due to inactivity and force a login.
The method(s) you choose will depend on the capabilities of the legacy environment. If there is no federation support, SAML or OpenID methods are not an option. Understanding the requirements will help make some of these decisions easier.
If you are interested in exploring CA SSO implementation options contact Amin.PashapourAlamdary@ca.com.
And watch for my next post, where I will discuss optimizing your CA SSO migration.