2 Overview of JAAS in Oracle Application Server

Provider Types

The OC4J JAAS implementation supports two different provider types. Each provider type implements a repository for secure, centralized storage, retrieval, and administration of provider data. This data consists of realm (users and roles) and JAAS policy (permissions) information.

• XML-based provider

  The XML-based provider is used for lightweight storage of information in XML files. The XML-based provider stores user, realm, and policy information in an XML file, normally jazn-data.xml.

  
  

  Note: XML files are used as property and configuration files by both LDAP-based and XML-based provider types. However, only the XML-based provider stores users, realms, and policies in an XML file, jazn-data.xml.

  
  

• LDAP-based provider

  The LDAP-based provider is based on the Lightweight Directory Access Protocol (LDAP) for centralized storage of information in a directory. The LDAP-based provider stores user, realm, and policy information in the LDAP-based Oracle Internet Directory.

  
  

  Note: We recommend that you use the LDAP-based provider in a production environment; the XML-based provider is suitable for prototyping only.

  
  

Login Module Authentication

To associate a principal (such as frank) with a subject, a client attempts to log in to an application. In login module authentication, the LoginContext class provides the basic methods used to authenticate subjects such as users, roles, or computing services. The LoginContext class consults configuration settings to determine whether the authentication modules (known as login modules) are configured for use with the particular application that the subject is attempting to access. Different login modules can be configured with different applications; furthermore, a single application can use multiple login modules.

Because the LoginContext separates the application code from the authentication services, you can plug a different login module into an application without affecting the application code.

Actual authentication is performed by the LoginContext.login() method. If authentication succeeds, then the authenticated subject can be retrieved by invoking the LoginContext.getSubject() method. The real authentication process can involve multiple login modules. The JAAS framework defines a two-phase authentication process to coordinate the login modules configured for an application.

After retrieving the subject from the LoginContext, the application then performs work as the subject by invoking the Subject.doAs() or Subject.doAsPrivileged() method.

Roles

The JAAS framework does not explicitly define roles or groups. Instead, roles or groups are implemented as concrete classes that use the java.security.Principal interface.

The JAAS framework does not define how to support the role-based access control (RBAC) role hierarchy, in which you can grant a role to a role.

Realms

The JAAS framework does not explicitly define user communities. However, the J2EE reference implementation (RI) defines a similar concept of user communities called realms. A realm provides access to users and roles (groups) and optionally provides administrative functionality. A user community instance is essentially a realm that is maintained internally by the authorization system. The J2EE RI Realm API supports user-defined realms through subclassing.

Applications

The JAAS framework does not explicitly define an application or subsystem for partitioning authorization rules.

Policies and Permissions

A policy is a repository of JAAS authorization rules. The policy includes grants of permissions to principals, thus answering the question: "Given a grantee, what are the granted permissions of the grantee?"

Policy information is supplied by the OracleAS JAAS Provider. The JAAS framework does not define an administrative API for policy administration. The administrative API provided by the OracleAS JAAS Provider is an Oracle extension.

Table 2-1 describes the Sun Microsystems implementation of policy file parameters.

<jazn-policy>
  <grant>
   <grantee>
     <principals>
      <principal>
        <class>oracle.security.jazn.samples.SampleUser</class>
        <name>admin</name>
      </principal>
    </principals>
   </grantee>
   <permissions>
     <permission>
       <class>oracle.j2ee.server.rmi.RMIPermission</class>
       <name>login</name>
     </permission>
   </permissions>
  </grant>
</jazn-policy>

Using JAZNUserManager

The JAZNUserManager class is the default user manager. The primary purpose of the JAZNUserManager class is to leverage the OracleAS JAAS Provider as the security infrastructure for OC4J.

There are two JAAS providers supplied with OC4J security: XML-based and LDAP-based.

• The XML-based provider is a fast, lightweight implementation of the JAAS Provider API. This provider type uses XML to store user names and encrypted passwords. The user repository is stored in the jazn-data.xml file, in a location specified in the jazn.xml file. For details, see Chapter 8, "Configuring the XML-Based Provider".

  Select JAZN-XML as the user manager in the Enterprise Manager. Configure its users, roles, and groups using the JAZN Admintool.

• The LDAP-based provider is scalable, secure, enterprise-ready, and integrated with OracleAS Single Sign-On. The LDAP-based provider is the only OracleAS JAAS Provider that supports OracleAS Single Sign-On.

  Select JAZN-LDAP as the user manager in the Enterprise Manager. Configure its users and groups using the Oracle Delegated Administration Services from Oracle Internet Directory. The user repository is an Oracle Internet Directory instance, which requires that the application server instance be associated with an infrastructure. If it the server is not associated with an Oracle Internet Directory instance, then the LDAP-based provider is not a security option.For information on configuring the LDAP-based provider, see Chapter 7, "Configuring the LDAP-Based Provider".

Figure 2-1 shows the two different JAAS providers supplied with OC4J.

Figure 2-1 OC4J Security Architecture under the JAZNUserManager Class

Description of "Figure 2-1 OC4J Security Architecture under the JAZNUserManager Class"

Using XMLUserManager

The XMLUserManager class is a simple user manager that manages users, groups, and roles in an XML-based system. It stores user passwords in the clear, and therefore is not as secure as the JAZNUserManager. All XMLUserManager configuration information is stored in the principals.xml file, which is the user repository for the XMLUserManager class.

Role Hierarchy

RBAC simplifies the management problems created by direct assignment of permissions to users. Assigning permissions directly to multiple users is potentially a major management task. If multiple users no longer require access to a specific permission, you must individually remove that permission from each user.

Instead of directly assigning permissions to users, permissions are assigned to a role, and users are granted their permissions by being made members of that role. Multiple roles can be granted to a user. A role can also be granted to another role, thus forming a role hierarchy that provides administrators with a tool to model enterprise security policies. Figure 2-2 provides an example of role-based access control.

Figure 2-2 Role-Based Access Control

Description of "Figure 2-2 Role-Based Access Control"

When a user's responsibilities change (for example, through a promotion), the user's authorization information is easily updated by assigning a different role to the user instead of a massive update of access control lists containing entries for that individual user.

For example, if multiple users no longer require write permissions on a file named salaries in the /home/user directory, those privileges are removed from the HR role. All members of the HR role then have their permissions and privileges automatically updated.

Role Activation

A user is typically granted multiple roles. However, not all roles are enabled by default. An application can selectively enable the required roles to accomplish a specific task in a user session with the run-as security identity and Subject.doAS() method. Selectively enabling roles upholds the principle of least privilege—the application is not enabling permissions or privileges unnecessary for the task. This limits the damage that can potentially result from an accident or error.