| Oracle® Containers for J2EE Security Guide 10g (10.1.3.5.0) Part Number E13977-01 |
|
|
View PDF |
| Oracle® Containers for J2EE Security Guide 10g (10.1.3.5.0) Part Number E13977-01 |
|
|
View PDF |
This chapter provides an overview of features and tools for security administration and configuration in OC4J and Oracle Application Server, covering the following topics:
Tools for Oracle Application Server and OracleAS JAAS Provider
Summary of Configuration Repositories and Security Management Tools
OC4J supports the following standards for deploying and managing applications in a J2EE environment:
Java Management Extensions (JMX) 1.2 specification allows standard interfaces to be created for managing resources, such as services and applications, in a J2EE environment. The OC4J implementation of JMX provides a user interface that you can use to completely manage an OC4J server and applications running within it.
Java 2 Platform, Enterprise Edition Management Specification (JSR-77) allows objects known as MBeans (managed beans) to be created for runtime management of applications in a J2EE environment. In OC4J, you can directly access MBeans through the System MBean Browser in Oracle Enterprise Manager 10g, but many of their properties are exposed in a more user-friendly way through other features of Enterprise Manager.
Java 2 Enterprise Edition Deployment API Specification (JSR-88) defines a standard API for configuring and deploying J2EE applications and modules into a J2EE-compatible environment. The OC4J implementation includes the ability to create or edit a deployment plan containing the OC4J-specific configuration data needed to deploy a component into OC4J.
See Also:
Oracle Containers for J2EE Deployment Guide and Oracle Containers for J2EE Configuration and Administration Guide for general information about OC4J deployment, configuration, and administration
Managing security in the J2SE and J2EE environments involves creating and managing realms, users, roles, permissions, and policies. The following Oracle tools are involved in managing security configuration:
Oracle Enterprise Manager 10g Application Server Control is used for overall security administration and configuration during and after deployment, and to manage the file-based provider.
OracleAS JAAS Provider Admintool is used to manage the file-based provider, and also to manage policies and login modules for any security provider.
Oracle Identity Management and Oracle Internet Directory tools: Oracle Delegated Administration Services (DAS) and Oracle Directory Manager (oidadmin) are used to manage users and roles in Oracle Internet Directory for Oracle Identity Management.
These tools will be summarized more thoroughly in the subsections that follow.
Note:
Wherever possible, Oracle Enterprise Manager 10g Application Server Control should be your first-choice tool to administer OC4J, including OC4J security. For features that the Application Server Control does not support, you can, as applicable, use the OracleAS JAAS Provider Admintool. Occasionally, you will have to directly manipulate a configuration file, particularly the instance-level
jazn.xml file (discussed in "The jazn.xml File").Typically, you should use Application Server Control to deploy and administer your applications. The user interface for this is the Application Server Control Console. Application Server Control includes features for the following:
Deploying an application to OC4J. This includes a deployment plan editor. For security, this also includes features to specify the security provider and security role mapping during deployment.
Using the System MBean Browser for MBean configuration and operations (further discussed in "JMX and MBeans Administration"). Also be aware, however, that many parameters corresponding to MBeans properties are exposed through other pages of the Application Server Control Console. Avoid direct manipulation of OC4J MBeans when possible.
Changing to a different security provider after deployment, or updating security provider settings.
Performing OC4J runtime administration and configuration.
OC4J-specific XML configuration files are updated automatically by OC4J when you use the Application Server Control Console.
Notes:
In standalone OC4J you also have the option of using the command-line OC4J admin_client.jar tool, which operates through the OC4J system application, to deploy and bind your J2EE applications. Alternatively, if you use the Oracle JDeveloper tool to develop your application, you can use it to deploy the application and any resource adapters as well.
Whenever a configuration change is made using Application Server Control or the OC4J security provider MBean, the application must be restarted. Until the application is restarted, all other operations of the security provider MBean are invalidated and will return an error message.
See Also:
Oracle Application Server Administrator's Guide for more information about Application Server Control
Oracle Containers for J2EE Configuration and Administration Guide for information about the admin_client.jar utility
The OracleAS JAAS Provider Admintool, for use during development, is a lightweight Java application with the following management features:
For the file-based provider: administration for users, roles, and policies
For Oracle Identity Management: administration for policies, plus read-only access to users and roles
For external LDAP providers: administration for policies and login modules
For custom security providers: administration for policies and login modules
Admintool functions can be called directly from a command line or through an interactive shell. The Admintool is located in ORACLE_HOME/j2ee/home/jazn.jar.
The general command-line syntax is as follows:
% java -jar jazn.jar [-user username -password pwd] [option1 option2 ... ]
When you use the Admintool for the file-based provider, by default it updates the system-jazn-data.xml file in the ORACLE_HOME/j2ee/home/config directory.
Note:
In general, changes made by the Admintool are not effective until you restart OC4J.This section provides an overview of tools to manage Oracle Internet Directory when you use Oracle Identity Management as your security provider.
Delegated administration is an important feature of the Oracle Identity Management infrastructure. It enables you to store all data for users, groups, and services in a central directory, while distributing the administration of that data to various administrators and end users. It does this in a way that respects the various security requirements in your environment.
Suppose, for example, that your enterprise stores all user, group, and services data in a central directory, and requires one administrator for user data, and another for the e-mail service. Delegated administration as provided by the Oracle Identity Management infrastructure enables different administrators with different security requirements to administer centralized data in a way that is both secure and scalable. Privileges can be delegated with Oracle Delegated Administration Services to (among other things) create, edit, and delete users and groups; assign privileges to users and groups; and manage services and accounts.
Oracle Delegated Administration Services (DAS) is a set of pre-defined, Web-based units for performing directory operations on behalf of a user. It frees directory administrators from the more routine directory management tasks by enabling them to delegate specific functions to other administrators and to end users. It provides most of the functionality that directory-enabled applications require, such as creating a user entry, creating a group entry, searching for entries, and changing user passwords.
You can use DAS to develop your own tools for administering application data in the directory. Alternatively, you can use the Oracle Internet Directory Self-Service Console, a tool based on DAS. This tool comes ready to use with Oracle Internet Directory.
See Also:
Oracle Identity Management Guide to Delegated Administration
Oracle Directory Manager is an administration tool with a Java-based graphical user interface that you can use to administer Oracle Internet Directory. The executable file is located in the ORACLE_HOME/bin directory, and you can run it from the command line as follows:
% oidadmin
In general, any directory-specific configuration or maintenance task not available through Application Server Control can be accomplished through Oracle Directory Manager (as well as various command-line interfaces supplied with Oracle Internet Directory).
You can use Oracle Directory Manager for tasks such as the following:
Configuring realms
Specifying password policies
Configuring the Oracle Directory Synchronization Service and Oracle Internet Directory connectors and agents
You can also manage features such as attribute uniqueness, plug-ins, garbage collection, change logs, replication, query optimization, debug logging, and access control lists.
See Also:
Oracle Internet Directory Administrator's Guide for general information about Oracle Directory Manager
OC4J support for the JMX specification allows standard interfaces to be created for managing resources dynamically in a J2EE environment. The OC4J implementation of JMX provides a JMX client, the System MBean Browser, that you can use to manage an OC4J instance through MBeans that are provided with OC4J.
An MBean is a Java object that represents a JMX manageable resource. Each manageable resource within OC4J is managed through an instance of the appropriate MBean. Each MBean provided with OC4J exposes a management interface that is accessible through the System MBean Browser in the Application Server Control Console. You can set MBean attributes, execute operations to call methods on an MBean, subscribe to notifications of errors or specific events, and display execution statistics.
To access the browser from the OC4J Home page, select the Administration tab and then, under the list of tasks, go to the JMX task "System MBean Browser". From the browser, you can do the following:
Select the MBean of interest in the left-hand frame.
Use the Attributes tab in the right-hand frame to view or change attributes. A settable attribute has a field where you can type in a new value. Then apply the change.
Use the Operations tab in the right-hand frame to invoke methods on the MBean. Select the operation of interest. In the Operation window, you can invoke it with specified parameter settings.
Use the Notifications tab (where applicable) in the right-hand frame to subscribe to notifications. You can select each item for which you want notification, and then apply the changes.
Use the Statistics tab (where applicable) in the right-hand frame to display execution statistics.
Be aware that MBeans and their attributes vary regarding when changes take effect. In the runtime model, changes take effect immediately. In the configuration model, some changes take effect when the resource is restarted, others when the application is restarted, and still others when OC4J is restarted. There is also variation in whether changes are persisted.
This section provides an overview of the following key XML files and elements for security configuration:
Note:
In general, you should use the Application Server Control Console or OracleAS JAAS Provider Admintool (both discussed earlier in this chapter) for configuration and administration, instead of manipulating configuration files directly. Using these tools results in the appropriate entries automatically being made in the configuration files.See Also:
"Summary of Configuration Repositories and Security Management Tools"
Reference appendix in the Oracle Containers for J2EE Developer's Guide for information about elements of the orion-application.xml (and system-application.xml) file
The OC4J orion-application.xml file is for general (not just security-related) application-level configuration. Settings in this file apply across a single J2EE application (EAR file).
For security settings in orion-application.xml, there is the <jazn> element. In particular, this element can specify the security provider, the user and role repository location, and the default realm for the application, as in the following example to use the file-based provider:
<jazn provider="XML" location="./system-jazn-data.xml" default-realm="jazn.com" > ... </jazn>
(The system-jazn-data.xml file, discussed in "The system-jazn-data.xml File", would actually be the repository by default, but is specified here for illustrative purposes.)
A subelement of <jazn> in orion-application.xml is the <jazn-web-app> element, which is where you specify OC4J-specific authentication methods (using the auth-method attribute) for Web applications.
Notes:
In order to take effect, changes to orion-application.xml require an application restart (if the changes were made through Application Server Control or security provider MBean) or an OC4J restart (if the changes were made manually).
If there is no <jazn> element in orion-application.xml, the security provider settings defer to those of the instance-level jazn.xml file (where the system-jazn-data.xml repository and jazn.com default realm are the default settings).
This OC4J configuration file is associated with the OC4J system application, which is described in "OC4J System Application". For the system application, system-application.xml is equivalent to the orion-application.xml file for a deployed application.
The system-application.xml file, through its <jazn> element, specifies the file-based security provider for OC4J instance-level user and role settings (including some used for special OC4J functionality). The system-application.xml file points to the system-jazn-data.xml file (described in the next section), which is also instance-level, as the repository for these settings, which are located under the <jazn-realm> element.
By default, OC4J expects the system-application.xml to be in the ORACLE_HOME/j2ee/instance_name/config directory.
The system-jazn-data.xml file is a new file in OC4J 10.1.3.x implementations. This file (as well as system-application.xml) is associated with the OC4J system application, which is described in "OC4J System Application".
The system-application.xml file points to the system-jazn-data.xml file as the repository for OC4J instance-level user and role settings (located under the <jazn-realm> element) for the file-based provider, which uses system-jazn-data.xml for authentication and authorization. (Note that the file-based provider is the default security provider.)
If you use the file-based provider for an application, you can optionally use system-jazn-data.xml as your user repository, or you can use an application-specific jazn-data.xml file that you package with your application, as described in the next section, "Application-Specific jazn-data.xml File (Optional)".
The system-jazn-data.xml file also stores JAAS login module configuration (under the <jazn-loginconfig> element) and JAAS policy configuration (under the <jazn-policy> element).
By default, OC4J expects the system-jazn-data.xml file to be in the ORACLE_HOME/j2ee/instance_name/config directory.
There is a persistence mode that governs how often changes are written to the system-jazn-data.xml file and, if applicable (for the file-based provider), to an application-level jazn-data.xml file. There are three possible values for persistence, according to the <jazn> element persistence attribute in either the instance-level jazn.xml file or application-level orion-application.xml file:
"NONE": Do not write changes.
"ALL": Write changes after every modification.
"VM_EXIT" (default): Write changes when the Java Virtual Machine exits.
Here is an example:
<jazn provider="XML" persistence="ALL" ... >
...
</jazn>
See Also:
Appendix D, "OracleAS JAAS Provider Configuration Files" for details about the hierarchy, elements, and attributes of this file
Notes:
If changes to system-jazn-data.xml are made through Application Server Control or the security provider MBean, then an OC4J restart is not required for the changes to take effect. A restart is required, though, if changes are made manually (which is not generally recommended).
In previous releases, system-jazn-data.xml was named jazn-data.xml. For the file-based provider, you can still use a file named jazn-data.xml to store user and role information, but this file would be application-specific. See the next section, "Application-Specific jazn-data.xml File (Optional)".
Settings in the system-jazn-data.xml file can be manipulated using Application Server Control or the OracleAS JAAS Provider Admintool.
Changes made to the system-jazn-data.xml file are visible to all applications that use it.
The system-jazn-data.xml file contains accounts for predefined OC4J users and roles. See "Predefined OC4J Accounts in system-jazn-data.xml".
White space in element settings is significant, such as the differences between the following:
<name>scott</name> <name>scott </name> <name> scott</name> <name> scott </name>
When you use the file-based provider, you can optionally use a jazn-data.xml file as the user and role repository. In OC4J 10.1.3.x implementations, this file is application-specific. You can specify its location in the <jazn> element of the orion-application.xml file, according to where you deploy it:
<jazn provider="XML" location="path/jazn-data.xml">
...
</jazn>
See Also:
Appendix D, "OracleAS JAAS Provider Configuration Files" for details about the hierarchy, elements, and attributes of this file
Note that if orion-application.xml is configured exactly as follows, but a jazn-data.xml file is not packaged with the application, then one will be created during deployment:
<jazn provider="XML" location="./jazn-data.xml" />
Persistence mode for changes to the repository, described in the preceding section for system-jazn-data.xml, also affects jazn-data.xml.
Notes:
Think of the application-specific jazn-data.xml file as a repository, not as a configuration file.
White space in element settings is significant, such as the differences between the following:
<name>scott</name> <name>scott </name> <name> scott</name> <name> scott </name>
The jazn.xml file, located in the ORACLE_HOME/j2ee/instance_name/config directory, is an OC4J instance-level configuration file for the OracleAS JAAS Provider. It specifies the instance-level security provider and repository for policy and permission settings. The main element of the jazn.xml file is the <jazn> element, with largely the same functionality as discussed earlier for the orion-application.xml file for application-level settings.
By default, jazn.xml specifies the file-based provider, with system-jazn-data.xml as the repository and jazn.com as the default realm:
<jazn provider="XML" location="./system-jazn-data.xml" default-realm="jazn.com"> ... </jazn>
The jazn.xml file for the OC4J home instance, referred to as the bootstrap jazn.xml file, is typically located in the ORACLE_HOME/j2ee/home/config directory. It is read at OC4J startup and used by the OracleAS JAAS Provider runtime. Without a valid jazn.xml file, the OracleAS JAAS Provider cannot begin running.
If you use Application Server Control to associate OC4J with an Oracle Internet Directory instance in order to use the Oracle Identity Management security provider, then the <jazn> element of the bootstrap jazn.xml file is updated appropriately for the Oracle Internet Directory instance. For example:
<jazn provider="LDAP" location="ldap://myoid.oracle.com:389" default-realm="us" > ... </jazn>
Note:
Changes tojazn.xml require an OC4J restart in order to take effect.See Also:
Appendix D, "OracleAS JAAS Provider Configuration Files" for details about the hierarchy, elements, and attributes of this file
You can optionally use a system property to specify an alternative location for the bootstrap jazn.xml file. When the OracleAS JAAS Provider starts, it searches for jazn.xml in the following order, stopping the search as soon as it finds one:
Location specified by the system property oracle.security.jazn.config
Location specified by the system property java.security.auth.policy
J2EE_HOME/config, where J2EE_HOME is specified by the system property oracle.j2ee.home
ORACLE_HOME/j2ee/home/config, where ORACLE_HOME is specified by the system property oracle.home (this is generally the same location as J2EE_HOME/config)
./config
Here are sample jazn.xml files, first with the default configuration for the file-based provider:
<?xml version="1.0" encoding="UTF-8" standalone='yes'?>
<jazn xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation=
"http://xmlns.oracle.com/oracleas/schema/jazn-10_0.xsd"
schema-major-version="10"
schema-minor-version="0"
provider="XML"
location="./system-jazn-data.xml"
default-realm="jazn.com"
/>
And for the LDAP-based provider:
<?xml version="1.0" encoding="UTF-8" standalone='yes'?>
<jazn xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation=
"http://xmlns.oracle.com/oracleas/schema/jazn-10_0.xsd"
schema-major-version="10"
schema-minor-version="0"
provider="LDAP"
location="ldap://myoid.us.oracle.com:389"
/>
The OC4J system application is an internal component defined in OC4J 10.1.3.x implementations. It is auto-deployed to the OC4J instance the first time OC4J is started. This application was added primarily to address issues related to deploying or redeploying applications to OC4J.
The system application is at the root of the application hierarchy, and provides classes and configuration required at OC4J startup, including shared libraries imported by default by all other deployed applications. It is an OC4J internal component only. Applications cannot be deployed to it, nor can it be declared the parent of another application. (The OC4J default application continues to serve as the default parent of all deployed applications, as in previous OC4J implementations.)
By default, the system application is configured to use the file-based provider for user and role settings, using system-jazn-data.xml for the repository. (Note this means that authorization of all system resources, such as MBeans and admin_client.jar, is based on entries in system-jazn-data.xml.) It is not advisable to alter this configuration.
The OC4J-specific application descriptor for the system application is system-application.xml, with the same functionality as orion-application.xml for a deployed application. (For the default application, the OC4J-specific application descriptor is application.xml, not to be confused with the J2EE standard application.xml file for deployed applications, and by default this configures the default application to also use the system-jazn-data.xml repository.) These files are located in the ORACLE_HOME/j2ee/instance_name/config directory.
See Also:
Oracle Containers for J2EE Configuration and Administration Guide for information about the OC4J application hierarchy and the system and default applications
This section provides a summary of key OC4J accounts, covering the following topics:
OC4J 10.1.3.x implementations include predefined "bootstrap" users and roles for Oracle Internet Directory (when you use Oracle Identity Management) or the file-based provider.
For the file-based provider, the accounts are predefined in the system-jazn-data.xml file. For Oracle Internet Directory (OID), they are created automatically as default accounts as part of the OC4J-OID association process.
The following predefined accounts are common to both providers:
oc4jadmin user (formerly admin)
This is the default administrator account. During the Oracle Application Server or OC4J installation process, you must specify a password for this account. You can then use this account to log in to the Application Server Control Console. This account is also used by Application Server Control when it performs administrative functions (through the OC4J system application).
In a cluster environment, the oc4jadmin name and password serve as administrative credentials for the cluster. Because there is only one set of administrative credentials for a cluster, by default each OC4J instance must have an oc4jadmin account with the same password. For this reason, use caution when changing the password for this account.
As a good practice, you may consider creating additional administrative accounts rather than using oc4jadmin for day-to-day administrative activities.
oc4j-administrators role (formerly administrators), with member oc4jadmin, RMI permission "login" granted, and administration permission "administration" granted (com.evermind.server.rmi.RMIPermission and oracle.security.jazn.policy.AdminPermission, respectively)
oc4j-app-administrators role (formerly jmx-users), with RMI permission "login" granted, to allow access to JMX application-level connectors
ascontrol_admin (administrative role for all SOA controls, including Application Server Control), with member oc4jadmin
ascontrol_appadmin (Application Server Control required role)
ascontrol_monitor (Application Server Control required role)
Important:
When you use an external LDAP security provider, you must take manual steps (through whatever provisioning tool is appropriate for the provider) to create the preceding user and role accounts and grant theoc4j-administrators and ascontrol_admin roles to oc4jadmin. Also use the OracleAS JAAS Provider Admintool to grant the noted permissions.The following additional accounts are predefined for the file-based provider only:
anonymous user, initially deactivated
Activate anonymous directly in the system-jazn-data.xml file, by changing the deactivated attribute of the <user> element from "true" to "false". Unlike for oc4jadmin, there is no support in the OracleAS JAAS Provider Admintool for activating anonymous.
users role, for EJB/RMI access
jtaadmin user, to allow transaction propagation over ORMI
Do not remove any of the accounts described in this section, or the administrative functions of the OracleAS JAAS Provider will not work.
See Also:
The next section, "Activation of the oc4jadmin Account (Standalone OC4J)"
Application Server Control online help topics: "About the oc4jadmin User", "About Administrative Users and Roles" (for additional information about the Application Server Control roles), and "Best Practices When Defining Administration Users and Roles".
The oc4jadmin account (formerly the admin account) is activated during Oracle Application Server installation, but is initially deactivated for the file-based provider in standalone OC4J. It is activated under the following circumstances:
When standalone OC4J is first started (and you are prompted for a password)
When you run the OracleAS JAAS Provider Admintool with the -activateadmin option
You also specify the password as part of this command:
% java -jar jazn.jar -activateadmin password
By default, as noted previously, oc4jadmin is the administrator account for OC4J. This section discusses how to use an alternative administrator account, such as to access SOA components (including the Application Server Control Console and Oracle Web Services Manager, for example) and for internal use by the OC4J system application. The system application is used by Application Server Control for various administrative functions (such as deploying and undeploying applications).
You may choose to create and use a new administrator account, rather than oc4jadmin. This could be to access SOA components such as the Application Server Control Console, for example (typically through Java SSO), which is the scenario we consider here.
The steps to take depend on whether the security provider for SOA components is the file-based provider or Oracle Identity Management, both of which have key administrator roles defined by default with necessary RMI permissions, or some other security provider such as an external LDAP provider, where you must configure these roles and permissions manually.
Notes:
The following additional points are applicable to Application Server Control:For Application Server Control to work properly in a clustered environment, you must create the new user across the cluster.
If you remove the oc4jadmin account, you will see the Application Server Control "post login" page. This is expected, because Application Server Control would no longer be able to make a connection with the previously cached oc4jadmin user. Once you enter the new user name and password, you will not see this page again.
If you use the file-based provider or Oracle Identity Management as the security provider for SOA components, the following steps are required to use a custom administrator account:
Create the new administrative user account.
Grant the new administrative user account the roles oc4j-administrators and ascontrol_admin.
Optionally set the admin.user property to allow the OC4J system application to use the new account, as discussed in "Configuring a New Administrator Account for the System Application". If you are not using system-jazn-data.xml as your repository, then this step requires you to also create your new administrator account in system-jazn-data.xml, for use by the system application, and grant it the necessary administrator roles.
No further steps are required. By default, the oc4j-administrators and ascontrol_admin roles exist in the file-based provider and Oracle Internet Directory, and have RMI permission "login" granted.
Notes:
For the file-based provider, use the Application Server Control Console for user and role management, as detailed in "Configuring the File-Based Provider in Application Server Control".
For Oracle Internet Directory, use the Oracle Delegated Administration Services (DAS) for user and role management, as detailed in the Oracle Identity Management Guide to Delegated Administration.
If you use anything other than the file-based provider or Oracle Identity Management as the security provider for SOA components, the following steps are required to use a custom administrator account:
Create the new administrative user account, using the appropriate tool for the security provider.
Create the administrator roles oc4j-administrators and ascontrol_admin, using the appropriate tool, if you have not already created them. For an external LDAP provider, these roles must be under the group search base configured for the LDAP provider. (See Table 10-4, "Application Server Control External LDAP Role and Member Options" and Table 10-7, "External LDAP Role and Member Options" for information about the group search base.)
Grant the new administrative user account the roles oc4j-administrators and ascontrol_admin, using the appropriate tool, if you have not already done so.
Create the additional administrator roles oc4j-app-administrators, ascontrol_appadmin, and ascontrol_monitor. (These do not have to be granted to the administrative user.)
If the administrator must access EJBs, grant the roles oc4j-administrators and ascontrol_admin RMI permission "login", if you have not already done so. You can use the OracleAS JAAS Provider Admintool for this, as in the following example:
% java -jar jazn.jar -grantperm myrealm -role oc4j-administrators \
com.evermind.server.rmi.RMIPermission login
Be aware that although the roles are defined in the external LDAP provider, these permission grants are stored in the system-jazn-data.xml file.
Optionally set the admin.user property to allow the OC4J system application to use the new account, as discussed in the next section, "Configuring a New Administrator Account for the System Application". This step requires you to also create your new administrator account in system-jazn-data.xml, for use by the system application, and grant it the necessary administrator roles.
You can specify a different administrator account for use by the OC4J system application as follows:
Create the desired account in the system-jazn-data.xml file, if it does not already exist there, and grant it the roles oc4j-administrators and ascontrol_admin. Use the Application Server Control Console for user and role management, as detailed in "Configuring the File-Based Provider in Application Server Control".
Set the admin.user property in the instance-level jazn.xml file, as follows:
<jazn ... >
...
<property name="admin.user" value="desired_admin_user_name" />
...
</jazn>
(These steps assume the OC4J system application is configured to use the file-based security provider, as should always be the case.)
The specified account will then be used for a variety of administrative functions, including, for example, being used by Application Server Control to deploy and undeploy applications.
When using either the file-based provider or Oracle Identity Management, you can map an anonymous user to an existing user by setting the anonymous.user property in the instance-level jazn.xml file. For example, assuming there is a user PUBLIC in Oracle Internet Directory:
<jazn ... > ... <property name="anonymous.user" value="PUBLIC" /> ... </jazn>
Management tools and configuration repositories have been discussed previously, but Table 4-1 summarizes the configuration repositories and the preferred management tools to use for the various types of configuration for each security provider.
Where applicable, Application Server Control is the preferred tool.
Table 4-1 Configuration Repositories and Preferred Management Tools
| Security Provider | Repository and Management Tool for Realms, Users, Roles | Repository and Management Tool for Policies | Repository and Management Tool for JAAS Login Modules |
|---|---|---|---|
|
File-based |
system-jazn-data.xml (or application-specific jazn-data.xml) Use Application Server Control Console (preferred) or OracleAS JAAS Provider Admintool. |
system-jazn-data.xml Use OracleAS JAAS Provider Admintool. |
n/a |
|
Oracle Identity Management |
Oracle Internet Directory Use DAS (or OracleAS JAAS Provider Admintool for read-only). |
Oracle Internet Directory Use OracleAS JAAS Provider Admintool. |
n/a |
|
External LDAP |
External (third-party) LDAP server Use tool supplied by provider. |
system-jazn-data.xml Use OracleAS JAAS Provider Admintool. |
system-jazn-data.xml Use Application Server Control Console (preferred) or OracleAS JAAS Provider Admintool. |
|
Custom security provider |
Custom security repository Use tool supplied by provider. |
system-jazn-data.xml Use OracleAS JAAS Provider Admintool. |
system-jazn-data.xml Use Application Server Control Console (preferred) or OracleAS JAAS Provider Admintool. |
|
Oracle Access Manager |
Oracle Access Manager Use the Policy Manager tool. |
system-jazn-data.xml Use OracleAS JAAS Provider Admintool. |
system-jazn-data.xml Use Application Server Control Console (preferred) or OracleAS JAAS Provider Admintool. |
Note:
"Policies" in this table refers to subject-based policies. Code-based policies are stored in a standard Java 2 policy file (such asjava2.policy or java.policy). OC4J currently offers no management tool to update or maintain Java 2 policy files.
|
 Copyright © 2003, 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|