RSA 7.1: Virtually Painful

Over the last few months, I've implemented a number of instances of RSA SecurID Authentication Manager for several clients. This is nothing new for me - in fact, I've been working with SecurID since version 2.1, which is way before RSA bought the product from Security Dynamics. What is new is my disappointment with the latest incarnation of the product in version 7.1. It's too heavy and doesn't work properly in a virtual environment.

Before I tell you why I don't get on the new product, let's go back to basics. What does Authentication Manager do? It receives authentication requests from agents, compares the username and passcode against its database, then sends back a reply to confirm or deny the access. That's it in a nutshell; it's not complex.

Of course, there is a tiny bit more to it than that. The communication with agents is encrypted. The user and token databases need to be maintained and the list of trusted agents managed. This might include links to external LDAP user databases such as Active Directory. An optional RADIUS server is available that allows a wider range of agents to connect. In later versions, multiple replicated servers can be used in a distributed setup, including the possibility of federated identity using the 'realms' feature.

Luckily, until recently, the implementation is very lightweight. Up until 6.1 the code for all of the above takes very little CPU, memory and disk resource. (Version 2.1 used to run quite happily on a 386sx with 8MB RAM.) The database is a proprietary RSA system and the GUI is very lightweight. It's not pretty, but it's quick. Configuration changes are few and far between compared to the handling of authentication requests, so this should not be a heavyweight application. So it's perfect for a virtual environment.

Ok. So what's the problem with 7.1? The latest version of the software is implemented in Java with an Oracle database backend. The new user interface is web based, again implemented in server side Java. This is no longer a lightweight solution and there are a number of problems with running this in a virtual environment. There are new features – the self service portal for one – but the basic premise has not changed.

The server still answers a simple question: is the passcode correct? Only now, it's a lot more resource hungry. I have had repeated issues on different client sites with different implementations of Windows Server on different ESX platforms. The installation takes at least an hour, the restart of the server takes thirty minutes to an hour. The services don't really start up properly of at all. Task Manager shows that there are two or three Java processes running using 100% CPU and around 800-900MB RAM each.

RSA's support desk suggested some database hotfixes and giving the VM more memory. Given that the first resource that we tend to run out of in a virtual environment is memory, is it really reasonable that Authentication Manager needs 4GB assigned to it? RSA recommends a minimum of 2GB, but the experience of mine and some others (enus and Rene) suggests that four is really the minimum required. I've gone further and added a memory reservation of 2GB to most client environments to ensure that the database even starts.

In a number of my clients environments this kind of memory requirement has not been acceptable. We have reluctantly reverted to running version 6.1. I have always loved this product. It does what it is supposed to do and has not become overly complex or grown bloated like so many other security products. Until version 7.1 that is. Clients either miss out on the benefits of virtualisation or the features that they are want from 7.1.

RSA - you need to fix this. Love, your greatest fan.