RSA Access Manager Migration Guide

Web access management (WAM) systems have been a part of enterprises for decades. It’s critical to control access and audit applications while reducing the friction for users to interact with applications.

As business has shifted and changed in the Internet era, identity and access management systems have to change and grow to support new use cases. Traditional IAM vendors have been challenged to respond in a timely manner to these changing business requirements. Ping Identity® offers the solution with Identity Defined Security to extend and replace traditional IAM vendor products.

Ping’s products are designed to provide a simple migration strategy from traditional IAM solutions. PingFederate® and PingAccess® integrate with RSA Access Manager to facilitate the transfer of applications without disrupting your end users. The transition from one system to Ping can happen on a timeline that supports your business.

A typical migration to the Ping Identity Platform involves the four phases discussed below. We recommend contacting one of our Platinum Service Partners to assist and guide your organization through the migration process. Information regarding a Platinum Service Partner can be found at https://www.pingidentity.com/en/partner-network.html. 

PingFederate Installation

To install PingFederate, find the document here.

PingAccess Installation

To install PingAccess, find the documentation here.

PingAccess Integration with PingFederate

Connect PingAccess to PingFederate for authentication by following the documentation located here.

RSA Access Manager Integration

RSA Access Manager Integration leverages the authentication and session management features in both environments. There are two approaches to this, and depending on your deployment needs, one or both might be used at different stages of the migration. Read about the two approaches on the following pages.

Option 1: Leverage RSA Access Manager
 

In its existing deployment, RSA Access Manager is likely the entry point for users in the system, dictating how authentication is performed and creating sessions once successful. The PingFederate and PingAccess infrastructure can leverage this authentication point by using the PingFederate WAM Integration Kit. This approach is a good way to try some of the PingAccess access control and session management capabilities without impacting the majority of applications or network infrastructure.

Consult the PingFederate WAM Integration Kit documentation for detailed steps on how to deploy it.

Once the PingFederate WAM Integration Kit is deployed, RSA Access Manager sessions are created or updated when accessing applications protected by PingAccess. From that point on, if the user accesses applications using only a PingAccess session, there’s a risk of the RSA Access Manager session timing out. To prevent this behavior and effectively centralize the sessions, employ a ‘session keep alive’ rule or site authenticator to ensure that the RSA Access Manager session is periodically ‘refreshed’ by calling a test resource on the user’s behalf. Any updates to this session (i.e., new cookie values returned in a SetCookie HTTP response header) should be relayed back to the browser.

A summary system architecture diagram of this WAM migration phase is depicted below:
 

Option 2: Token Mediation
 

An alternative to leveraging sign-on interfaces in RSA Access Manager is to migrate those to PingFederate as the sole entry point into the system. PingFederate provides a full-featured username/password sign-on mechanism, known as the HTML Form Adapter, and it easily connects to existing directory servers. This may be supplemented with other sign-on mechanisms such as Integrated Windows Authentication (IWA) and strong authentication (i.e., PingID, X.509 certificates, third-party OTP tokens, etc.).

When a mix of PingAccess and RSA Access Manager protected applications exist in the environment, token mediation can be used to ensure a seamless end user SSO and session management experience. In this configuration, the PingAccess gateway exchanges its own web session cookie (known as the PA token) for the target RSA Access Manager session, which is presented to a back-end web server on which an agent
is still deployed. This may be most convenient in a phased migration when a majority of the applications are protected by PingAccess, but pockets of applications still exist that have third-party agents installed on their supporting web server that are difficult to remove.

Details of a typical token mediation are presented in the PingAccess documentation.

The token mediator site authenticator provides this capability in PingAccess and depends on the PingFederate STS with appropriate token generators installed, such as the WAM token translator. View the documentation here.

A summary system architecture diagram of this WAM migration phase is depicted below:
 

The first step in migrating an application from RSA Access Manager to PingAccess is to ensure that the required integrations are complete and that PingAccess can provide the necessary identity information to the application. The next step is to create the PingAccess rules that enforce access in the same way that RSA Access Manager enforces access.

The final step is to select the architecturally appropriate deployment option. Appendix C highlights a sample migration scenario from an agent- based architecture into either a gateway-based or proxy architecture.

Migrating Application Protection to the PingAccess Gateway

The first step is to determine if the application will continue to require the RSA Access Manager Cleartrust SSO cookie. If it’s still required (for example, if the RSA Access Manager agent will remain on the target web server), you configure token mediation so that PingAccess will acquire a target token on behalf of the user.

Next, you configure the application in PingAccess, defining where the protected web server resides, how it’ll be exposed via the gateway, what the required web session management controls are, and how end user identity details will be passed down to the application if needed (i.e., HTTPheaders using identity mappings).

Then you define your access policies using rules that are equivalent to (or a simplification of) those employed in RSA Access Manager.

Last, you configure network routing to start sending request traffic to PingAccess instead of the application.

Migrating Application Protection to a PingAccess Agent

In scenarios where an agent model is still preferred, the PingAccess agent replaces the existing RSA Access Manager agent.

You should start by defining the application details in PingAccess, including virtual host and path information, web session management controls and how end user identity details will be passed down to the application, if required (i.e., HTTP headers using identity mappings). The agent bootstrap configuration must be defined in PingAccess, and produces a configuration file the agent plugin will read on the target system.

Next, you define your access policies using rules that are equivalent to (or a simplification of) those employed in RSA Access Manager.

Once configured, you uninstall the RSA Access Manager agent on the target web server and install the PingAccess agent.

Documentation for the agents can be found here.

Deploying New Applications

Any new applications protected by the solution should be deployed behind PingAccess. They immediately benefit from the lighter weight integration and combined web and API access management features that PingAccess provides. While a gateway-based implementation is recommended to simplify ongoing maintenance, agents can be installed where required in order to accommodate existing deployment models. 

Authentication Migration

The final phase of the migration is to remove any remaining RSA Access Manager dependencies. If authentication responsibilities haven’t been transferred to PingFederate, finalize those changes first.

Move the authentication policies and methods to PingFederate in order to provide the same security, experience and functionality that existed with RSA Access Manager.

Application Migration

As applications are migrated to PingAccess for protection, RSA Access Manager agents could still be left in place. It’s critical to work with the application owners to remove those agents before RSA Access Manager is decommissioned. As agents are removed from applications, configuration should be updated in PingAccess to provide the applications the necessary information.

When the final application requiring RSA Access Manager Cleartrust Tokens is migrated to PingAccess, you remove the token mediation configuration.

Final Migration Steps

The last steps are to remove any mechanisms for synchronizing sessions between RSA Access Manager. Finally, RSA Access Manager can be shut down and the servers can be recycled.

The migration to PingFederate and PingAccess is now complete. If you encounter problems or challenges, please contact support@pingidentity.com. 

Low Complexity Applications

Low complexity applications are protected by standard web/application agents and have the following characteristics:

• LDAP or Active Directory is typically used for authentication
• Form basic and certificate-based authentication schemes
• Simple realms, rules and policies with no custom authentication schemes/active expressions (such applications are easily migrated to PingAccess without any customizations)

Medium Complexity Applications

Medium complexity applications rely on minor RSA Access Manager customization and have the following characteristics:

• Minimal RSA Access Manager customizations, such as custom authentication schemes

• RSA Access Manager authorization APIs called to perform authorization checks or using RSA Access Manager APIs for responses (headers/cookies)

Custom code developed using the RSA Access Manager SDK will need to be evaluated to determine if similar functionality is supported by PingAccess out-of-box functionality or can be developed using the PingAccess SDK.

High Complexity Applications

High complexity applications are similar to the medium complexity applications, but have more customization or specific integration requirements. High complexity applications have the following characteristics:

• More complex forms of authentication schemes like two-factor authentication, IWA, and impersonation

• Integration with applications like PeopleSoft, SAP, WebLogic, WebSphere, etc.

Custom code developed using RSA Access Manager’s SDK will have to be evaluated to determine if similar functionality is supported by PingAccess out-of-box functionality or can be developed using the SDK. While PingAccess provides a number of out-of-box connectors/ adapters for various other tools that require SSO integration, the migration may require some additional planning. 

RSA Access Manager as the Authenticator

When RSA Access Manager is used for user authentication, there are two request flows to understand. The first flow focuses on the user accessing an application protected by RSA Access Manager before accessing an application protected by PingAccess. The second flow focuses on the user accessing an application protected by PingAccess and then accessing an application protected by RSA Access Manager.

Scenario 1: User Accesses an Application Protected by RSA Access Manager and then an Application Protected by PingAccess

The user initiates a web session by accessing a RSA Access Manager protected application and then clicks on a URL protected by PingAccess. The following diagram shows the request flow:

Request Flow:

1. The user clicks a URL protected by RSA Access Manager.
2. The agent intercepts the request and collects the credentials and authenticates the user with the policy server.
   
3. The user is then redirected to the protected web page. The agent creates an Cleartrust SSO cookie for the user.
4. The user now clicks a URL protected by PingAccess.
5. PingAccess redirects to PingFederate for authentication.
6. Integration with PingFederate (i.e., WAM Integration Kit integrated with RSA Access Manager) decodes the Cleartrust SSO cookie and then validates the session with the policy server.
7. Upon successful validation, PingFederate performs an OpenID Connect based sign-on to PingAccess.
8. PingAccess validates the OpenID Connect sign-on and generates a PingAccess web session cookie (PA Token) during a redirection to the requested resource. All rules associated with the resource are evaluated for authorization, and if successful, the resource content is returned to the client.
    

Scenario 2: User Accesses an Application Protected by PingAccess and then an Application Protected by RSA Access Manager

The user initiates the session by accessing a PingAccess protected application and then clicks on a URL protected by RSA Access Manager. The following diagram depicts the request flow:
 

Request Flow: 

1. The user accesses a URL protected by PingAccess.
2. PingAccess redirects to PingFederate for authentication 
   
3. Integration with PingFederate (i.e., WAM Integration Kit integrated with RSA Access Manager) checks if there’s an existing Cleartrust SSO cookie, and if there’s not, it redirects the user to a URL protected by RSA Access Manager for authentication.
   
4. The agent intercepts the URL and shows the sign-on page. The user enters credentials and is authenticated by the policy server. RSA Access Manager then creates an Cleartrust SSO cookie.
5. PingFederate integration with RSA Access Manager decodes the Cleartrust SSO cookie and completes an OpenID Connect based sign-on to PingAccess.
6. PingAccess validates the OpenID Connect sign-on and generates a PingAccess web session cookie (PA token) and evaluates all the rules associated with the resource for authorization.
7. The user now clicks a URL protected by RSA Access Manager.
8. The agent intercepts and validates the Cleartrust SSO cookie with policy server.
9. If the Cleartrust SSO cookie is still valid and the user is authorized, the application content returned to the browser.
    

PingFederate as an authenticator

When PingFederate is used for authenticating users, the requirement is that users must interact with an application protected by PingAccess first. The request flow below shows that the authentication event places both the PingAccess JSON web token (JWT) and the RSA Access Manager Cleatrust token as cookies in the browser. After authentication, the user can access either a PingAccess protected application or a RSA Access Manager protected application.

Scenario 3: User Accesses an Application Protected by PingAccess and then an Application Protected by RSA Access Manager

The following steps describe how SSO is achieved between PingAccess and RSA Access Manager when a user accesses a resource protected by PingAccess and authenticated by PingFederate.

Request Flow: 

1. The user accesses a URL protected by PingAccess.

2. PingAccess redirects to PingFederate for authentication. The HTML Form Adapter (or other configured sign-on mechanism) presents the sign-on page. The user enters credentials and is authenticated.

3. PingFederate completes an OpenID Connect based sign-on to PingAccess and is redirected to protected resource.

4. The user now clicks a URL to a resource hosted on a web server with an RSA Access Manager agent installed that is behind a PingAccess gateway.

5. The PingAccess gateway takes the PingAccess web session cookie (PA token) and sends it in a WSTrust STS request to PingFederate to request a RSA Access Manager token (the Cleartrust SSO cookie).

6. The PingAccess gateway puts the Cleartrust SSO cookie in the HTTP request and then proxies it to the RSA Access Manager protected resource.

7. The RSA Access Manager agent checks the session with the policy server. Upon successful authentication and authorization, the web agent allows access to the resource.

8. The web server returns the resource to the browser. 

The following table shows the list of RSA Access Manager objects and the corresponding PingAccess/PingFederate objects:
 

#3233 | 12.18 | v05