Release 2 (9.0.2)
Part Number A95879-01
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle9iAS Containers for J2EE Services Guide Release 2 (9.0.2) Part Number A95879-01 |
|
This chapter introduces support for Java Authentication and Authorization (JAAS), in Oracle9iAS Containers for J2EE (OC4J). JAAS enables application developers to integrate authentication, authorization, and delegation services with their applications.
This chapter contains these topics:
JAAS is a Java package which enables applications to authenticate and enforce access control.
Oracle9iAS supports JAAS by implementing a JAAS provider. The JAAS provider provides application developers with user authentication, authorization, and delegation services to integrate into their application environments. Instead of devoting resources to developing these services, application developers can focus on the presentation and business logic of their applications.
Authentication is the process of verifying the identity of a user, device, or other entity in a computer system, often as a prerequisite to granting this entity access to resources in a system. For example, when a user enters a username and password to access resources on a computer, such as a database, the user must first be authenticated (verified) by means of the login information before being permitted access to these resources.
Once a user's username and password have been authenticated, the authorization process occurs. Authorization is the process of determining the following for the authenticated user: Who has the right to perform an operation on an object (such as updating a table in a database)?
Delegation provides support for impersonation of a specified user. An application can be configured to run with the permissions associated with specified user by means of the run-as element.
The JAAS framework and the Java2 Security model form the foundation of the JAAS provider. That is, the JAAS provider implements JAAS and integrates with J2SE and J2EE applications that use the Java2 Security model.
The JAAS provider implements support for JAAS policies. Policies contain the rules (permissions) that authorize a user to use resources, such as reading a file. JAAS enables services to authenticate and enforce access control upon users of these resources.
The JAAS provider integrates with J2SE and J2EE applications that use the Java2 Security Model. Unlike the original Java security model, under Java2 security, many levels of restrictions can be configured.
Developers can easily integrate the JAAS provider with these applications for quick development and deployment:
Section , "Integrating the JAAS Provider with Basic Authentication" for additional information on the J2SE and J2EE environments
See Also:
The JAAS provider supports two types of repository providers, referred to as provider types.
These provider types are repositories for secure, centralized storage, retrieval, and administration of provider data. This data consists of realm (users and roles) and JAAS policy (permissions) information.
Use the provider type appropriate to your environment.
The LDAP-based provider type is based on the Lightweight Directory Access Protocol (LDAP) for centralized storage of information in a directory. Oracle9iAS only uses the LDAP-based Oracle Internet Directory.
Use this provider type if you are using Oracle9iAS and Oracle Internet Directory.
The XML-based provider type is used for lightweight storage of information in XML files.
Use this provider type if you are using an XML file, such as jazn-data.xml, to store your user and realm information.
Sun's Java2 Security Model is fundamental to the JAAS provider.
The Java2 Security Model enables configuration of security at all levels of restriction. This provides developers and administrators with increased control over many aspects of enterprise applet, component, servlet, and application security.
The Java2 Security Model is capability-based and enables you to establish protection domains, and set security policies for these domains. When the JAAS provider is integrated with applications developed for the J2SE or J2EE environments, these environments use the Java2 Security Model to different degrees.
Permissions are the basis of the Java2 Security Model. All Java classes (whether run locally or downloaded remotely) are subject to a configured security policy that defines the set of permissions available for those classes. Each permission represents a specific access to a particular resource. Table 4-1 identifies the elements that comprise a Java permission instance:
Each Java class, when loaded, is associated with a protection domain. Protection domains can be configured for all levels of restriction (from complete restriction on resources to full access to all resources). Each protection domain is assigned a group of permissions based on a configured security policy at Java virtual machine (JVM) startup.
At runtime, the authorization check is done by stack introspection. This consists of reviewing the runtime stack and checking permissions based on the protection domains associated with the classes on the stack. This is typically triggered by a call to either:
The permission set in effect is defined as the intersection of all permission sets assigned to protection domains at the moment of the security check.
Figure 4-1 shows the basic model for authorization checking at runtime.
Table 4-2 describes the permission classes provided by the JAAS provider that enables you to enforce access upon users of resources.
| Permission | Part of Package... | Description | See Also... |
|---|---|---|---|
|
|
|
Represents the right to administer a permission (that is, grant or revoke another user's permission assignment) |
"AdminPermission" for specific syntax examples |
|
|
|
The grantee of this permission is granted the right to further grant/revoke the target role. |
|
|
|
|
For authorization permissions. |
"JAZNPermission" for a list of target names for |
|
|
|
Represents permission actions for a realm (such as |
"RealmPermission" for a list of permission actions |
|
See Also:
|
The JAAS interface is implemented by the JAAS provider. JAAS is a Java package that enables applications to authenticate and enforce access controls upon users.
JAAS is designed to complement the existing code-based security in JDK 1.3. JAAS implements a Java version of the standard Pluggable Authentication Module (PAM) framework. This enables an application to remain independent from the authentication service.
JAAS extends the access control architecture of the Java2 Security Model to support principal-based authorization.
This section describes JAAS support for the following authorization, authentication, and user community (realm) features. Some of these features are fully supported in this release of JAAS, while others are not explicitly defined. The JAAS provider provides enhancements to some of these features.
See Also:
http://java.sun.com/products/jaas/
A principal is a specific identity, such as a user named frank or a role named hr. A principal is associated with a subject upon successful authentication to a computing service.
A principal is represented by an instance of a concrete class that implements the java.security.Principal interface. Each class defines a namespace for its instances, within which each principal instance has a unique name. The name and class of a principal instance uniquely describes the instance.
For LDAP-based environments, an X500Principal class is defined that accepts the X.500 style name as the name of the principal.
A subject represents a grouping of related information for a single user of a computing service, such as a person, computer, or process. Such information includes the subject's identities and security-related attributes (such as passwords and cryptographic keys).
Subjects can have multiple identities, where principals represent identities in the subject. A subject becomes associated with a principal (user frank) upon successful authentication to a computing service, that is, the subject provides evidence (such as a password) to prove its identity.
Principals bind names to a subject. For example, a person subject, user frank, may have two principals:
frank doe (name on his driver license) to the subject
999-99-9999 (number on his student identification card) to the subject
Both principals refer to the same subject.
Subjects can also own security-related attributes (known as credentials). Sensitive credentials requiring special protection, such as private cryptographic keys, are stored in a private credential set. Credentials intended to be shared, such as public key certificates or Kerberos server tickets are stored in a public credential set. Different permissions are required to access and modify different credential sets.
Subjects are represented by the javax.security.auth.Subject class.
To perform work as a particular subject, an application invokes the method Subject.doAs(Subject, PrivilegedAction) (or one of its variations). This method associates the subject with the current thread's AccessControlContext, and then executes the specified request.
To associate a principal (such as frank) with a subject, a client attempts to log into 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.
Since the LoginContext separates the application code from the authentication services, a different login module can be plugged in under an application without affecting the application code.
Actual authentication occurs with the method LoginContext.login(). If authentication succeeds, the authenticated subject can be retrieved by invoking LoginContext.getSubject(). The real authentication process can involve multiple login modules. JAAS 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 Subject.doAs().
JAAS does not explicitly define roles or groups. Instead, roles or groups are implemented as concrete classes that use interface java.security.Principal.
JAAS does not define how to support the RBAC role hierarchy (granting a role to a role). The Sun provider of javax.security.auth.Policy recognizes a special type of principal, as defined by the PrincipalComparator interface. However, PrincipalComparator is not fully integrated with the JAAS provider, and is therefore not supported.
For LDAP-based environments, an X500GroupPrincipal class is defined that accepts an X.500 style name as the name of the group.
JAAS 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. The J2EE RI Realm API, however, is:
See Also:
JAAS does not explicitly define an application or subsystem for partitioning authorization rules. However, JAAS meets many of the requirements for the subsystem concept. For example, JAAS defines the notion of a codebase (plus a signer) as the target and grantee of a grant statement. This enables permissions to be granted application-specific code. The Java notion of namespace partitioning through packages also allows for partitioning of permission classes in an application-specific manner.
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 JAAS provider. JAAS does not define an administrative API for policy administration. The administrative API is implementation specific.
Table 4-3 describes Sun's implementation of policy file parameters.
| Where... | Is Defined As... | Example |
|---|---|---|
|
subject |
one or more principal(s) |
|
|
codesource |
|
|
The following example shows a typical entry in the JAAS policy file as implemented by Sun's implementation of the JAAS file-based policy provider:
grant CodeBase "http://www.foo.com",
Principal com.sun.security.auth.SolarisPrincipal "duke"
{
permission java.io.FilePermission "/home/duke", "read, write";
};
Code from www.foo.com, signed by foo, and running as a SolarisPrincipal with the username duke, has the permission that permits the executing code to read and write files in /home/duke.
The JAAS provider also provides an XML file to store policy information. In the following example, a segment of the jazn-data.xml file grants the jazn.com /administrators various permissions:
<!--JAZN Policy Data --> <jazn-policy> <grant> <grantee> <principals> <principal> <realm>jazn.com/realm> <type>role/type> <class>oracle.security.jazn.spi.xml.XMLRealmRole </class> <name>jazn.com/administrators/name> </principal> </principals> </grantee> <permissions> <permission> <class>oracle.security.jazn.policy.AdminPermission</class> <name>oracle.security.jazn.realm.
RealmPermission$jazn.com$modifyrealmmetadata</name> </permission> <permission> <class>oracle.security.jazn.policy.AdminPermission</class> <name>oracle.security.jazn.realm.
RealmPermission$jazn.com$droprealm</name> </permission> <permission> <class>oracle.security.jazn.policy.AdminPermission</class> <name>oracle.security.jazn.realm.RealmPermission$jazn. com$createrole</name> </permission> <permission> <class>oracle.security.jazn.realm.RealmPermission</class> <name>jazn.com</name> <actions>createrealm</actions> </permission> </permissions> </grant> </jazn-policy>
|
See Also:
|
Table 4-4 lists the JAAS features provided by Oracle9iAS.
| Feature | Description | See Also... |
|---|---|---|
|
Realms |
Realms provide access to user and role information. An Oracle proprietary Realm API package ( |
|
|
Role-based access control (RBAC) |
Support is provided for secure, centralized, and customizable RBAC management |
|
|
Login Module Authentication |
||
|
JAAS provider type management |
Several methods for managing JAAS provider type information are available: |
|
|
JAZNUserManager |
|
"JAAS Provider Integration in J2SE Application Environments" |
The Oracle9iAS implementation of JAAS provides these user services for application developers to integrate into their applications. This section describes several JAAS provider authorization features.
The capability model is essentially a method for organizing authorization information. The JAAS provider is based on the Java2 Security Model, which uses the capability model of access control to control access to permissions. With the capability model, authorization is associated with the principal (a user named frank in the following example). Table 4-5 shows the permissions that user frank is authorized to use:
| User | Has These File Permissions... |
|---|---|
|
|
Read and write permissions on a file named |
When user frank logs in and is successfully authenticated, the permissions described in Table 4-5 are retrieved from the JAAS provider (whether the LDAP- based Oracle Internet Directory or XML-based provider type) and granted to user frank. User frank is then free to execute the actions permitted by these permissions.
RBAC enables you to assign permissions to roles. Users are then granted their permissions by being made members of appropriate roles. Support for RBAC is a key JAAS provider feature. This section describes the following RBAC features:
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 4-2 provides an example.
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.
A user is typically granted multiple roles. However, not all roles are enabled by default. The user can selectively enable the required roles to accomplish a specific task in a user session with the run-as security identity and Subject.doAS(). This ensures the principle of least privilege. This way, the user is not enabling permissions or privileges unnecessary for the task. This limits the damage that can potentially result from an accident or error.
The JAAS provider supports two types of repository providers, referred to as provider types:
jazn-data.xml
OiD and jazn-data.xml are repositories used to store realm (users and roles) and policy (permissions) information. This section discusses the following topics in relation to the two different provider types:
Several tools are provided for managing realm and policy information. Table 4-6 describes these tools and indicates the environment in which they operate.
| Method/Environment | Description | See Also... |
|---|---|---|
|
LDAP-based only |
A graphical user interface tool that enables you to create principals (known as grantees) and assign permissions to these grantees. |
"Using the Oracle Enterprise Manager Interface with the JAAS Provider" |
|
Both LDAP and XML-based environments |
A command line interface tool that enables administrators to create and manage users, realms, roles, and policies. The JAZN Admintool:
The JAZN Admintool has the same capabilities and limitations as the JAAS Provider APIs. For example, you cannot create users with the JAZN Admintool if your provider type is LDAP-based Oracle Internet Directory. However, you can create users if your provider type is XML-based. |
|
See Also:
|
The J2EE environment defines the concept of user communities. A user community instance is essentially a realm maintained internally by the authorization system.
The API package oracle.security.jazn.realm is provided to support realms. This API package is an enhancement to the JAAS policy provider.
Realms can be managed in both provider type environments:
Provides for centralized storage of realms and JAAS policy in a directory
Provide a lightweight form of storage for realms and JAAS policy
A realm provides user and role management. An LDAP-based realm's data can be managed:
The JAAS provider supports three types of realms for LDAP-based environments. Each realm provides different user and role management capabilities. Table 4-7 describes these realms.
Each realm type consists of:
User and role managers internally perform their duties (through JAAS provider permissions) or externally (through OiD Delegated Administration Service (DAS)).
Figure 4-3 shows a sample LDAP directory information tree (DIT) containing an External Realm that is registered as an instance with the JAAS provider. The realm type is created below a Realms container.
Table 4-8 describes the user and role management responsibilities of the External Realm.
| External Realm Name | Role Management | User Management |
|---|---|---|
|
|
Retrieves external, read-only roles |
Retrieves external, read-only users |
Figure 4-4 shows a sample LDAP directory information tree (DIT) containing a Subscriber Realm that is registered as an instance with the JAAS provider. The realm type is created below a Realms container.
Table 4-9 describes the user and role management responsibilities of the Subscriber Realm.
| Subscriber Realm Name | Role Management | User Management |
|---|---|---|
|
|
Retrieves external, read-only roles of a subscriber |
Retrieves external, read-only users of a subscriber |
Figure 4-5 shows a sample LDAP directory information tree (DIT) containing an Application Realm that is registered as an instance with the JAAS provider. The realm type is created below a Realms container.
Table 4-10 describes the user and role management responsibilities of the Application Realm.
| Application Realm Name | Role Management | User Management |
|---|---|---|
|
|
Internally creates and manages modifiable roles |
Retrieves external, read-only users |
The realm framework provides a means for registering realm instances with the JAAS Provider and managing their information.
A Realms container object is created under the site-wide JAAS context. (For example, see the Realms container in Figure 4-3.) For each registered realm instance, a corresponding realm entry is created under the Realms container that stores the realm's attributes. This directory hierarchy is known to the JAAS provider, which enables the JAAS provider to create new realm instances in the desirable directory location and find all the registered realms in runtime.
For example, the distinguished name (DN) for a realm called oracle can be "cn=oracle,cn=realms,cn=JAZNContext,cn=site root".
Upon successful installation of the JAAS provider, a default realm (External Realm) instance is installed. Predefined realm properties are configured for starting the default realm. Any realm type must provide concrete implementations for the system defined Java interfaces UserManager and RoleManager. In runtime, the JAAS provider finds all the registered realms and their attributes (name, user manager implementation class, role manager implementation class, and their properties) from the provider type (Oracle Internet Directory) and instantiates the realm's implementation class with the properties for initialization.
A RealmPermission class is defined to represent realm permissions. RealmPermission extends from java.security. Permission. It is used like any regular Java permission. RealmPermission has the following characteristics:
See Also:
A realm provides user and role management. For XML-based environments, realm management is less restrictive and faster: a more lightweight implementation than LDAP-based realm management.
The JAAS provider enables you to create a single realm type for an XML-based environment.
|
See Also:
"Using the JAZN Admintool" for instructions on creating realm types. |
An XML-based realm enables you to:
This information is stored in an XML file, typically, jazn-data.xml. The following example shows the structure used in a jazn-data.xml file to create realms, users, and roles.
<!--JAZN Realm Data --> <jazn-realm> <realm> <name>jazn.com</name> <users> <user> <name>admin</name> <displayName>Realm Administrator</displayName> <description>Administrator for this realm</description> <credentials>Qj+w7NJulLM=</credentials> </user> <user> <name>anonymous</name> <description>The default guest/anonymous user</description> </user> </users> <roles> <role> <name>guests</name> <members> <member> <type>user</type> <name>admin</name> </member> <member> <type>user</type> <name>anonymous</name> </member> </members> </role> <role> <name>administrators</name> <displayName>Realm Admin Role</displayName> <description>Administrative role for this realm</description> <members> <member> <type>user</type> <name>admin</name> </member> </members> </role> <role> <name>users</name> <members> <member> <type>user</type> <name>admin</name> </member> </members> </role> </roles> </realm> </jazn-realm>
|
See Also:
"Sample jazn-data.xml Code" for a completed |
The JAAS provider implementation of javax.security.auth.Policy uses either an LDAP-based Oracle Internet Directory or XML-based provider type for storing policy (authorization rules). The JAAS provider administrator uses various grant and revoke methods of the JAZNPolicy class to create authorization policies for principals.
The provider must be administered in a secure manner. There are several ways to administer the JAAS provider policy:
Table 4-6 for information on Oracle Enterprise Manager and "Using the JAZN Admintool" for information on the JAZN Admintool
See Also:
For LDAP-based application environments, you manage realm and policy data as Oracle Internet Directory entries through:
Two possible administrative groups can manage the data:
JAZNContext and any subscriber-specific JAZNContext
In hosted application environments, part of the policy data may be partitioned along subscriber boundaries and thus stored in a subscriber subtree. That policy data cannot be administered by the realm-specific administrative group. The same is true with role information.
With the JAAS provider policy data (including realm data), only users that belong to JAZNClientGroup or JAZNAdminGroup have read-access capabilities on provider data.
The LDAP-based environment caches provider policy data; for details, see "Managing JAAS Provider Policy" on page 36.
The AdminPermission class can be used in either LDAP-based or XML-based environments.
The AdminPermission class represents the right to administer a permission. This enables a grantee (such as a user named frank) to further grant and revoke the granted right/permission to other grantees. Instances of this permission class include instances of other permissions. Since this is a permission about permission, it varies slightly from the permission definition, which includes a simple name, actions pair. This variation is resolved by encoding a permission instance as a string and using that as the name of the AdminPermission instance. Table 4-11 provides an example:
When expressed in the format recognized by the policy provider, this results in the following:
grant Principal com.oracle.security.jazn.JAZNPrincipal "frank" { permission com.oracle.security.jazn.policy.AdminPermission "class=java.io.FilePermission, name=\"/tmp/*\", actions=\"read, write\"" };
Note that another permission instance is encoded in the target name for this AdminPermission instance.
Recursive embedding of AdminPermission (that is, an AdminPermission instance embedded within another AdminPermission instance) is not supported. In the initial policy, the JAAS user is granted AdminPermission to java.security.AllPermission, enabling the JAAS user to grant and revoke all permissions to anyone.
A RoleAdminPermission class is defined for roles. This means that when role hr is granted to frank, frank is granted both role hr and a RoleAdminPermission that enables frank to further grant and revoke role hr.
|
See Also:
"Policies and Permissions" for an example of an XML-based policy file |
The JAAS provider supports policy partitioning among realms (that is, each realm has its own realm-specific policy). This realm-specific policy is administered by the realm-specific administrative group.
In a hosted environment, a subscriber is represented by a realm and the subscriber-specific information subtree is stored under a subscriber-specific JAZNContext. This subscriber-specific subtree, however, is primarily administered by the JAAS Provider administrative group from the perspective of the LDAP server (Oracle Internet Directory).
|
 Copyright © 2002 Oracle Corporation. All Rights Reserved. |
|