PremierAccess also can broker authentication requests to external systems, which is how RADIUS and SecureID are supported. To configure our RSA Ace/Server, we edited PremierAccess authbroker.cfg, which is an XML-based text file, and added the configuration data. We also set the default authentication strength. On the Ace/Server, we had to enter the PremierAccess host information because that is where the authentication requests will be coming from, not the workstations users are accessing. PremierAccess uses proxy RADIUS to communicate with Ace/Server.

All authentication attempts are processed through a series of ACLs (access-control lists) that have one or more ACEs (access-control entries). An ACE defines the subject being authenticated, any restrictions and any data that should be returned. The subjects can be users, or the subjects can be defined as specific roles, or groups, to which users are assigned; IP address or range; or the application requesting authentication. Next, an ACE defines any restrictions, such as time of day, a specific set of dates or an authentication strength that must be satisfied before authentication will be accepted.

Glossary • Authentication: Positively relating a human to a user ID. • Access control: Determining what a user can do once authenticated based on user ID, his or her role, or some other characteristic related to the user. • Accounting: Tracking logins, logouts and determining how long users were logged in systems. • Auditing: Building a trail of user events that can be replayed at a later date. • Credentials: Information that users present to authentication systems to identify themselves. • One-time passwords: Potentially strong passwords that are used only once. Often used to enroll users into a system.

Authentication strengths assign a numeric value, between 1 and 20, to authentication factors such as passwords, tokens or digital certificates. Passwords are weak, so they are by default assigned a value of 5; pinless tokens, like Secure Computing's Silver fobs, are stronger and so are assigned 15; and pinned tokens, like RSA's SecureID and Secure Computing's Platinum token, are strongest and assigned 20. The authentication values can be modified as needed. The minimum authentication strength indicates that a user must successfully authenticate at or above the minimum to be considered sufficiently authenticated. So to meet a minimum authentication strength of 20, a successful authentication with a password and an RSA SecureID token or a successful authentication with a Secure Computing SafeWord Platinum token would suffice.

In our tests, we assigned all our users roles, which organizationally group users with similar authentication requirements. For example, we had a "General User" role, of which all users were members, and we had a "High Secure" role, comprising only a few. Users can be members of one or more roles, depending on your requirements. In addition, roles can have priorities that are used to determine the order in which they are processed, with the highest priority role processed first. In all our ACEs, we used roles to restrict who the ACE applied to.

Here's where it gets fun. ACL processing is an involved two-step process, so we are going to give you the Cliffs Notes version: ACLs, and in turn ACEs, are processed until a successful authentication that satisfies all restrictions occurs or until a failure occurs. Failures end processing immediately and the user fails to authenticate. The upshot is that you don't have to specify the devices a user authenticates with in the policy, which you must do with NMAS and BioNetrix. As long as users satisfy the authentication strength, they are golden.

What Trouble?

Flexibility implies complexity, and the more complex, the more error-prone implementation becomes. Secure Computing's logging utilities offer extremely clear tools for monitoring and troubleshooting. The logging isn't very detailed, and it won't point you to where problems lie, but it did tell us the policy and ACE number that finally processed the user authentication. Knowing that, we were able to begin troubleshooting an authentication problem we were having. We had a user who was failing to authenticate, so after examining the logs, we knew the user was passing to the default policy. Working with Secure Computing, we made a change on our policy file, and processing resumed. Numerous system events could be logged and exported for review. Past logs could be loaded into the log viewer as well.

Improvements

The only area really lacking is wide biometric support. Secure Computing does support authentication using the Sony FIU-710 Puppy, a fingerprint reader and digital-certificate repository and processor, but in that case, you authenticate to the Puppy, which in turn unlocks a digital certificate. Not exactly a biometric device. The second thing that we'd like to see is the addition of single-sign-on authentication to back-end applications, a capability that isn't available without custom development. Secure Computing says PremierAccess is used primarily to augment existing authentication strategies, but anything that eases the user experience will mean fewer support issues and better policy enforcement.

SafeWord PremierAccess 3.1, $28.50 to $120 per user. Secure Computing Corp., (800) 379-4944, (408) 979-6100. http://www.securecomputing.com