Skip navigation
All Places > Products > RSA SecurID Access > Blog > Author: Vasanth Balakrishnan

PLEASE  NOTE:  An RSA Authentication Manager 8.x  Web Tier server installed on CentOS is NOT supported by RSA.

 

This UNOFFICIAL GUIDE is intended only for non-production lab testing for partners, customers and RSA employees.

 

For more information on RSA's position on using CentOS with RSA Authentication Manager and RSA Authentication Agents, please see 000016848 - RSA support for Authentication Manager and/or RSA Authentication Agents installed on CentOS.

        

Introduction

An RSA Authentication Manager Web Tier server has three functions:

  • Secure CT-KIP RSA SecurID software token provisioning across untrusted networks (usually the internet).
  • Allowing Self-Service Console (SSC) access to untrusted networks or the internet.
  • Legacy Risk-Based Authentication (RBA) feature in Authentication Manager 8.x. This function has been superseded by SecurID Access Cloud Authentication Service Risk-Based Identity Confidence in the Premium edition.

Of these functions, the first is most important for a secure Authentication Manager 8.3 deployment. The  Web Tier is currently provided as Microsoft Windows or Linux software packages that install on a customer-provided server typically deployed in a DMZ. Lab deployments usually operate inside a secured network zone.

It is strongly recommended that customers and partners maintain a non-production lab testing environment to test new versions and configuration changes.

          

Please see the RSA Authentication Manager 8.3 Setup and Configuration Guide, Chapter 5: Installing Web Tiers, Web-Tier Hardware and Operating System Requirements for more details on supported versions of Windows and Red Hat Enterprise Linux (RHEL).  Here are the requirements:

Description
Requirements
HardwareHard Drive: 2 GB for Web Tier installation
Hard Drive: 4 GB, with 20 GB free space for logs and updated component downloads
RAM: 2 GB
CPU: A CPU with a dual-core processor or better, or 2 or more CPUs.
Ports

External Firewall: 443 HTTPS (TCP)

DMZ: 443 HTTPS (TCP)
Internal Firewall: 7022 T3S (TCP)

Operating SystemsRed Hat Enterprise Linux 5 Server (64-bit)
Red Hat Enterprise Linux 6 Server (64-bit)
Red Hat Enterprise Linux 7.4 Server (64-bit)
Windows Server 2008 R2 (64-bit)
Windows Server 2012 (64-bit)
Windows Server 2012 R2 (64-bit)

 

While these are the officially supported servers, it's often difficult for lab/demo usage to get a licensed copy of Microsoft Windows Server or Red Hat Enterprise Linux. CentOS is the free and open source version of RHEL which is nearly 100% compatible. In my testing I have found it's possible to deploy the RSA Web Tier package on a CentOS host after a very trivial modification of the OS. 

This guide is intended to allow a SecurID administrator to configure a CentOS 7 Web Tier in a non-production lab or demo environment based on VMware workstation or ESXi virtualization infrastructure.

 

Task 1: Configuring the CentOS 7 Operating System

Since CentOS is highly configurable with several different distributions, this section will provide step-by-step guidance.

  1. Download the DVD ISO from CentOS. The Everything ISO is too bloated and the Minimal ISO leaves out important tools, so the DVD release is the right one which allows you to configure your server at install.
  2. Build your virtual machine in VMware Workstation or ESXi, or your hypervisor platform of choice. Note that the Web Tier can even be installed on a physical server which may make sense for some environments, as it typically sits in the DMZ on a network. The VMware step-by-step instructions are beyond the scope of this article. Create the VM with 20 GB of disk, 2 GB of RAM and a single network adapter. (See Web Tier hardware requirements in the RSA Authentication Manager 8.3 Setup and Configuration Guide) I did customize the virtual hardware and remove the printer and sound card defaults since we don't need that for a server. Change the CD/DVD virtual drive to use the CentOS 7 ISO image you downloaded above and increase the memory to 2 GB. I find 2 vCPUs to be overkill for a lab so I kept the single CPU default. Once everything looks good, power on the VM and enter the virtual console.
    VMware create VM customized hardware and ISO image
  3. At this point I find it easiest to get the DNS for the server configured. In my lab network router interface, here I have entered an A DNS record and will fill in the static IP address in my lab router admin interface, which also is my local DNS resolver:
    Adding of Web Tier DNS entry
  4. Now we're ready to proceed with the VMware console install of the CentOS 7 Web Tier. The following screen shots are based on the ESXi web client but it should be similar for workstation. On boot you should see the CentOS Linux 7 installer boot screen, select the first option Install CentOS Linux 7. Follow the screen prompts from there including typing Enter.
    CentOS 7 boot install first option
  5. A bunch of booting events happen and then you'll get to a language selection screen, defaulted to US English. Select the default and then move to the main installation GUI screen. Note anything that's red needs to be selected before the installation can proceed. You have to be careful because it's a lot easier to configure some optional items here rather than later after installation is complete.
    1. First complete the mandatory Installation Destination. Don't forget to also fix the Date & Time time zone to match the Web Tier location. Then highlight the Software Selection option and select it:
      CentOS 7 main installer mandatory selections
    2. Choose the server type. I've found Minimal too bare bones, so Compute Node has more useful utilities. You may be wondering why I didn't select Basic Web Server. I don't want that because the RSA Authentication Manager 8.3 Web Tier package has it's own web app server and web server so we don't want an unneeded web server in the OS.
      CentOS 7 software selection
    3. The last step, which is an important one, is configuring the Web Tier server network connection. Select the Network & Host Name option and configure the network. Note the Ethernet connection is defaulted to off. Before you switch it on, click the lower left Configure button:
      Network and Host Name configuration main screen
      Go through the various tabs.  Most settings are left as the default but I turned off IPv6 by choosing Ignore and configured IPv4 as Manual with my static IP configuration that I already set up on my DNS server. Set the IP address, subnet mask and gateway as well as Host name and Search domains. Note all the fields are not shown completed below:
      IPv4 detailed configuration
      Finally turn the network on with the top right graphical switch. You should see the connection details and then be able to ping the Web Tier from another host on the network by hostname. Note that the Web Tier installer process requires the Web Tier to be resolvable by host name.
      Network and Host Name configuration completed
      Successful DNS resolution and ping from another host on the LAN
    4. You're finally ready to begin the installation, so select that option on the main installer screen. You'll see the installer starts installing packages from the DVD ISO. In the meantime, you can set the root password and create the Web Tier user. Set a strong root password and note you should really create the Web Tier user now and set it up as non-root with another strong password. This will be required for the Web Tier installer later.
      Web Tier passwords set
      Finally, the install will complete and you'll be prompted to reboot. You will come to the login bash prompt. Login as root, then logout again. You can proceed to get the Web Tier software install going. This is a lab environment so all security procedures and Security Enhanced Linux (SELinux) were not selected, but certainly follow best practices for your environment as they apply.

 

Task 2: Install and Configure RSA Authentication Manager 8.3 Web Tier Package

  1. We now have a CentOS 7 server with network connectivity that is ready for the RSA Web Tier install. Use your favorite SSH client from your chosen OS and log into the Web Tier. If you haven't already by this point, download the Authentication Manager 8.3 Web Tier package from the /Webtier directory in the Extras .zip file, available from Version Upgrades on RSA Link.  See 000034558 - How to download RSA Authentication Manager 8.x full kits and service packs from RSA Link for information on how to  download the file.
    Note you must have entitlements to download this file, so contact Customer Support if you get a login or authorization error.
    Handy Tip: You only need the /common and /linux-x86_64 sub directories extracted and copied over to your local VM or PC jump host with LAN access to the Web Tier CentOS 7 server. This way you are not copying over the unneeded /windows directory to a Linux Web Tier server.
  2. Use your favorite SCP tool to copy the /common and /linux-86_64 subdirectories to a new directory named /tmp/webtier on your CentOS 7 Web Tier server. The screen shots here are based on WinSCP. It's pretty important to have GbE or faster local LAN connectivity to your Web Tier box. For 8.3 it's about 1.7 GB of install files to copy over.
    WinSCP file copy to CentOS 7 Linux server
  3. From here we will follow the steps on how to install a Web Tier on Linux using the command line from chapter 5 of the RSA Authentication Manager 8.3 Setup and Configuration Guide. The documentation for Linux Web Tier installs has been greatly improved over older 8.x versions. Make sure you look at the Web Tier Installation Checklist before you start the installer script and follow the chmod permissions instructions carefully. You'll also need the Web Tier package from the Authentication Manager 8.3 Operations Console before you start the installer script as shown here. The typical service options are selected:
    Web Tier OC configuration and package generation

Task 3: Fix Installer Script Version Check to Allow Install on CentOS 7

STOP HERE. If you just try to continue with the default Web Tier installer script, you'll run into this error:

          


Installer script prerequisites error

  1. There's an easy fix to fool the installer script OS version check, which isn't that sophisticated. At the command prompt, type cat /etc/redhat-release and you'll see this file contents refers to CentOS:
    Release file view
    If you search this subject online, you'll get links regarding Red Hat Enterprise Linux Release Dates, which will give you the contents of this file specific to RHEL 7.4; which is Red Hat Enterprise Linux Server release 7.4 (Maipo).
  2. Use a nano /etc/redhat-release command, edit the file accordingly, and save it. Here is the string that can be cut & paste:
    Red Hat Enterprise Linux server release 7.4 (Maipo)
    Editing /etc/redhat-release file
  3. Now the installer script can proceed after you answer all the questions, as it will pass the RHEL 7.4 version check:
    WT installer script proceeding successfully
    Depending on how fast your storage system is on your server the install should take 20 to 30 minutes. After this time you should see the installer script finish with this message. It does take some time.
    Your installation is complete.
    Next Step
    After you exit the Web-Tier Installer, the Web-Tier Update Service connects to the preferred server to install the necessary services. Use the RSA Operations Console to check the status of this process.
    Go to Operations Console > Deployment Configurations > Web-Tier Deployments > Manage Existing.
    The update may take up to 20 minutes to complete.

    Press Enter to exit.
  4. The other key tip I've found is to go ahead and reboot the Web Tier server with a reboot command. It seems the Web Tier bootstrapper doesn't start after the installer finishes, but will kick off on a reboot. You will know it is working because if you run a top command on the console, Java will be taking up a bunch of CPU cycles:
    Web Tier Java processes
    You also may need to open the HTTPS service using the
    firewalld command if it's not already open. Search online for the many helpful guides on this.  RSA knowledge article 000033006 - Troubleshooting an Update Issue with an RSA Authentication Manager 8.1 Web Tier Deployment is very helpful in troubleshooting Web Tier connectivity issues on Linux. Eventually you will see this happy message on your Operations Console Web Tier configuration screen:
    Web Tier online successful

  5. Finally, go ahead and browse from your lab network to the FQDN of your Web Tier. It's recommended you use Microsoft Edge or Internet Explorer, as you should get a invalid security warning that you can click past. Firefox and Chrome are much stricter (rightfully so) on security, so you probably can't open the Web Tier Self-Service Console on current versions of those browsers. This can be fixed by getting a proper SSL certificate on the Web Tier through the documented procedure. For now, we have the Web Tier up and running.  Success!
    Web Tier SSC success!

Recently I had a customer use case that required integrating SecurID Access authentication into one of their web applications. With the release of Authentication Manager (AM) 8.2 SP1, and continuing with AM 8.3, there is a new built-in RESTful web API for authentication. A REST-compliant API allows for much easier integration of SecurID authentication into web-based applications and sign-on workflows. In a few hours of testing, I was able to get an RSA-provided test application up and running using this API in my Authentication Manager 8.2 SP1 lab. One cool thing about this new REST API is that it allows you to use the same API for AM with traditional SecurID authenticators but also the new SecurID Access Cloud Authentication Service and new authenticators such as push-to-approve, biometrics and the Authenticate app token codes.

 

This guide is written for a non-programmer to get the RSA test application up and running against a local AM 8.2 SP1 test/lab instance. The guide is also based on a Windows client PC or VM but a knowledgeable Linux admin could easily get it running on a Linux client.

 

Requirements

  • Local AM 8.2 SP1 Primary instance, ideally patched to the latest version, P2 as of this post, with Super Admin access
  • Windows host or VM with network connectivity to AM 8.2 SP1 Primary
  • rsa-securid-authentication-api-example.zip file from rsa-am-extras-8.2.1.0.0 ZIP file package under the \RSA SecurID Authentication API folder. This Extras package is available for existing SecurID Customers and Partners at the Version Upgrade Downloads on Link. (login required)
  • The README text file inside the API example test app zip file is very helpful and notes two other requirements in order to build and run the test applications:

References

  • RSA SecurID Authentication API Developer's Guide PDF
    • The OpenAPI references in the Preface section of this PDF are helpful to developers
  • rest-java-client/target/generated-sources/swagger/index.html Documentation generated during install/compile
  • openapi-yaml/rsa-securid-authentication-api.yaml This OpenAPI interface definition source (YAML) file which contains details on the endpoints and JSON objects

Setting Up Java JDK and Apache Maven Steps

  1. Java JDK - If it’s not already installed, download the appropriate version of the Java JDK for your client platform and install it using the defaults. Once it’s installed, on a Windows PC, you can launch the command prompt and type java -? and you should get output to make sure the JDK is installed and the PATH is set correctly.
  2. Maven - Follow the Apache install instructions which is basically to unzip it to a directory of your choice and create a PATH environment variable to the /bin directory inside the Maven package. I unzipped it to: C:\Program Files\apache-maven-3.5.0 .
    1. Maven requires the JAVA_HOME variable to bet set for the JDK executable and it does not seem to be properly set by the JDK installer on my Windows VM when you also have the Java Runtime Environment (JRE) installed. If you don't get an actual path when you type in echo %JAVA_HOME% on the command prompt, the Atlassian website has a good guide on this.
    2. If everything is installed correctly, on a command line mvn -v should give you similar output to this:
      Command line maven installation verification
      Notice it is jdk and not jre when the JAVA_HOME environment variable is set correctly. If it points to the JRE you will get a Maven compile error in the next step.
  3. Extract the entire rsa-securid-authentication-api-example.zip file preserving directories into a directory of your choice. In this example, it is c:\SID-REST. From now you can follow the instructions from the README text file contained inside that zip. When you run mvn clean install from the unzipped directory, it will download a bunch of Maven cloud repo Java libraries and then compile the test app based on the pom.xml file. You will see some warnings which is OK but eventually you should something like this BUILD SUCCESS message:
    Command line maven build success completed
  4. Finally, we are now ready to configure AM 8.2 SP1 to start testing. However, first it’s never a bad idea to ping the Primary test instance to make sure your Windows VM can talk to it:
    Command line AM instance successful ping from Windows VM
  5. We know AM is up so we can configure the instance to accept REST API connections. Log into the AM 8.2 SP1 Primary instance Security Console as Super Admin. On the main dashboard at the bottom left under Quick Links, go into System Settings. With 8.2 SP1 we now have a link for RSA SecurID Authentication API on the top left quadrant. Click into it:
    AM Security Console System Settings quick link Authentication API
    Enable the API checkbox and keep the default port unless you need to change it, click Apply Settings:
    SecurID Authentication API enablement and apply
    Note the Access ID and Access Key - it may be handy to cut paste those into a text editor.
  6. Now if you haven't already, either create a test user in the internal database or find a user in a lab identity source (AD or LDAPv3) and assign them a token. TIP: If your AM lab is like mine it probably only has soft tokens. You'll need to use the Windows Desktop token on the client VM or configure iOS or Android with the CTF soft token profile. Note: CTF is considered an insecure soft token provisioning method by RSA and is not recommended for production environments. For a test lab this is fine. You can then go in as admin, assign a soft token and distribute it with that CTF profile. Cut and paste the CTF activation code and email it to an account on your smart phone. After you install the RSA SecurID soft token app from the app store, that email code will allow you to import the token. The specific instructions for this set of steps are beyond the scope of this guide but it's straightforward. Make sure you go into the Self Service Console (SSC) as that user and set the PIN (if not set with SSC) and test the token to make sure authentication is working and you have a good token:
    AM Self Service Console successful token test authentication
  7. Now we can get back to the README file and start testing the Java test REST-API app. I find the test authentication client (rest-test-auth) is a lot easier than the single-step CLI client (rest-test-CLI.) The readme instructions are fairly general so let’s take it step-by-step. Go into the \rest-rest-auth\target subdirectory and run the java executable:
    cd rest-test-auth\target
    java -jar rest-test-auth-jar-with-dependencies.jar
  8. You should get output like this assuming your JRE is installed correctly:
    Command line rest-test-auth Java program main menu

    Notice the testclient.properties file is not found because this is the first time to run this test Java client that creates it. There’s also an SSL warning since we haven’t yet downloaded the root certificate from our lab AM primary instance. First step is to select 1) and configure the client API. We will configure these in order:
    1. Base server URL - After compile and install this app defaults to localhost. It’s easiest to just cut and paste this existing default URL and edit it to the correct FQDN of your lab primary instance with the correct configured port and type enter:Command line AM default URL change to correct address
    2. Agent Name - The app defaults to the local FQDN so just cut & paste that and make sure you go over to your Primary, login as Super Admin and add a standard agent record for your Windows client VM. In my lab, this box happens to also be the AD server:Command line keep default agent nameAM Security add REST-API client computer as new host
    3. For the next 5 options just keep the default values:
      Command line keep next 5 options default
    4. Root Certificate File - Now we come to the AM instance certificate file option so that verified HTTPS can be established between this client app and REST-API service running on the AM instance. If you don't do this, the test app will just throw a warning but it will still work. Nevertheless, it's not hard to fix. I found the easiest thing is to use the Firefox browser to log into the primary Security Console. Click the padlock icon on the URL bar top left, click the arrows and More Information button until you get to the View Certificate button and click into it. (Note not all steps are shown below as screenshots for the sake of brevity:)
      AM Security Console Firefox view certificate
      AM Security Console Firefox certificate save as p7c
      Click the Details tab and then you click the Export button and export to an X.509 Certificate (PKCS#7) format taking note of the filename. Copy the p7c file to the same directory as your rest-test-auth-jar-with-dependencies.jar file. You can then update the root certificate filename at the command line:Command line certificate name update
    5. API Key Type - keep the default value of KEY. The RSA SecurID Authentication API Developer's Guide (linked above) goes into details on these two options.
    6. Access ID & Access Key - These two will be from your temporary text file copied from the AM Security Console. Make sure you cut & paste carefully without truncating or padding spaces. (The screenshot below shows the values being updated because I changed the regenerated the API keys on the AM Security Console between screenshots.)Command line API Access ID and Key update
    7. Policy ID (for RSA SecurID Access) - This next option does not apply since we are using the SecurID REST-API on Authentication Manager so just leave the default as shown in bottom of the screenshot above.
  9. Once everything is configured correctly, this program will write a testclient.properties local file. You will be returned to the main menu and we can see SSL verification is enabled:Command line SSL verification enabled and properties file loaded
    We are finally ready to try out authentication with our test user token! The 4) option is the choice for a regular hard or soft token. My lab has user ID auser with a soft token on iOS. It's also helpful to go to your AM Security Console and run the Authentication Monitor. Switch back to the command line and run option 4 and test your confirmed working user and token. The screenshots below show iOS soft token PIN entry, passcode display and 2FA credential entry into the test app:
    iOS auser soft token PIN entryiOS auser soft token tokencode display

Command line single-step authentication username and passcode entryCommand line single-step successful SecurID authentication

AM Security Console Authentication Monitor successful

SUCCESS!

It's cool to get this working after all those steps, I think you can agree. The option 3) in the app is a multi-step authentication mostly applicable to the SecurID Access Cloud Authentication service but it also works for an On-Demand enabled user where you must enter a PIN and then the tokencode is delivered via SMS or email, then entered by the user as a multi-step authentication. Now you or your development teams can start testing the REST-API and building in SecurID Access authentication into any application that supports a RESTful API integration.

 

Important Considerations

The biggest caveat is that traditional SecurID native API clients written to our Java or C APIs will by default support the built-in load balancing and high availability in the SecurID (SDI) protocol. That will include automatically discovering all Replica instances during the first authentication and failing over to the next available instance. This new RESTful API explicitly requires the API client to connect to a Primary or Replica instance. Failover functionality must be handled by the client. In this respect it is very similar to the RADIUS server functionality built into each AM instance with explicit primary and failover RADIUS servers defined at every client agent.

 

If you want to check out the Java code in this sample app, there are /src directories in the test app package with the Java source that can be examined in a text editor.

Filter Blog

By date: By tag: