Migrating applications is actually an onboarding exercise. You’ll need to define the resources that are protected for an application, assign agents or CA Access Gateway proxy rules, determine a login method for the applications and access rules, and map those rules to user roles and/or groups. Sometimes interim policies or login methods are employed during the parallel phase and disabled or discarded once the end state has been achieved.
Bill of Materials
For each application to be migrated, a bill of materials needs to be created to onboard the application to the new security infrastructure; for example:
- Use cases to be covered for each application
- Inventory of protected resources (URLs)
- Inventory of current web agents involved
- Authentication methods needed
- Step-up flows
- Authorization policies by URL grouping rule groups (for large number of applications, it can reach into 100s per group)
- Response header requirements by rule grouping - response groups (some applications may get more headers than needed, but it makes operations a lot faster)
- Admin users and roles/use cases
- Federation requirements
- Session timeout requirements
- Session store and session customizations; e.g., storage and retrieval of session-specific data outside of standard supported ones/user store schema elements for a session
- Session assurance feature, if needed, and which URLs will need it
Once the bill of materials is created, mapping to configurations needs to occur to accomplish migration of functionality specific to the target application(s).
Prioritization of applications to be migrated can be based on a number of factors. To mitigate risk, migration can begin with simpler low-profile applications and graduate to more complex higher-profile applications.
In all strategies, URL schemes are critical criteria for isolating change scope. Common approaches include:
Migrating application by application:
- Select application(s) protected by a set/cluster of related web servers.
- Limit scope further by migrating one set of URL schemes.
- Partitioning by domain name might be possible based on URL/domain hosting strategies used in current applications.
The fallback strategy becomes easier if web server/CA SSO agents are deployed in parallel and Layer 4 load balancer is used to graduate applications into production.
Migrating by business unit:
- All applications servicing a business unit may be migrated in one phase.
- Business units with smaller footprints could be targeted first.
Migrating by user-specific communities (e.g., new net benefits users, technical users or accounting users):
- Migrating smaller audiences at one time contains the change impact to a smaller portion of the user population.
For all strategies, change management plans that cover business processes, technology, communications, operations and training of involved constituencies are required for optimal adoption.
Identifying Pilot Applications
Identifying the pilot applications to be on-boarded is crucial to ensuring a quick win and laying the foundation for successful long-term expansion of the solution.
The two most common approaches for a pilot are:
- User communities: Build a solid single sign-on infrastructure and slowly expose the infrastructure to a single user community. Historically, the most common starting point has been internal users, then expanding to partners and finally customers/Internet users.
- Key web application/site: A key revenue-generating or cost-saving initiative, such as an e-commerce application, partner extranet, or employee intranet, often drives the need for a web single sign-on solution. Starting here can be effective, as it accomplishes a key business initiative while establishing technical requirements and a central security framework for the larger implementation.
If you are interested in exploring CA SSO implementation options contact Amin.PashapourAlamdary@ca.com.
And watch for my next post, where Six Considerations for Accelerating a CA SSO Implementation.