RSA SECUREID® Migration Guide
Migrating from applications that use RSA SecurID® to the SecureAuth® Identity Platform.
Overview
This guide will assist users in migrating from applications that use RSA SecurID® to the SecureAuth® Identity Platform. The SecureAuth Identity Platform is the most advanced identity security solution for large global organizations to enable secure access to systems, applications, and data for all workforce and customer identities everywhere: hybrid, on-prem and in the cloud.
Lower total cost of ownership (TCO)
The top reason organizations switch to SecureAuth is total cost of ownership (TCO). Our customers have demonstrated as much as a 50% ROI after switching to the SecureAuth Identity Platform. Migrating to SecureAuth from RSA reduces or eliminates expenses related to:
- Administration and upkeep of tokens and fobs
- Operational management of infrastructure and hardware for token servers
- Licensing and administration of multiple products
- Expensive and often hard to find professional services resources
- Enablement required to learn RSA’s proprietary architecture
Why move to SecureAuth from RSA®?
RSA®’s token-based authentication was a state-of-the-art solution when introduced about 20 years ago. Since then, it has become expensive, cumbersome and limited in modern security functions. SecureAuth provides the tools to migrate to a more powerful and flexible identity security solution, the SecureAuth Identity Platform.
Modern Security
To enhance security beyond basic second-factors and preserve the user experience, the SecureAuth Identity Platform provides a broad set of adaptive authentication risk checks that analyze characteristics around device, location, IP address, behavior and more to identify legitimate users and stop bad actors. These risk checks are powered by the SecureAuth® Intelligent Identity Cloud, a service that employs a big-data approach to identity intelligence to increase identity security. Out of the box, the service analyzes a range of threat data and cultivated threat intelligence to identify a wide spectrum of known attackers, and leverages machine learning to analyze user behavior and pinpoint anomalies that signal risk is present. Adaptive authentication risk checks are executed in the background, minimizing interruptions, driving broad adoption, ensuring your identities are secure and the user experience is preserved.
Standards-based security
Proprietary architecture imposes costs and difficulty in administering RSA’s user interface (UI). In contrast, SecureAuth utilizes standards-based support for nearly any device, identity type, VPN, identity store, MFA method, and application. This fidelity to standards such as REST (REpresentational State Transfer) enables you to utilize RESTful Application Programming Interfaces (APIs), driving down implementation and maintenance costs and slashing the time required to roll out new applications. SecureAuth’s adherence to other modern standards, such as OAuth and OpenID, enables easy support for your mobile initiatives.
Security Information and Event Management (SIEM), for which SecureAuth provides native integration to industry leading solutions including Splunk and LogRhythm, enables correlation of a broad range of security and event data. This enables quick identification of anomalies to prevent breaches and business disruptions. Customers we’ve migrated from RSA have reported waiting 3–4 weeks waiting for RSA to determine whether a credential was compromised. Quick dashboard views show login activity, failures, blocked requests, request types, realm utilization — and more — so your security team always has its fingers on the pulse of access requests.
Superior Support
Built around our Center of Excellence, SecureAuth’s Global Delivery & Support Team equips you with the services and tools you need to be successful at implementing, managing, and maintaining your environment. We are dedicated to ensuring you achieve the best possible outcome and offering the services and a hassle-free day-to-day experience to get you there. From professional services to 24/7 support, to training, and our online customer community, Intersections, SecureAuth can ensure that you can get the most out of your investment with us.
The SecureAuth RSA SecurID Migration Value-Added module was designed to enable a measured migration approach, ensuring there is no disruption to your users or business.
Migrating to the SecureAuth Identity Platform
In most enterprises, it is not practical to convert from one “token” method to another overnight. To ease the process of moving your business from RSA SecurID to the SecureAuth Identity Platform, the SecureAuth RSA SecurID Migration Value-Added module (VAM) was designed and architected to enable a measured migration approach, ensuring there is no disruption to your users or business. During the coexistence period, both RSA SecurID tokens and SecureAuth second factor methods can be used with the Identity Platform for second factor authentication.
The SecureAuth RSA SecurID Migration Module
SecureAuth developed the SecureAuth RSA SecurID Migration VAM as a means to utilize SecureAuth’s multi-factor authentication (MFA) and adaptive authentication in conjunction with RSA’s hard-token topology, as seen in the figure below.
- User navigates to the target application using a web browser.
- The target application redirects the user to SecureAuth for authentication.
- SecureAuth validates the username and password and prompts the user to enter the OTPfrom the RSA Token.
- The RSA Token is validated against RSA Authentication Manager through the SecureAuthIdentity Platform.
- Successful validation allows access to the target resource. Failed validations are blocked.
This interim measure works well to lower administration cost, improve user uptime, and boost user satisfaction. However, to benefit from the full range of protection and ease-of-use provided by the SecureAuth Identity Platform, full migration to SecureAuth is the next logical step.
Migration concerns
Migrating to a new access control solution can be a daunting challenge. SecureAuth has identified several concerns that organizations encounter when considering a change in access control in their environment.
Considerations
Many of the considerations associated with implementing this VAM revolve around a larger SecureAuth implementation plan. Some of the considerations listed below are specific to the RSA SecurID migration.
- What is the timeline to migrate all users? This is often driven by licensing considerations of the soon to be retired platform.
- Do I have a full inventory of the applications that use RSA SecurID authentication services?
- Which applications/use cases will be migrated first?
- Are there any applications that are customized to work with the legacy platform, and can those be moved to federated or other standards-based authentication methods?
- How will I communicate to the user base about the changes?
- What user groups will be prioritized to move to the new platform?
- How will reluctant users be “forced” to move the new platform?
- Do I have a pilot environment where each app can be tested prior to migration?
Stakeholders
It’s crucial to make sure that all the relevant business units, users, customers, vendors, partners, and other stakeholders are involved in planning the migration and that participants are aware of how it could impact them. Clear communication up front paves the way for a successful migration.
Change management
Ensure that your standard company change management processes are followed, including well planned back-out procedures. It is not uncommon for some migrations to have unforeseen issues. It is critical that a well-planned back-out scenario is in place to ensure business continuity.
Migration process
1. Planning
The planning phase can be the most powerful period in which to reduce the cost of migration, ensure minimal downtime and set appropriate stakeholder expectations, including users. This is the time when the inventory of servers and data takes place and communication with stakeholders begins.
Architecture
To migrate from RSA Authentication Manager to the SecureAuth Identity Platform, the first step is to survey and inventory the existing RSA deployment in order to visualize every interconnection, as displayed in the illustration below.
Inventory the applications and policies to be migrated
Once the existing architecture and use cases are understood and documented, take an inventory of applications that currently rely on RSA for authentication and access. Each application should have its realms (workflows), rules, and rule groups cataloged and prepared for migration to the SecureAuth Identity Platform.
Next, RSA Authentication Manager policies need to be prepared for migration, with each policy cataloged and all protected resources identified. Included in this preparation are the access control lists (ACLs) and rules used, as well as any authentication requirements employed to identify users.
Authentication and session management
A subsequent step in planning a migration involves understanding and evaluating the authentication processes within your environment. Systems that use RSA Authentication Manager require a decision regarding when to transition authentication to the SecureAuth Identity Platform.
One option is to migrate all user “tokens” at the beginning of the process. This makes SecureAuth the controlling record source for identification and authentication. This option does not take full advantage of this migration module.
The other option is to migrate authentication to the SecureAuth Identity Platform at the end of migration (after all applications are migrated), or in a phased approach. In this case, RSA Authentication Manager continues to perform authentication even when users access a SecureAuth protected application. When the time comes to decommission RSA Authentication Manager and tokens, the authentication process migrates completely to the SecureAuth Identity Platform.
Planning the project
Once the applications have been classified, the policies cataloged, and the authentication and session management processes understood, create a project plan to bring together the necessary resources to install the SecureAuth Identity Platform, integrate it with RSA Authentication Manager, and conduct the migration.
A migration involves incremental steps made with care and deliberation in the test area, insulated from interference with the production system.
We recommended your migration follow the progression below.
2. Initial deployment and integration
Installing the SecureAuth RSA SecurID Migration VAM
Deployment Prerequisites
The requirements for deployment of this functionality are:
- SecureAuth IdP version 8.2 or later, or the SecureAuth Identity Platform 19.07
- The RSA SecurID with a RADIUS server enabled. Other vendor products such as Vasco, Defender, or SafeNet are supported via this module in place of SecurID.
- Connectivity between the SecureAuth Identity Platform appliance and the RSA SecurID RADIUS server.
- The appropriate version of the deployment package. (There is a version of this package for each supported version of SecureAuth IdP and the SecureAuth Identity Platform).
Best Practices
When planning for deployment, keep in mind the following best practices:
- Utilize the RADIUS Test Client to streamline the integration. We recommend that you test both the RADIUS server connectivity and token validation using the Test Client process before any integration.
- We have found specific errors arising from RADIUS server policies in Vasco RADIUS servers. Any possible problems can be alleviated by using the Test Tool and examining the server logs.
- Make sure you download the SecureAuth RSA SecurID Migration VAM deployment package that matches your version of SecureAuth IdP or the SecureAuth Identity Platform. There are multiple versions of SecureAuth IdP and the SecureAuth Identity Platform, and each version has a corresponding version of this module. Verify version compatibility before installation.
Installing the VAM
To configure the SecureAuth Identity Platform installation for RSA SecurID Migration authentication, perform the following steps.
1.- Download SecureAuth RSA SecurID Migration VAM deployment package from the SecureAuth site to a temporary folder on the SecureAuth IdP or Identity Platform appliance. (For the specific location of this deployment package, contact your project team for assistance.)
2.- Using a decompression program such as WinZip or 7-Zip, unpack the deployment package to a temporary folder. Two sub-folders appear:
3.- Drill into the SecureAuthxx folder.
4.- Copy these files to the targeted realm’s bin folder, such as SecureAuth1/bin or SecureAuth2/ bin.
Repeat this step for every SecureAuth folder, except for the SecureAuth0 folder.
Configuring the VAM
1. Launch the SecureAuth Identity Platform Admin Console
Launch the SecureAuth Identity Platform Admin Console by entering the URL http://localhost:8088/. The admin console user interface can only be viewed on the local machine. For version IdP version 9.3 and above, open the classic admin interface.
2. Click the Tools option
From the admin console’s left panel, click the Tools option at the top of the page, as seen in the image below.
3. Select the Update Web Config option.
Select the Update Web Config option. A screen appears, as in the image below.
4. Click both the Update and Update Resource buttons.
The web config files are updated using the new DLLs you copied to the appropriate folders. After the update is completed, the admin UI reappears.
5. Add module settings to the configuration file:
- For versions 9.2 and below, click on the Admin Realm option, then from the left pane, click to select the targeted realm, such as SecureAuth1 or SecureAuth2, then click the System tab, then “Click to edit Web Config file.” to open the web.config editor.
- For versions 9.3 and above or the SecureAuth Identity Platform, click the Tools option, then Decrypt Web Config. Select all realms that will be using this module then click the Decrypt button.
6. Add the following configuration settings in the sections below as described:
In
<SectionGroup name=”system.web”>
<section name=”oneTimePasswordRadiusService” type=”SecureAuth.OTP.Radius.OneTimePasswordConfiguration, SecureAuth.OTP.Radius” allowDefinition=”MachineToApplication” />In key RegMethodOrder add “radius”
<add key=”RegMethodOrder” value=”Email,..,PushAccept,radius” />Add the following keys
<add key=”RadiusOathTokenValidationEnabled” value=”True” />
<add key=”RadiusOathTokenField” value=”AuxID5″ />
<add key=”RadiusTokenField” value=”AuxID5″ />
<add key=”msgRADIUSMethod” value=”RADIUS Registration Method Selected” />
<add key=”RegistrationRadius” value=”True” />Add the Radius provider inside
<!– otp –>section
<oneTimePasswordRadiusService>
<providers>
<clear />
<add description=”Radius Server Provider” Authentication_Port=”1812″ Authentication_Account=”1813″ Retries=”3″ Socket_Timout=”6000″ Hostname=”” Shared_Secret=”” RadiusClientNAS_IP_Address=”” name=”OTPRadiusProvider” type=”SecureAuth.OTP.Radius” /> </providers>
</oneTimePasswordRadiusService>
7. Click to select the Registration Methods tab.
Scroll down until you see the newly created RSA/RADIUS Server Settings section as shown in the next image.
The default settings for the attached RSA server are displayed.
8. Change the values in these fields as required. These fields include:
Attribute |
Setting |
|---|---|
| RADIUS Server | Select whether a RADIUS server is enabled for this SecureAuth Identity Platform appliance. Enable this feature to connect with the RSA SecurID serve |
| Host Name | Enter the IP address or the server name of the target RADIUS server |
| Authentication Port | Enter the port number this appliance will use to authenticate applications overseen by the external RADIUS server gateway |
| Authentication Account | Not used. No value is needed or used for this use case |
| Retries | Enter the number of retries the SecureAuth appliance will do before abandoning the request to the RSA RADIUS server |
| Socket Timeout | Enter the number of milliseconds this RADIUS port will wait before abandoning the request to the RSA RADIUS server |
| Shared Secret | Enter the RADIUS shared secret that enables this appliance to access the RADIUS server |
Update the configuration accordingly and click Save the to commit configuration changes.
3. Testing
Testing the SecureAuth RSA SecurID Migration VAM Deployment
A third component included in the SecureAuth RSA SecurID Migration VAM deployment package is the RADIUS Test Client. This command line tool enables you to test the deployment and ascertain whether the VAM configuration is working properly prior to any integration.
To initiate this test, use the following procedure:
- Place the RADIUS test tool into a directory of your choosing and extract the files. Notice that one of the files is an executable.
- Open the command line prompt by typing cmd. The command prompt dialog box appears.
- Use cmd to navigate to the directory where you placed the executable, then enter: SecureAuth.RadiusServerTestClient [hostname] [sharedsecret] [username] [password] where:
- [hostname] Enter the name of the host where the RADIUS server resides.
[sharedsecret] Enter the shared secret that enables the RADIUS server to communicate with the client.
[username] Enter the name of the user
[password] Enter the password associated with this user.
NOTE: If you enter only the executable name, a list of all parameters supported by this executable appear.
The test client runs and indicates whether the deployment was successful or not, as shown in the example below.
4. Migration
Migrating a protected application to SecureAuth
- Integrate a protected application with the SecureAuth Identity Platform.
- Enable RSA token validation in the SecureAuth IdP/Identity Platform realm.
- Apply adaptive authentication polices for the application in the SecureAuth Identity Platform.
- Deploy application to users
- Users are able to authenticate with RSA SecurID tokens for MFA.
- Enable alternate 2FA methods for the realm.
- Disable RSA SecurID tokens when all users have registered for alternate 2FA methods.
- Migration complete.
Migrating a protected application to SecureAuth
Steps to complete the migration
Application migration
Even as apps migrate to the SecureAuth Identity Platform, RSA Authentication Manager agents may still be left in place. The application owners must work with the migration project team to remove those agents so that RSA Authentication Manager can be safely retired. Once all users have registered with an alternate 2FA method, the RSA token second factor method can be disabled on a per-realm basis.
Sample Scenarios
This section provides two example scenarios for the RSA SecurID Migration module after its deployment.
Token Validation for Web Applications
Typically, RSA SecurID is leveraged to protect VPN and other RADIUS compatible devices. With this module, the tokens can now be used to authenticate to web applications during the RSA token phase-out period.
The example below illustrates a typical user workflow when logging into a web based application protected by the SecureAuth Identity Platform.
Click the Security Token radio button, then click the Submit button. A screen appears, as in the next image.
Type or click the buttons to input the security-token code then click Submit.
After the token is validated, the requested application is now available to the user
Token Validation via SecureAuth RADIUS Server
Most customers that use the RSA SecurID product leverage it to protect access to network resources such as VPNs. To migrate from RSA to SecureAuth, the SecureAuth RADIUS server is often used if the VPN does not support more modern authentication methods such as SAML. SecureAuth recommends using SAML when supported by the VPN, when migrating from RSA SecurID.
In cases where the VPN (or other protected resource) does not support modern authentication methods, the SecureAuth RADIUS server is used. The RADIUS protocol is well supported by VPNs and legacy applications. The SecureAuth RADIUS server proxies authentication requests from the VPN (or other protected resource) to the SecureAuth Identity Platform server. All of the authentication methods that you choose to make available to the user are presented via the VPN (or other protected resource) login user interface.
Below is an example of the user workflow when logging into a Cisco AnyConnect VPN client.
About SecureAuth
SecureAuth is an identity security company that enables the most secure and flexible authentication experience for employees, partners and customers. Delivered as a service and deployed across cloud, hybrid and on-premises environments, SecureAuth manages and protects access to applications, systems and data at scale, anywhere in the world. The company provides the tools to build identity security into new and existing applications and workflows without impacting user experience or engagement, resulting in increased productivity and reduced risk.