It's no secret that the web access management (WAM) systems of the 1990s can't keep up with today's modern identity and access management (IAM) needs. But there seems to be some mystique--and even worry--around how to migrate away from these systems. If you follow a proven, four-phase approach, it's not as scary as it may seem. Let's dive right in...
Phase 1: Planning
During the planning phase, your existing WAM deployment and architecture is surveyed and understood. You'll take inventory of your applications, policies, authentication levels and methods and ask questions such as:
What access control policies are necessary?
What types of application integration is necessary?
Where will authentication happen?
What are your password management and recovery requirements?
After taking a full inventory, you'll create a plan for your new architecture and deployment model, rationalize session management and settings, and plan the order of your application migration.
During this phase, the order of application migration should also be determined. You should start by identifying a pilot application to test and validate the migration plan. The pilot application is taken through the migration phases to ensure that the process is understood, and you can gain confidence in the Ping Identity Platform. After the pilot application is successfully migrated, the remaining planned applications can gradually be migrated.
Phase 2: Initial Deployment and SSO Integration
Initial deployment starts with the installation and configuration of PingFederate® and PingAccess® in order to start integrating them with your existing identity management systems. During this phase, PingFederate is integrated into the existing authentication flows, which can support internal users stored in local directories or by delegating authentication to an existing IAM system. Additionally, the authentication flows can support federated identities from other organizations. Both PingFederate and PingAccess should be integrated into the existing monitoring, auditing and reporting tools available in the enterprise.
Phase 3: Application Migration
Application migration typically starts with the migration of a low-risk application from the existing identity management system into the Ping Identity Platform. Legacy access management objects and access control policies required to protect the application are first migrated. The next step is to integrate PingAccess with the application. This integration can happen through identity mappings or site authenticators in the PingAccess gateway or with the PingAccess agent deployed on a web server.
PingAccess also supports more complex migration scenarios. With PingAccess, it's possible to migrate an application with an existing legacy access management agent in place without removing the agent. PingAccess can acquire the appropriate token that the application is expecting. When the agent is removed, a simple configuration change is all that's necessary to continue to protect the application. Scenarios like this are supported to reduce the difficulties of migrating applications when the department deploying PingAccess doesn't directly own the applications. You'll repeat the migration process for the remainder of the applications targeted for migration, and the phase is complete when all applications have been migrated from the existing identity management system into the Ping Identity Platform.
Phase 4: Finalize Migration
The final step in the migration is to remove the last dependencies on your existing WAM system. Typically, this means shifting the authentication responsibilities from the system into PingFederate so that PingFederate becomes the authoritative source for authentication and takes over password management responsibilities. When all WAM dependencies are removed, the legacy access management servers can be decommissioned and recycled.