Understanding JAAS Authorization | Java Security Solutions

Authentication is used to verify an authentication mechanism. It validates an entity by associated credentials that provide identification for the entity, very much like a driver's license is used to verify a person. After an identity has been verified , the entity becomes a subject with principals and credentials. The principal can now try to access system resources such as a file, device, other process, and more.

Just because a user has been validated does not mean that the user has permissions to access the system resources. The next phase of JAAS must check permissions of the system resource. The permissions are stored in a security policy file, and JAAS will use the Java 2 security manager to check the permissions of the principal to ensure authorization to the system resource.

Cross-Reference

See Chapter 18 for more on the security manager and security policy file.

Authorization regulates, by defined security policies, that the subjects only access their permissions and perform actions based on those permissions. Any subject without specific permissions should not be allowed system resources. All systems have users and the system role responsible for assigning the permissions to specific subjects, which sometimes is called root or admin. Accessing resources in this way is dated back to the beginning of the UNIX operating system, and since there are specific permissions associated to a subject and there is discretion as to which subjects get which permissions. This type of security is called the Discretionary Access Control (DAC) model.

The DAC model specifies that the owner of each file can determine who else can access it by setting the file's permission bits, and it is the reason why the DAC model is sometimes called the owner-based model. One of the issues with this model is that anyone who has read access to a file can copy the file and give it to another user.

In the JAAS model, the security manager is the root process that may check permissions to determine if the principal has access to the system resource. JAAS is the specification that is now part of using the JDK 1.4, and the access is no longer dependent on the operating system. Listing 19-8 demonstrates the subject requesting permission to access a privileged action using the doAs method. Listing 19-15 demonstrates the privileged action.

Listing 19-15: The JAASAction class: A privileged action example

 package com.richware.chap19;     import java.security.*; import java.util.*; import javax.security.auth.*; import javax.security.auth.login.*; import javax.security.auth.x500.*; import java.io.*;     /**  * Class JAASAction  * Description: This is a Sample PrivilegedAction implementation  * to read the secretinfo.txt file.  *  * Copyright:    Copyright (c) 2002 Wiley Publishing, Inc.  * @author Rich Helton <rhelton@richware.com>  * @version 1.0    * DISCLAIMER: Please refer to the disclaimer at the beginning of this book.  */ public class JAASAction implements PrivilegedAction  {   /**    * Method run    * Description: Run the printing of secret info    *    *    * @return the running object    *    */   public Object run()    {     try      {       printSecretText();       return this;           /*        * Catches        */     }     catch (Exception ex)      {       ex.printStackTrace();     }         return null;   }       /**    * Method printSecretText    * Description: Print the secret text from a file    */   public void printSecretText()    {     try      {       FileReader in   = new FileReader("secretinfo.txt");       char[]     buff = new char[50];       int        nch;       while ((nch = in.read(buff, 0, buff.length)) != -1)        {         System.out.println(buff);       }       in.close();     }     catch (Exception ex)      {       ex.printStackTrace();     }   } }

Listing 19-15 demonstrates the privileged action that is called in the JAAS application from Listing 19-8. The privileged action is called privileged because any time that a system resource is being accessed, the security manager does a permission lookup to see if the principal has the required permissions. In the example in Listing 19-15, no system is accessed until the read of the file secretinfo.txt . The secretinfo.txt file is a system resource.

When accessing a file, the permission java.io.FilePermission must be defined for the principal. An operation must also be defined for the permission. The read action on the secretinfo.txt file must be specified for access to read the file. Listing 19-12 gave the X500Principal access for all permissions, so the alias for richh may read the file. If the principal does not match the user in this case, then the principal will have no access to system resources. Figure 19-3 gives a sequence overview of the subject and privileged action.

Figure 19-3: Java Authorization Class interaction

Understanding the subject

To understand the how to implement a subject, a configuration identifying the resources that must be accessed by the principal must be defined. If no principal is explicitly defined, then it is implicit that all principals have access to the permission set. To use the subject for accessing the system resource, the security manager must be defined. To explicitly use a particular subject, the Subject 's class doAs() and doAsPrivileged() methods can be used to execute a privileged action. Once a subject is instantiated and authenticated, it provides the facilities to store a set of principals, private credentials, and public credentials.

Principals and credentials

After a user logs in to a system, a name is attached to the user, and each specific name attached to the subject as identification is a principal . A credential is a token for security access, such as a password or Kerberos certificate. The principal is the name of the subject trying to access a system resource, and the credential is the security token for verifying that subject's principal. A single subject to authenticate and authorize through multiple authentication mechanisms and authorization systems may use multiple principals and credentials. In an enterprise system, the subject may be passed through many authorization systems.

The credential can be either public or private key type. The key is a private key for the private credential , and for the public credential , the key acts like a public key. Credentials are a security token associated with a principal meant to give the user access to the resource. Credentials may include passwords, Kerberos tickets, and data related to authentication throughout the system. The subject only becomes a principal after a successful authentication into the system. The subject also maintains a set of principals because a user might take on many names throughout an enterprise system on the different tiers of authentication.

Initiating and caller principals

These resources cannot only be static, such as a file, but also dynamic such as a running process. The initiating principal can be turned over to a caller principal . An example of an initiating principal is when a user logs in to an e-commerce system. An example of the caller principal is when a principal is trying to access a system resource. In some cases, these principals may be the same, but in others they may be different.

An example of when they are different is when a customer logs in to a Web site but needs to access the database to get his or her record. The customer does not have access to most organizations' databases directly, so the customer is masked as a user that has the rights to the database for access. The customer, in this case, is the initiating principal and the user that has the access to the database is the caller principal. The caller principal could be a role or group that the customer is assigned to once he is authenticated.

Groups

A group refers to a subject containing a set of principals that are managed equally. The group could be an identity that contains multiple identities. The reason for the group concept is because the access across the system may change from resource to resource, and it is difficult to set the accesses to each resource individually.

Therefore, when a set of principals is created, each principal in the set is managed in the same way. The principal is a named identifier of groups and users to authorize a system resource. A principal can be a user, group, computer resource, or a computer component. Figure 19-4 shows a diagram of the Java subject.

Figure 19-4: The Java subject

As mentioned, principals can be people, organizations, daemon threads, or even smart cards. Once a principal is established in a subject, the principal's name is immutable, meaning it cannot change once initialized . Using the subject's principal and credential sets can further authorize and authenticate throughout multiple systems. Figure 19-5 demonstrates these concepts with an extended Java subject.

Figure 19-5: The Java subject extended

Many different classes of principals and credentials come distributed in the JDK 1.4. Some of these principals, like the NTUserPrincipal , are specific to the WinNT operating system. Others, like the X500Principal, are specific for support of a protocol, in this case the X.500 Directory Protocol. Many of these can be found in the com.sun.security.auth package.

Understanding groups

Because there could be many users accessing a system, in some systems thousands and even hundreds of thousands, it can be very time consuming to manage the users individually, so groups are needed. A group is a set of users that have the same permissions. Groups allows many principals to be associated with a set of permissions and associated system resources.

For instance, if an administrator wants to give access to many users at once, the administrator creates a group that consists of all the users. Since a group itself is a principal, groups can present a hierarchy of principals, meaning that one of the entries in a group can be another group. The concept of hierarchical groups makes it possible for some "user" groups to belong to an admin group. The group class is defined in java.security.acl.Group as shown in Figure 19-6.

Figure 19-6: The Java group

Understanding permissions

The java.security.acl.Permission class is an abstract class representing a system resource and the desired actions for the system resource. For instance, a subject might want to access a file resource and read from it, so the action would be a read , and the system resource would be a particular file. However, system resources can have a wide range of actions, and they can vary based on the system resource. For example, a file could be executed using the execute permission, but a Socket doesn't understand what execute means.

There are many extensions to the base Permission class, specific to a system resource, to ensure that the appropriate actions and other attributes, such as how files are named, are associated with the correct permission. Some of these permissions are for File, Socket, Property, Runtime, AWT, Net, Security, Serializable, and Reflection classes. An association for a permission is also between the resource type, operation, and resource name. Listing 19-16 shows a permission association allowing the user's home directory to be read.

Listing 19-16: A permission entry

 //Allow the user's home directory to be read permission java.io.FilePermission "${user.home}/-", "read";

Listing 19-16 demonstrates a java.io.FilePermission. The file permission has the actions of read, write, execute, and delete. FilePermission formats for naming the file information is platform dependent. Listing 19-16 specifies the macro for the user.home in a UNIX format. Some of the Permission classes from Java exist in the following formats:

java.security.BasicPermission . This is the permission base class for most of the Permission classes, such as SocketPermission , PropertyPermission , RuntimePermission , AWTPermission, and others. It extends the Permission class to include actions and simply allows or blocks permission. There are no other operations for the permission to support.
java.net.SocketPermission . Actions are accept, listen, connect, and resolve. This class represents access to the network through the socket API. The access is dependent on the host name, through a DNS name, or an IP address is specified with the range of port numbers . The port or port range is optional. The following example gives access for connection to a client and accepting connections from a server for the local machine for the port 1024 and above:
```
 //Allow the user's home directory to be read  permission java.net.SocketPermission "localhost:1024/-",  "connect,accept"; 
```
java.util.PropertyPermission . Actions are read and write. This class provides access for getting local or system properties defined in the environment. Access can be denied for the read permission, for the System.getProperty method, and write permission, for the System.setProperty method. An example to grant the user testUser the read permission for the java.home directory is as follows :
```
 grant codebase "file:./sample_action.jar",  Principal SamplePrincipal "testUser" {        permission java.util.PropertyPermission "java.home", "read"; }; 
```
java.lang.RuntimePermission . There are no actions in this policy. There are no target names involved because you either have the permissions or you do not. In the following example, the first entry shows accessing the specified package name "*", meaning any package, via a class loader's loadClass method. The second entry shows accessing all declared members of a class. The third field gives access to create a class loader. The last field can be a large security risk because it gives the applications the capability to load their own rogue class loaders that, in turn , can load their own rogue classes into the system.
```
 grant codebase "file:./sample_action.jar",  Principal SamplePrincipal "testUser" {   permission java.lang.RuntimePermission "accessClassInPackage.*";   permission java.lang.RuntimePermission "accessDeclaredMembers.*";   permission java.lang.RuntimePermission "createClassLoader"; }; 
```
java.awt.AWTPermission . There are no actions in this policy. It gives the user to a specific AWT resource, such as accessing the Clipboard. The following example grants the user testUser access to the event queue and Clipboard:
```
 Grant codebase "file:./sample_action.jar",  Principal SamplePrincipal "testUser" {    permission java.awt.AWTPermission "accessClipboard";    permission java.awt.AWTPermission "accessEventQueue"; }; 
```

java.security.SecurityPermission . There are no actions; the following example shows how SecurityPermission is used:

 Grant codebase "file:./sample_action.jar",  Principal SamplePrincipal "testUser" {   permission java.security.SecurityPermission "getPolicy";   permission java.security.SecurityPermission "setPolicy"; };

java.lang.reflect.ReflectionPermission . This is the Permission class for reflective operations that are part of introspection. Introspection is the capability of a class to examine itself to understand what type of object it belongs in and get data based on its members. There are no targets because it gives access to all classes or it does not. There are also no actions because all that exists is the Permission descriptor to give all access in the suppressAccessChecks or not to give all access. This policy could be a security risk as it no longer relies on the classes' encapsulation and gives access for reflective programs to access protected and private members. Here is an example:
```
 grant codebase "file:./sample_action.jar",  Principal SamplePrincipal "testUser" {   permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; }; 
```
java.security.AllPermission . This Permission class gives all or no access to a user. The following example gives the user testUser all permissions:
```
 Grant codebase "file:./sample_action.jar",  Principal SamplePrincipal "testUser" {   permission java.security.AllPermission; }; 
```

java.security.AuthPermission . This Permission class gives all authentications or no authentication to a user. The following lines give the user testUser all permissions:

 Grant codebase "file:./sample_action.jar",  Principal SamplePrincipal "testUser" {    permission javax.security.auth.AuthPermission  "createLoginContext.Sample";    permission javax.security.auth.AuthPermission "doAs"; };

Understanding ACLs

The DAC model has also been enhanced over the years , from the structure of UNIX files and directories. The Java 2 security manager model implements the DAC model and is a standard interface shipped with the JDK v1.4. The DAC model can further store entries outside of configuration files in the form of Access Control Lists (ACL). The ACL is a data structure for security objects, such as the ones mentioned earlier (permissions, groups, and principals).

So far, the discussion has been centered on the security policy file that stores the principal, permissions, and resource entries. The ACL data structure can form relationships with other permission sets, groups, principals, and resources. The ACL is a named object that represents the system resource. Because this model is very generic, it can easily suit access control requirements for any system.

Each ACL has a list of AclEntry objects. An AclEntry associates an implemented principal, such as NTUserPrincipal having the name of rich , with a permission object, such as read. Permissions normally have a plus sign associated with them to allow the permission and a minus sign to deny permissions. The AclEntry accommodates this by having a boolean flag set to true if it is a negative, or minus, permission. Figure 19-7 demonstrates the Java ACL and AclEntry objects.

Figure 19-7: ACL and AclEntry objects

The ACL and its associated AclEntry lists have several objects that have relationships. These relationships can be formed in a relational database of the LDAP server. The advantages of this architecture include its relationship nature and the capability to decouple the individual objects from the list when needed. Storing these objects in a centralized area also promotes having all the security information, permissions, subjects, and resources in a centralized data store. An LDAP server is an implementation of an organization's security realm.

A security realm is the central location for storing information across an enterprise system. Figure 19-8 gives an example of a database relationship.

Figure 19-8: The Java ACL table

Using a table like the one in Figure 19-8 centralizes all the security resources in a centralized table. A centralized data store provides a convenient management facility with all security information in the same location and in the same form. Centralizing the security material into one location can help the user understand and modify the security resources more easily.

Table of content

Java Security Solutions

ISBN: 0764549286
EAN: 2147483647

Year: 2001
Pages: 222

Authors: Rich Helton, Johennie Helton

BUY ON AMAZON

WebLogic: The Definitive Guide

Snort Cookbook

MySQL Cookbook

Microsoft WSH and VBScript Programming for the Absolute Beginner

InDesign Type: Professional Typography with Adobe InDesign CS2

HTI+ Home Technology Integrator & CEDIA Installer I All-In-One Exam Guide