Biometrics and SSO

You’ll notice that the title of this post is “Biometrics And SSO”; not Biometrics for SSO. This is an important distinction.

Most IT shops don’t realize that they can use standard SSO along with biometric authentication to implement unobtrusive two-factor authentication for accessing servers and server applications — even if they don’t use biometric authentication to control access to the network!

Why would you want to do this? For one thing, you would ensure that the person who logged into the network from a workstation is still the same person sitting there and accessing your server.

To explain how this works, let’s first agree on a definition of Single Sign-On or SSO.  The definition I always use is that you authenticate only once to log into your workstation and the network.  After that you can access everything you need in your network without having to identify or authenticate yourself again.

In a previous article, I discussed the difference between identification and authentication. Biometric authentication is just that — authentication. It’s not biometric identification. So, immediately we see that biometric authentication is not SSO. It is merely the means by which you verify the right to be represented by the userID you asserted at the time you logged in.

Before addressing biometrics and SSO, let’s describe how biometrics can be used to access your Windows domain.  The experience could be different depending  on which biometric infrastructure provider you’re using, what options they provide and which of those options you select. I’ll use Valid Technologies’ VSSA product to describe what it would look like. (Disclosure: I am a part owner of Valid Technologies!)

VSSA provides two options for Windows domain login: 1) use biometric authentication as a second authentication factor; and, 2) use biometric authentication to replace the password as the only authentication factor. Logging in using the first option you would would see the same Windows domain login prompt as you do now. You would fill in your userID and password. Assuming the password was correct, you would then see a prompt asking you to interact with the sensor (e.g. place finger on sensor, look into the camera, place hand above the palm vein reader, etc.). The sensor would read your biometric, convert it to a template, return it to the server for comparison, and the server would tell the login process whether or not the biometric matched the enrolled template associated with the given userID. If so, you would see your Windows desktop or Start screen. The second option would be much the same except the login prompt would not display the password field.

With either option you have now authenticated to the Windows domain — congratulations.

So what about SSO?  Well, there are all kinds of possibilities, but it depends on what your IT shop and administrators want to do.  If you were already using the integrated Windows SSO (i.e. Kerberos and possibly EIM depending on the platform), you would still have that functionality.  Either way, biometric authentication wouldn’t necessarily  be involved after authentication to the domain.

This would certainly provide an improvement in your security posture. Implemented appropriately, it would make it more difficult for attackers to successfully infiltrate your Windows domain network. However, if an attacker is able to access your firewall, they could still attempt to access your servers (e.g. IBM i, Linux, Unix) directly, without needing to compromise your Windows domain. Some shops are happy enough with this level of improvement either because they have a tolerance for higher risk or because they just don’t understand the real ramifications.

In an environment where you don’t already have SSO configured, users could be prompted for a userID and password to log in to servers accessed after they have been authenticated to the network. Administrators could use something like the VSSA Login tools package from Premise, Inc. to require biometric authentication as a second factor to access IBM i, or use a PAM module provided by Botz & Associates to do the same thing in a Unix/Linux environment. In this case, after providing a valid userID and password for the server and before seeing their initial menu, program, window, they would see a prompt asking them to interact with the sensor.

I explained this process in order to discuss the advantage of using standard SSO along with biometric authentication to implement unobtrusive two-factor authentication.

If you are already using SSO via Kerberos (e.g. the SSO stat! service), you could easily add biometric authentication to new or existing legacy, Web, or Web services applications (mobile or non-mobile.) In this scenario for accessing a server after logging into the network, Kerberos would still be used as the initial authentication factor (i.e. something you know.) The advantage of this is that users wouldn’t have to enter anything, because the userID is contained in the Kerberos ticket. When a user accesses a server via Telnet, for example, and assuming you were using the VSSA Login tools from Premise, Inc., they would click on the PC5250 Telnet client icon just like they do now. The first thing they would notice would be a prompt to interact with the biometric sensor. The next thing they would see is their initial menu, program, shell, or Window on that server.  Voila! Two factor authentication without the user having to enter a userID or a password!

Somewhat ironically, this scenario doesn’t meet my definition of SSO. But that is sort of a moot point.  As long as the authentication process isn’t intrusive, doesn’t require remembering a password or entering it correctly, and completes quickly, you can have your security and “eat it too.” (Yes I did just butcher a cliche.)  In a future blog post,  I’ll discuss how biometric authentication in any kind of IT shop application can be done here and now for a very reasonable price.  I might use “It’s Not Just for Breakfast Anymore” as the title.