Is your organization considering a new single sign-on solution? Before you do anything, you may want to read this guide to successful migrations. The first topic we’ll handle are the preliminary steps you should take to determine if the migration is the right move for your organization.
A well thought-out strategy for migrating to CA Single Sign On (CA SSO) from another access management solution reaps several benefits:
- A seamless user experience
- Minimal to no disruption to user activity
- Low risk
- An accelerated pace of migration that delivers quick wins.
Of course, a well thought-out strategy requires effective planning. What considerations do we need to take into account? We’ve been involved in countless CA SSO migrations over the years, and we’ll share our leading practices with you here. One caveat, though, before you use this as the guide to end all guides: Your organization’s environment has unique variables that must be factored in before performing this migration.
Here’s a general view of the process:
- Evaluate the existing solution
- Map requirements and perform gap analysis
- Build out the new solution
- Develop co-existence strategy
- Develop and execute application migration strategy
Step #1: Evaluate the Existing Solution
You can glean a lot of information from the current solution: existing requirements, login methods, authentication and authorization load, and audit reporting. Discovery elements include:
- Evaluate the solution design documentation
- Interview stakeholders, application owners and users, and security administrators
- Understand average and peak transaction volumes for logins and authorizations for sizing the new solution
- Analyze existing application protection needs:
- Login methods
- Coarse- or fine-grained authorization
- Roles, group memberships, or user attribute values needed for valid access
- Data needed by application in cookies, headers, etc.
- Current processes for on boarding applications
Step #2: Map Requirements and Perform Gap Analysis
This phase maps solution requirements and use cases to out-of-the-box (OOTB) features of CA SSO. (A few use cases will be beyond the scope of CA SSO’s OOTB capabilities.)
Here’s a sample mapping table:
Use Case Number
Uses uid attribute from LDAP directory
Specified in Agent Configuration Object
Java SDK and CA SDK needed
Multi-factor authentication using mobile OTP
Requires integration with CA Advanced Authentication
Existing policies or protection schemes can also be analyzed to generate requirements for protecting each application when using CA SSO. These requirements can be used to create policy definitions:
- Application resources to be protected (path, URI, etc.)
- Web server(s) hosting application
- Authentication method required for user identification (login form, multi-factor, certificate, token, windows session, etc.)
- Authorization method for validating user entitlements, group membership, user attribute values, etc.
- Special considerations in determining user access—network location, time of day or week, etc.
- Policy server
- Data stores: policy store, user store(s)
- CA Access Gateway and/or web agents
- Administrative UI server
All this information is mapped into equivalent configurations on the CA SSO side.
If these first two steps tell you that your organization will benefit from a new single sign-on solution, I hope you’ll read my next post highlighting co-existence and build out of the new environment, which will be available next week.