Single Sign-On - Expert Oracle and Java Security - page 147

Additionally, are your users able to distinguish the list of secure, corporate sites where the single
work password can be synchronized from all other insecure or non-work-related sites that should not
have access to their work password? Work passwords that grant access to sensitive information should
never be used on external systems—who knows what security those external systems maintain?
In the end, we need to strive for SSO. First, we need to establish the foundation of trust and
assurance with NAC. Then we should push for adoption of SSO everywhere we can achieve it. Our Java
and Oracle applications are one of those places.
Who Is Logged-In on the Client?
If you are on a Microsoft Windows client or a UNIX client, the operating system (OS) retains knowledge
of the identity you claimed when you authenticated or logged in. That identity is published in your
environment settings for easy access from scripts, but the environment can be changed by those scripts
so that, judging from your environment settings alone, you can spoof a different user.
To see this spoofing, bring up a command prompt window (on Windows) and type SET to see your
settings. Perhaps you have a setting called USERNAME near the end. Observe what it is. In the same
window, type:
set USERNAME=coffin
Now type SET again and observe what the value of USERNAME is. Note that this doesn't change your
identity in the operating system, but it could change your identity for any script that uses the current
environment as its source.
Because the environment is so malleable and transient, it is not a trustworthy source of identity. Do
not read a user's identity from the environment—if you are doing that, change your ways!
Find a Better Source of OS User Identity
Windows is willing to tell our applications who the logged-in user is. Specifically, the Active Directory
authenticated user ID is available to all who know how to read it. The JRE for Windows has a class that
can acquire the user ID. That class is named NTSystem , and it is in the com.sun.security.auth.module
package—it is automatically available to the Java applications on Windows.
There is an alphabet soup of acronyms that will help us define what NTSystem does. NTSystem calls
functions in a dynamic load library (DLL) named jaas_nt.dll —part of the Java authentication and
authorization system (JAAS) package. That DLL is included in the JRE (and JDK) for Windows. NTSystem
makes native code calls using Java Native Interface (JNI) to the DLL. I suspect that NTSystem was named
for the precursor to Active Directory, NT Directory Service. For Microsoft, the Windows NT (marketed in
1993 as New Technology) server operating system was a source of many names, including NT Domains.
Use NTSystem or UnixSystem to Get Identity
When you use NTSystem , you are not relying on the environment or other intermediary, but are going
directly to the OS to get the user identity. Listing 8-1 shows the code for that functionality.