OracleŽ Application Server Containers for J2EE Security Guide 10g (9.0.4) Part Number Part No. B10325-02 |
|
This chapter introduces support for Oracle Application Server Java Authentication and Authorization Service (JAAS), in Oracle Application Server Containers for J2EE (OC4J). JAAS enables application developers to integrate authentication, authorization, and delegation services with their applications.
This chapter contains these topics:
OracleAS supports JAAS by implementing a JAAS Provider. The JAAS Provider implements user authentication, authorization, and delegation services that developers can 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.
The JAAS framework and the Java 2 Security model form the foundation of JAAS. The OracleAS JAAS Provider implements support for JAAS policies. Policies contain the rules (permissions) that authorize a user to use resources, such as reading a file. Using JAAS, services can authenticate and enforce access control upon resource users. The JAAS Provider is easily integrated with J2SE and J2EE applications that use the Java 2 Security model.
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.
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.
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.
JAAS is a Java package that enables applications to authenticate and enforce access controls upon users. The JAAS Provider is an implementation of the JAAS interface.
JAAS is designed to complement the existing code-based Java 2 security. 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 Java 2 Security Model to support principal-based authorization.
This section describes JAAS support for the following authentication, authorization, and user community (realm) features. The JAAS Provider enhances some of these features.
See Also:
http://java.sun.com/products/jaas/
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; 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 method LoginContext.login()
. If authentication succeeds, then the authenticated subject can be retrieved by invoking LoginContext.getSubject()
. 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 Subject.doAs()
or Subject.doAsPrivileged()
.
The JAAS framework does not explicitly define roles or groups. Instead, roles or groups are implemented as concrete classes that use the interface java.security.Principal
.
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.
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.
See Also:
"JAAS Provider Realm Framework" for JAAS Provider enhancements to realms |
The JAAS framework does not explicitly define an application or subsystem for partitioning authorization rules.
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. The JAAS framework does not define an administrative API for policy administration. The administrative API provided by the JAAS Provider is an Oracle extension.
Table 2-1 describes the Sun Microsystems 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 policy provider:
grant CodeBase "http://www.example.com", Principal com.sun.security.auth.SolarisPrincipal "duke" { permission java.io.FilePermission "/home/duke", "read, write"; };
Code from www.example.com
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 XML-based provider can store policy data in the file jazn-data.xml
. In the following example, a segment of the jazn-data.xml
file grants the jazn.com /administrators
permission to modify realm data, to drop realms, and to create roles:
<!--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 2-2 contains the JAAS framework features implemented by the Oracle Application Server JAAS Provider.
Feature | Description | See Also |
---|---|---|
Authentication |
||
Declarative Model |
||
Role-based access control (RBAC) |
||
Realms |
||
Management |
||
|
OC4J security employs a user manager to authenticate and authorize users and groups that attempt to access a J2EE application. You base your choice of user manager on performance and security needs.
All UserManager
classes implement the com.evermind.security.UserManager
interface. UserManager
classes manage users, groups, and passwords through methods such as createUser()
, getUser()
, and getGroup()
.
OC4J provides two predefined user managers, JAZNUserManager and XMLUserManager
. JAZNUserManager
supports both XML-based and LDAP-based providers. We recommend using JAZNUserManager
because it is based on the JAAS specification and is integrated with Oracle Application Server Single Sign-On and Oracle Internet Directory. JAZNUserManager
is the default security provider, because it offers powerful and flexible security control. Customers can also supply their own classes that implement the UserManager
interface.
Note:
For a discussion of creating a custom |
Table 2-3 lists the user managers provided by OC4J.
User Manager Class | User Repository |
---|---|
|
Two types: |
|
|
Custom user manager |
Customized user repository |
See "Specifying UserManagers" for directions on how to use Enterprise Manager to define the default UserManager
for all applications or a single UserManager
for a specific application.
The following sections describe the JAZN and XML user managers:
The JAZNUserManager
class is the default user manager. The primary purpose of the JAZNUserManager
class is to leverage the JAAS Provider as the security infrastructure for OC4J.
There are two JAAS Providers supplied with OC4J security: XML-based and LDAP-based.
jazn-data.xml
file, in a location specified in the jazn.xml file. For details, see Chapter 3, "Configuring And Deploying the JAAS Provider".
Select JAZN-XML as the user manager in the Enterprise Manager. Configure its users, roles, and groups using the JAZN Admintool. For information on the Admintool, see Chapter 5, "Using the JAZN Admintool".
Select JAZN-LDAP as the user manager in the Enterprise Manager. Configure its users and groups using the Delegated Administrative Service (DAS) 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 using the Enterprise Manager, see Chapter 8, "JAAS and Enterprise Manager".
Figure 2-1 shows the two different JAAS Providers supplied with OC4J.
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.
The user manager, employing the user name and password, verifies the user's identity using information in the user repository. The user manager contains your definitions for users, groups, or roles. The default user manager is the JAZNUserManager
.
You can define a user manager for all applications or for specific applications.
UserManager
instance instead of the UserManager
instance specified in the parent application.
The capability model is a method for organizing authorization information. The JAAS Provider is based on the Java 2 Security Model, which uses the capability model to control access to permissions. With the capability model, authorization is associated with the principal (a user named frank
in the following example). Table 2-4 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 2-4 are retrieved from the JAAS Provider (whether the LDAP- based Oracle Internet Directory or XML-based provider) 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. You grant users permissions by making them members of appropriate roles. Support for RBAC is a key JAAS 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 2-2 provides an example of 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.
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()
. 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.
|
Copyright © 1996, 2003 Oracle Corporation. All Rights Reserved. |
|