JAAS authorization

 

Java 2 security architecture uses a security policy to specify which access rights granted based on code characteristics including where the code is coming from, whether it is digitally signed, and by whom. Permissions are granted based on what code is running and who is running it.

With JAAS authentication a subject is created to represent the authenticated user. A subject is comprised of a set of principals, where each principal represents an identity for that user.

You can grant permissions in the policy to specific principals. After the user is authenticated, the application can associate the subject with the current access control context. For each subsequent security-checked operation, the Java run time automatically determines whether the policy grants the required permission to a specific principal only. If so, the operation is supported if the subject associated with the access control context contains the designated principal only.

Associate a subject with the current access control context by calling the static doAs method from the subject class, passing it an authenticated subject and java.security.PrivilegedAction() or java.security.PrivilegedExceptionAction. The doAs method associates the provided subject with the current access control context and then invokes the run method from the action. The run method implementation contains all the code that ran as the specified subject. The action runs as the specified subject.

In the J2EE programming model, when invoking the EJB method from an enterprise bean or servlet, the method runs under the user identity that is determined by the run-as setting. The J2EE Version 1.3 Specification does not indicate which user identity to use when invoking an enterprise bean from a Subject.doAs action block within either the EJB code or the servlet code. A logical extension is to use the proper identity specified in the subject when invoking the EJB method within the Subject doAs action block.

This simple rule of letting Subject.doAs overwrite the run-as identity setting is an ideal way to integrate the JAAS programming model with the J2EE run-time environment. However, a design oversight was introduced into IBM Developer Kit, JTE V 1.3 when integrating the JAAS Version 1.0 implementation with the Java 2 security architecture. A subject, which is associated with the access control context is cut off by a doPrivileged call when a doPrivileged call occurs within the Subject.doAs action block. Until this problem is corrected, no reliable and run-time efficient way is available to guarantee the correct behavior of Subject.doAs in a J2EE run-time environment.

The problem can be explained better with the following example...

Subject.doAs(subject, new java.security.PrivilegedAction() 
{
    Public Object run() 
    {
        // Subject is associated with the current thread context

        java.security.AccessController.doPrivileged( new java.security.PrivilegedAction() 
        {
            public Object run() 
            {
            // Subject was cut off from the current 
            // thread context

            return null;
            }
        });

        // Subject is associated with the current thread context
        return null;
    }
});

The subject object is associated with the context of the current thread. Within the run method of a doPrivileged action block, the subject object is removed from the thread context. After leaving the doPrivileged block, the subject object is restored to the current thread context. Because doPrivileged blocks can be placed anywhere along the running path and instrumented quite often in a server environment, the run-time behavior of a doAs action block becomes difficult to manage.

To resolve this difficulty, WAS provides a WSSubject helper class to extend the JAAS authorization to a J2EE EJB method invocation as described previously. The WSSubject class provides static doAs and doAsPrivileged methods that have identical signatures to the subject class. The WSSubject.doAs method associates the WSPrincipal, WSCredential, and the CORBA credential to the currently running thread. The credential is used by the SAS run time for EJB invocation. The WSSubject.doAs and WSSubject.doAsPrivileged methods then invoke the corresponding Subject.doAs and Subject.doAsPrivileged methods. The original credential is restored and associated with the running thread upon leaving the WSSubject.doAs and WSSubject.doAsPrivileged methods.

Note that the WSSubject class is not a replacement of the subject object, but rather a helper class to ensure consistent run-time behavior as long as an EJB method invocation is a concern.

The following example illustrates the run-time behavior of the WSSubject.doAs method...

WSSubject.doAs(subject, new java.security.PrivilegedAction() {
       // Subject's CORBA Credentials  is associated with SAS thread 
       // local storage
    Public Object run() {
        // Subject is associated with the current thread context
        java.security.AccessController.doPrivileged( new 
            java.security.PrivilegedAction() {
                    public Object run() {
                       // Subject was cut off from the current thread 
                       // context, but nonetheless its CORBA Credentials 
                       // is still associated with SAS thread local 
                       // storage
       return null;
               }
         });
         // Subject is associated with the current thread context and 
       // its CORBA
                  //  Credentials is still associated with SAS thread local 
                  //  storage
         return null;
    }
});
       // Subject's CORBA Credential is removed from SAS thread local storage 
       // and the original CORBA Credentials is restored.

The Subject.doAs and Subject.doAsPrivileged methods are not integrated with the J2EE run-time environment. EJB methods that are invoked within the Subject.doAs and Subject.doAsPrivileged action blocks run under the identity specified by the run-as setting and not by the subject identity.

• The subject object generated by the WSLoginModuleImpl instance and the WSClientLoginModuleImpl instance contains a principal that implements the WSPrincipal interface. Using the getCredential() method for a WSPrincipal object returns an object that implements the WSCredential interface. You can also find the WSCredential object instance in the PublicCredentials list of the subject instance. Retrieve the WSCredential object from the PublicCredentials list instead of using the getCredential() method.

• The getCallerPrincipal() method for the WSSubject class returns a string representing the caller security identity. The return type differs from the getCallerPrincipal method of the EJBContext interface, which is java.security.Principal.

• The Subject object generated by the J2C DefaultPrincipalMapping module contains a resource principal and a PasswordCredentials list. The resource principal represents the caller.

Refer to Java 2 Connector security for more information

 

---