| Oracle® Fusion Middleware Application Security Guide 11g Release 1 (11.1.1) Part Number E10043-12 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware Application Security Guide 11g Release 1 (11.1.1) Part Number E10043-12 |
|
|
PDF · Mobi · ePub |
This chapter describes the manual configuration and packaging recommended for Java EE applications that use OPSS but do not use Oracle ADF security. Note that, nevertheless, some topics apply also to Oracle ADF applications.
The information is directed to developers that want to configure and package a Java EE application outside Oracle JDeveloper environment.
This chapter is divided into the following sections:
The files relevant to application management during development, deployment, runtime, and post-deployment are the following:
OPSS provides a servlet filter, the JpsFilter, and an EJB interceptor, the JpsInterceptor. The first one is configured in the file web.xml packed in a WAR file; the second one in the file ejb-jar.xml packed in a JAR file. OPSS also provides a way to configure in the file web.xml the stripe that application Mbeans should access; for details, see Configuring the Application Stripe for Application MBeans.
All of them are available on WebLogic and WebSphere. The configuration available differs slightly according to the server platform as follows:
On WebLogic, the JpsFilter is out-of-the-box automatically set with default parameter values and need not be explicitly configured in the deployment descriptor; it needs to be configured manually only if a value different from the default value is required. The JpsInterceptor must be manually configured.
On WebSphere, both the JpsFilter and the JpsInterceptor must be manually configured.
Note:
Oracle JDeveloper automatically inserts the required servlet filter (JpsFilter) and EJB interceptor (JpsInterceptor) configurations for Oracle ADF applications.
The manual configurations explained in this section are required only if you are packaging or configuring a Java EE application using the OPSS features detailed next outside the Oracle JDeveloper environment.
OPSS allows the specification of the application stripe used by MBeans; for details, see Configuring the Application Stripe for Application MBeans.
The servlet filter and the EJB interceptor can be configured using the same set of parameters to customize the following features of a servlet or of an Enterprise Java Bean (EJB):
The application name, better referred to as the application stripe and optionally specified in the application web.xml file, is used at runtime to determine which set of policies are applicable. If the application stripe is not specified, it defaults to the application id (which includes the application name).
An application stripe defines a subset of policies in the policy store. An application wanting to use that subset of policies would define its application stripe with a string identical to that application name. In this way, different applications can use the same subset of policies in the policy store.
The function of the anonymous and authenticated roles is explained in sections The Anonymous User and Role and The Authenticated Role.
A servlet specifies the use a filter with the element <filter-mapping>. There must be one such element per filter per servlet.
An EJB specifies the use of an interceptor with the element <interceptor-binding>. There must be one such element per interceptor per EJB. For more details, see Interceptor Configuration Syntax.
For a summary of the available parameters, see Summary of Filter and Interceptor Parameters.
This value is controlled by the following parameter:
application.name
The specification of this parameter is optional and case sensitive; if unspecified, it defaults to the name of the deployed application. Its value defines the subset of policies in the policy store that the application intents to use.
One way of specifying the application stripe is withing the filter element, as illustrated in the following sample:
<filter> <filter-name>JpsFilter</filter-name> <filter-class>oracle.security.jps.ee.http.JpsFilter</filter-class> <init-param> <param-name>application.name</param-name> <param-value>stripeid</param-value> </init-param> </filter>
Another way to specify it, is to specify it is within the context-param element as illustrated in the following sample:
<context-param> <description>JPS custom stripe id</description> <param-name>application.name</param-name> <param-value>stripeid</param-value> </context-param>
This last configuration is required if the application contains MBeans accesssing the application policy store and the application name is different from the application stripe name. For details, see Configuring the Application Stripe for Application MBeans.
Configuration Examples
The following two samples illustrate the configuration of this parameter for a servlet and for an EJB.
The following fragment of a web.xml file shows how to configure two different servlets, MyServlet1 and MyServlet2, to be enabled with the filter so that subsequent authorization checks evaluate correctly. Note that servlets in the same WAR file always use the same policy stripe.
<filter>
<filter-name>JpsFilter</filter-name>
<filter-class>oracle.security.jps.ee.http.JpsFilter</filter-class>
<init-param>
<param-name>application.name</param-name>
<param-value>MyAppName</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>JpsFilter</filter-name>
<servlet-name>MyServlet1</servlet-name>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
<filter-mapping>
<filter-name>JpsFilter</filter-name>
<servlet-name>MyServlet2</servlet-name>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
The following fragment of an ejb-jar.xml file illustrates the setting of the application stripe of an interceptor to MyAppName and the use of that interceptor by the EJB MyEjb:
<interceptor>
<interceptor-class>oracle.security.jps.ee.ejb.JpsInterceptor</interceptor-class>
<env-entry>
<env-entry-name>application.name</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>MyAppName</env-entry-value>
<injection-target>
<injection-target-class>
oracle.security.jps.ee.ejb.JpsInterceptor</injection-target-class>
<injection-target-name>application_name</injection-target-name>
</injection-target>
</env-entry>
</interceptor>
...
<interceptor-binding>
<ejb-name>MyEjb</ejb-name>
<interceptor-class>
oracle.security.jps.ee.ejb.JpsInterceptor</interceptor-class>
</interceptor-binding>
Note how the preceding example satisfies the interceptor configuration syntax requirements.
The addition of application roles to a subject is controlled by the following parameter, which can be set to true or false:
add.application.roles
To add application roles to a subject, set the property to true; otherwise, set it to false. The default value is true.
The principal class for the application role is:
oracle.security.jps.service.policystore.ApplicationRole
Anonymous User and Anonymous Role Support
The use of anonymous for a servlet is controlled by the following parameters, which can be set to true or false:
enable.anonymous remove.anonymous.role
For an EJB, only the second parameter above is available, since the use of the anonymous user and role is always enabled for EJBs.
To enable the use of the anonymous user for a servlet, set the first property to true; to disable it, set it to false. The default value is true.
To remove the anonymous role from a subject, set the second property to true; to retain it, set it to false. The default value is false. Typically, one would want to remove the anonymous user and role after authentication, and only in special circumstances would want to retain them after authentication.
The default name and the principal class for the anonymous user are:
anonymous oracle.security.jps.internal.core.principals.JpsAnonymousUserImpl
The default name and the principal class for the anonymous role are:
anonymous-role oracle.security.jps.internal.core.principals.JpsAnonymousRoleImpl
The following fragment of a web.xml file illustrates a setting of these parameters and the use of the filter JpsFilter by the servlet MyServlet:
<filter>
<filter-name>JpsFilter</filter-name>
<filter-class>oracle.security.jps.ee.http.JpsFilter</filter-class>
<init-param>
<param-name>enable.anonymous</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>remove.anonymous.role</param-name>
<param-value>false</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>JpsFilter</filter-name>
<servlet-name>MyServlet</servlet-name>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
The following fragment of an ejb-jar.xml file illustrates the setting of the second parameter to false and the use of the interceptor by the Enterprise Java Bean MyEjb:
<interceptor>
<interceptor-class>oracle.security.jps.ee.ejb.JpsInterceptor</interceptor-class>
<env-entry>
<env-entry-name>remove.anonymous.role</env-entry-name>
<env-entry-type>java.lang.Boolean</env-entry-type>
<env-entry-value>false</env-entry-value>
<injection-target>
<injection-target-class>
oracle.security.jps.ee.ejb.JpsInterceptor</injection-target-class>
<injection-target-name>remove_anonymous_role/injection-target-name>
</injection-target>
</env-entry>
</interceptor>
...
<interceptor-binding>
<ejb-name>MyEjb</ejb-name>
<interceptor-class>
oracle.security.jps.ee.ejb.JpsInterceptor</interceptor-class>
</interceptor-binding>
The following fragments illustrate how to access programmatically the anonymous subject, and the anonymous role and anonymous user from a subject:
import oracle.security.jps.util.SubjectUtil; // The next call returns the anonymous subject javax.security.auth.Subject subj = SubjectUtil.getAnonymousSubject(); // The next call extracts the anonymous role from the subject java.security.Principal p = SubjectUtil.getAnonymousRole(javax.security.auth.Subject subj) // Remove or retain anonymous role ... // The next call extracts the anonymous user from the subject java.security.Principal p = SubjectUtil.getAnonymousUser(javax.security.auth.Subject subj) // Remove or retain anonymous user ...
The use of the authenticated role is controlled by the following parameter, which can be set to true or false:
add.authenticated.role
To add the authenticated role to a subject, set the parameter to true; otherwise it, set it to false. The default value is true.
The default name and the principal class for the authenticated role are:
authenticated-role oracle.security.jps.internal.core.principals.JpsAuthenticatedRoleImpl
The following fragment of a web.xml file illustrates a setting of this parameter and the use of the filter JpsFilter by the servlet MyServlet:
<filter>
<filter-name>JpsFilter</filter-name>
<filter-class>oracle.security.jps.ee.http.JpsFilter</filter-class>
<init-param>
<param-name>add.authenticated.role</param-name>
<param-value>false</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>JpsFilter</filter-name>
<servlet-name>MyServlet</servlet-name>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
The use of JAAS mode is controlled by the following parameter:
oracle.security.jps.jaas.mode
This parameter can be set to:
doAs doAsPrivileged off undefined subjectOnly
The default value is doAsPrivileged. For details on how these values control the behavior of the method checkPermission, see Section 20.3.3.1, "Using the Method checkPermission."
The following two samples illustrate configurations of a servlet and an EJB that use this parameter.
The following fragment of a web.xml file illustrates a setting of this parameter and the use of the filter JpsFilter by the servlet MyServlet:
<filter>
<filter-name>JpsFilter</filter-name>
<filter-class>oracle.security.jps.ee.http.JpsFilter</filter-class>
<init-param>
<param-name>oracle.security.jps.jaas.mode</param-name>
<param-value>doAs</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>JpsFilter</filter-name>
<servlet-name>MyServlet</servlet-name>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
The following fragment of an ejb-jar.xml file illustrates a setting of this parameter to doAs and the use of the interceptor JpsInterceptor by the Enterprise Java Bean MyEjb:
<interceptor>
<interceptor-class>oracle.security.jps.ee.ejb.JpsInterceptor</interceptor-class>
<env-entry>
<env-entry-name>oracle.security.jps.jaas.mode</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>doAs</env-entry-value>
<injection-target>
<injection-target-class>
oracle.security.jps.ee.ejb.JpsInterceptor</injection-target-class>
<injection-target-name>oracle_security_jps_jaas_mode
</injection-target-name>
</injection-target>
</env-entry>
</interceptor>
...
<interceptor-binding>
<ejb-name>MyEjb</ejb-name>
<interceptor-class>
oracle.security.jps.ee.ejb.JpsInterceptor</interceptor-class>
</interceptor-binding>
The following requirements and characteristics of the specifications apply to all parameters configured for the JpsInterceptor:
The setting of a parameter requires specifying its type (in the element <env-entry-type>).
The setting of a parameter requires the element <injection-target>, which specifies the same class as that of the interceptor (in the element <injection-target-class>), and the parameter name rewritten as a string where the dots are replaced by underscores (in the element <injection-target-name>).
The binding of an interceptor to an EJB is specified by the EJB name and the interceptor's class, that is, the interceptor is referred to by its class, not by name.
The following table summarizes the description of the parameters used by the JpsFilter and the JpsInterceptor:
Table 21-1 Summary of JpsFilter and JpsInterceptor Parameters
| Parameter Name | Values | Default | Function | Notes |
|---|---|---|---|---|
|
application.name |
Any valid string. The value is case sensitive. |
The name of the deployed application. |
To specify the subset of policies that the servlet or EJB is to use. |
It should be specified if several servlets or EJBs are to share the same subset of policies in the policy store. |
|
add.application.roles |
TRUE or FALSE |
TRUE |
To add application roles to a Subject. |
Since it defaults to TRUE, it must be set (to FALSE) only if the application is not to add application roles to a Subject. |
|
enable.anonymous |
TRUE or FALSE |
TRUE |
To enable or disable the anonymous user in a Subject. |
If set to TRUE, it creates a Subject with the anonymous user and the anonymous role. |
|
remove.anonymous.role |
TRUE or FALSE |
FALSE |
To keep or remove the anonymous role from a Subject after authentication. |
Available for servlets only. For EJBs, the anonymous role is always removed from a Subject. If set to FALSE, the Subject retains the anonymous role after authentication; if set to TRUE, it is removed after authentication. |
|
add.authenticated.role |
TRUE or FALSE |
TRUE |
To allow addition of the authenticated role in a Subject. |
Since it defaults to TRUE, it needs be set (to FALSE) only if the authenticated role is not be included in a Subject. |
|
oracle.security.jps.jaas.mode |
doAsPrivileged doAs off undefined subjectOnly |
doAsPrivileged |
To set the JAAS mode. |
If your application satisfies the following conditions:
It contains MBeans that access the policy store and perform authorization checks.
The application stripe name is not equal to the application name.
then, for the MBean to access the application stripe in the domain security store, the stripe name must be specified by the global parameter (or context parameter) application.name in the file web.xml, as illustrated in the following sample:
<context-param> <description>JPS custom stripe id</description> <param-name>application.name</param-name> <param-value>stripeid</param-value> </context-param>
Note:
If you are using Oracle JDeveloper, the tool chooses the appropriate classes. Therefore, the configuration explained next is only necessary if policies are entered outside the Oracle JDeveloper environment.
The classes specified in members of an application role must be either other application role class or one of the following:
weblogic.security.principal.WLSUserImpl weblogic.security.principal.WLSGroupImpl
The following fragment illustrates the use of these classes in the specification of enterprise groups (in bold face).
Important:
Application role names are case insensitive; for example, app_operator in the following sample.
Enterprise user and group names are case sensitive; for example, Developers in the following sample.
For related information about case, see Section L.4, "Failure to Grant or Revoke Permissions - Case Mismatch."
<app-role>
<name>app_monitor</name>
<display-name>application role monitor</display-name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<members>
<member>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<name>app_operator</name>
</member>
<member>
<class>weblogic.security.principal.WLSGroupImpl</class>
<name>Developers</name>
</member>
</members>
</app-role>
This section explains the packaging requirements for a servlet or an EJB (using custom policies and credentials) that is to be deployed on WebLogic Application Server or WebSphere Application Server.
Application policies are defined in the file jazn-data.xml. The only supported way to include this file with an application is to package it in the directory META-INF of an EAR file.
Servlets are packaged in a WAR file that contains the configuration file web.xml; EJBs are packaged in a WAR file that contains the configuration file ejb-jar.xml. The WAR file must include the configuration of the filter JpsFilter (for servlets) or of the interceptor JpsInterceptor (for EJBs) in the corresponding configuration file.
The description that follows considers the packaging of a servlet and the configuration of the JpsFilter in the file web.xml, but it applies equally to the packaging of an EJB and the configuration of the JpsInterceptor in the file ejb-jar.xml.
Important:
Currently all JpsFilter configurations in all web.xml files in an EAR file must have the same configuration. Same constrains apply to the JpsInterceptor.
For details about the JpsFilter and the JpsInterceptor, see Configuring the Servlet Filter and the EJB Interceptor.
The packaging requirements and assumptions for a Java EE application that wants to use custom policies and credentials are the following:
The application to be deployed must be packaged in a single EAR file.
The EAR file must contain exactly one file META-INF/jazn-data.xml, where application policies and roles are specified; these apply equally to all components in the EAR file.
The EAR file may contain one or more WAR files.
Each WAR or JAR file in the EAR file must contain exactly one web.xml (or ejb-jar.xml) where the JpsFilter (or JpsInterceptor) is configured, and such configurations in all EAR files must be identical.
Component credentials in cwallet.sso files can be packaged in the EAR file. These credentials can be migrated to the credential store when the application is deployed with Oracle Enterprise Manager Fusion Middleware Control.
Note:
If a component should require a filter configuration different from that of other components, then it must be packaged in a separate EAR file and deployed separately.
Application policies are defined in the file jazn-data.xml. The only supported way to include this file with an application is to package it in the directory META-INF of an EAR file. The EAR file may contain zero or more WAR files, but the policies can be specified only in that XML file located in that EAR directory. To specify particular policies for a component in a WAR file, that component must be packaged in a separate EAR file with its own jazn-data.xml file as specified above. No other policy package combination is supported in this release, and policy files other than the top jazn-data.xml are disregarded.
Application credentials are defined in a file that must be named cwallet.sso. The only supported way to include this file with an application is to package it in the directory META-INF of an EAR file. The EAR file may contain zero or more WAR files, but credentials can be specified only in that cwallet.sso file located in that EAR directory. To specify particular credentials for a component in a WAR file, that component must be packaged in a separate EAR file with its own cwallet.sso file as specified above. No other credential package combination is supported in this release, and credential files other than the top cwallet.sso are disregarded.
This section describes several configurations that a developer would perform manually for a Java EE application developed outside the Oracle JDeveloper environment, in the following sections:
Note:
Use the system property jps.deployment.handler.disabled to disable the migration of application policies and credentials for applications deployed in a WebLogic Server.
When this system property is set to TRUE, the migration of policies and credentials at deployment is disabled for all applications regardless of the particular application settings in the application file weblogic-application.xml.
The migration of application policies at deployment is controlled by several parameters configured in the file META-INF/weblogic-application.xml.
For details about the specification of parameters on WebSphere, see Oracle Fusion Middleware Third-Party Application Server Guide.
The parameters that control migration of policies during application deployment or redeployment, and the removal of policies during undeployment are the following:
Migration
Listener
Principal Validation
Target of Migration (application stripe)
The configuration and function of each of the above is explained next.
Notes:
Fusion Middleware Control allows setting of most of these parameters when the application is deployed, redeployed, or undeployed. For details, see Section 6.2.1, "Deploying Java EE and Oracle ADF Applications with Fusion Middleware Control."
The configurations explained next need be entered manually only if you are not using Fusion Middleware Control to manage your application.
When deploying an application that is using file-based stores to a managed server running in a computer different from that where the administration server is running, do not use the life cycle listener. Otherwise, the data maintained by the managed server and the administration server would not match, and security may not work as expected. Instead of employing the life cycle listener, use the OPSS script migrateSecurityStore to migrate application policies and credentials to the domain stores.
The above remark applies only when using file-based stores.
This parameter specifies whether the migration should take place, and, when it does, whether it should merge with or overwrite matching policies present in the target store.
On WebLogic, it is configured as illustrated in the following fragment:
<wls:application-param>
<wls:param-name>jps.policystore.migration</wls:param-name>
<wls:param-value>Option</wls:param-value>
</wls:application-param>
Option stands for one of the following value is MERGE, OVERWRITE, or OFF.
For details about the configuration of this parameter on WebSphere, see Oracle Fusion Middleware Third-Party Application Server Guide.
Set to OFF to prevent policy migration; otherwise, set to MERGE to migrate and merge with existing policies, or to OVERWRITE to migrate and overwrite existing policies. The default value (at deploy) is MERGE.
This parameter specifies the target stripe into which policies are migrated.
On WebLogic, it is configured as illustrated in the following fragment:
<wls:application-param> <wls:param-name>jps.policystore.applicationid</wls:param-name> <wls:param-value>myApplicationStripe</wls:param-value> </wls:application-param>
For details about the configuration of this parameter on WebSphere, see Oracle Fusion Middleware Third-Party Application Server Guide.
This parameter's value can be any valid string; if unspecified, Oracle WebLogic Server picks up a stripe name based on the application name and version, namely, application_name#version.
The value of this parameter must match the value of application.name specified for the JpsServlet (in the file web.xml) or for the JpsInterceptor (in the file ejb-jar.xml). For details, see Application Name (Stripe).
The value picked from weblogic-application.xml is used at deploy time; the value picked from web.xml or ejb-jar.xml is used at runtime.
JpsApplicationLifecycleListener
This parameter is supported on WebLogic only, and it must be set as illustrated in the following fragment:
<wls:listener>
<wls:listener-class>
oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener
</wls:listener-class>
</wls:listener>
jps.apppolicy.idstoreartifact.migration
This parameter is supported on WebLogic only, and it specifies whether the policy migration should exclude migrating references to enterprise users or groups, such as application roles grants to enterprise users or groups, and permission grants to enterprise users or groups; thus it allows the migration of just application policies and, when enabled, the migration ignores the mapping of application roles to enterprise groups or users.
It is configured as illustrated in the following fragment:
<wls:application-param>
<wls:param-name>jps.apppolicy.idstoreartifact.migration</wls:param-name>
<wls:param-value>Option</wls:param-value>
</wls:application-param>
Option stands for one of the values TRUE or FALSE. Set to FALSE to exclude the migration of artifacts referencing enterprise users or groups; otherwise, set it to TRUE; if unspecified, it defaults to TRUE.
Important:
When an application is deployed with this parameter set to FALSE (that is, to exclude the migration of non-application specific policies), before the application can be used in the domain, the administrator should perform the mapping of application roles to enterprise groups or users with Fusion Middleware Control or the WebLogic Administration Console.
Note how this setting allows the administrator further control over application roles.
The following examples show fragments of the same jazn-data.xml files. This file, packaged in the application EAR file, describes the application authorization policy.
The file system-jazn-data.xml represents the domain file-based policy store into which application policies are migrated (and used in the example for simplicity).
It is assumed that the parameter jps.apppolicy.idstoreartifact.migration has been set to FALSE.
<!-- Example 1: app role applicationDeveloperRole in jazn-data.xml that references the enterprise group developers --> <app-role> <class>weblogic.security.principal.WLSGroupImpl</class> <name>applicationDeveloperRole</name> <display-name>application role applicationDeveloperRole</display-name> <members> <member> <class>weblogic.security.principal.WLSGroupImpl</class> <name>developers</name> </member> </members> </app-role> <!-- app role applicationDeveloperRole in system-jazn-data.xml after migration: notice how the role developers has been excluded --> <app-role> <name>applicationDeveloperRole</name> <display-name>application role applicationDeveloperRole</display-name> <guid>CB3633A0D0E811DDBF08952E56E4544A</guid> <class>weblogic.security.principal.WLSGroupImpl</class> </app-role> <!-- Example 2: app role viewerApplicationRole in jazn-data.xml makes reference to the anonymous role --> <app-role> <name>viewerApplicationRole</name> <display-name>viewerApplicationRole</display-name> <class>weblogic.security.principal.WLSGroupImpl</class> <members> <member> <class> oracle.security.jps.internal.core.principals.JpsAnonymousRoleImpl </class> <name>anonymous-role</name> </member> </members> </app-role> <!-- app role viewerApplicationRole in system-jazn-data.xml after migration: notice that references to the anonymous role are never excluded --> <app-role> <name>viewerApplicationRole</name> <display-name>viewerApplicationRole</display-name> <guid>CB3D86A0D0E811DDBF08952E56E4544A</guid> <class>weblogic.security.principal.WLSGroupImpl</class> <members> <member> <class> oracle.security.jps.internal.core.principals.JpsAnonymousRoleImpl </class> <name>anonymous-role</name> </member> </members> </app-role>
This parameter specifies whether the removal of policies at undeployment should not take place.
On WebLogic, it is configured as illustrated in the following fragment:
<wls:application-param> <wls:param-name>jps.policystore.removal</wls:param-name> <wls:param-value>OFF</wls:param-value> </wls:application-param>
For details about the configuration of this parameter on WebSphere, see Oracle Fusion Middleware Third-Party Application Server Guide.
When set, the parameter's value must be OFF. By default, it is not set.
Set to OFF to prevent the removal of policies; if not set, policies are removed.
The above setting should be considered when multiple applications are sharing the same application stripe. The undeploying application would choose not to remove application policies because other applications may be using the common set of policies.
Note:
Deciding to set this parameter to OFF for a given application requires knowing, at the time the application is deployed, whether the application stripe is shared by other applications.
jps.policystore.migration.validate.principal
This parameter is supported on WebLogic only, and it specifies whether the check for principals in system and application policies at deployment or redeployment should take place.
It is configured as illustrated in the following fragment:
<wls:application-param> <wls:param-name>jps.policystore.migration.validate.principal</wls:param-name> <wls:param-value>TRUE</wls:param-value> </wls:application-param>
When set, the parameter's value must be TRUE or FALSE.
When set to TRUE the system checks the validity of enterprise users and groups: if a principal (in an application or system policy) refers to an enterprise user or group not found in the identity store, a warning is issued. When set to FALSE, the check is skipped.
If not set, the parameter value defaults to FALSE.
Validation errors are logged in the server log, and they do not terminate the operation.
This section describes the settings required to manage application policies with the following behaviors:
Any value settings other than the ones described in the following sections are not recommended and may lead to unexpected migration behavior. For more details, see Recommendations.
All behaviors can be specified with Fusion Middleware Control when the application is deployed, redeployed, or undeployed with that tool.
The following matrix shows the settings that prevent the migration from taking place:
Table 21-2 Settings to Skip Policy Migration
| Valid at deploy or redeploy | |
|---|---|
|
JpsApplicationLifecycleListener |
Set |
|
jps.policystore.migration |
OFF |
Typically, you would skip migrating policies when redeploying the application when you want to keep domain policies as they are, but you would migrate policies when deploying the application for the first time.
The following matrix shows the setting of required and optional parameters that migrates only policies that are not in the target store (optional parameters are enclosed in between brackets):
Table 21-3 Settings to Migrate Policies with Merging
| Valid at deploy or redeploy | |
|---|---|
|
JpsApplicationLifecycleListener |
Set |
|
jps.policystore.migration |
MERGE |
|
[jps.policystore.applicationid] |
Set to the appropriate string. Defaults to servlet or EJB name. |
|
[jps.apppolicy.idstoreartifact.migration] |
Set to FALSE to exclude migrating policies that reference enterprise artifacts; otherwise set to TRUE. Defaults to TRUE. |
|
[jps.policystore.migration.validate.principal] |
Set to TRUE to validate enterprise users and roles in application and system policies. Set to FALSE, otherwise. If unspecified, it defaults to FALSE. |
Typically, you would choose migrating policies with merging at redeploy when the policies have changed and you want to add to the existing policies.
The following matrix shows the setting that migrates all policies overwriting matching target policies (optional parameters are enclosed in between brackets):
Table 21-4 Settings to Migrate Policies with Overwriting
| Valid at deploy or redeploy | |
|---|---|
|
JpsApplicationLifecycleListener |
Set |
|
jps.policystore.migration |
OVERWRITE |
|
[jps.policystore.migration.validate.principal] |
Set to TRUE to validate enterprise users and roles in application and system policies. Set to FALSE, otherwise. If unspecified, it defaults to FALSE. |
Typically, you would choose migrating policies with overwriting at redeploy when a new set of policies should replace existing policies. Note that if the optional parameter jps.policy.migration.validate.principal is needed, it must be set manually.
The removal of application policies at undeployment is limited since code source grants in the system policy are not removed. For details, see example in What Gets Removed and What Remains.
The following matrix shows the setting that removes policies at undeployment:
Table 21-5 Settings to Remove Policies
| Valid at undeploy | |
|---|---|
|
JpsApplicationLifecycleListener |
Set |
|
jps.policystore.removal |
Not set (default) |
Note:
The policies removed at undeploy are determined by the stripe that the application specified at deploy or redeploy. If an application is redeployed with a stripe specification different than the original one, then policies in that stripe (the original) are not removed.
The following matrix shows the setting that prevents the removal of application policies at undeployment:
Table 21-6 Settings to Prevent the Removal of Policies
| Valid at undeploy | |
|---|---|
|
JpsApplicationLifecycleListener |
Set |
|
jps.policystore.removal |
OFF |
Note:
Deciding to set this parameter to OFF for a given application requires knowing, at the time the application has been deployed, whether the application stripe is shared by other applications.
What Gets Removed and What Remains
Consider the application myApp, which has been configured for automatic migration and removal of policies. The following fragment of the application's jazn-data.xml file (packed in the application EAR file) illustrates the application policies that are migrated when the application is deployed with Fusion Middleware Control and those that are and are not removed when the application is undeployed with Fusion Middleware Control:
<jazn-data>
<policy-store>
<applications>
<!-- The contents of the following element application is migrated
to the element policy-store in domain system-jazn-data.xml;
when myApp is undeployed with EM, it is removed from domain store -->
<application>
<name>myApp</name>
<app-roles>
<app-role>
<class>oracle.security.jps.service.policystore.SomeRole</class>
<name>applicationDeveloperRole</name>
<display-name>application role applicationDeveloperRole</display-name>
<members>
<member>
<class>oracle.security.somePath.JpsXmlEnterpriseRoleImpl</class>
<name>developers</name>
</member>
</members>
</app-role>
</app-roles>
<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<name>applicationDeveloperRole</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>loadPolicy</name>
</permission>
</permissions>
</grant>
</jazn-policy>
</application>
</applications>
</policy-store>
<jazn-policy>
<!-- The following codebase application grant is migrated to the element
jazn-policy in domain system-jazn-data.xml; when myApp is undeployed
with EM, it is not removed from domain store -->
<grant>
<grantee>
<codesource>
<url>file:${domain.home}/servers/${weblogic.Name}/Foo.ear/-</url>
</codesource>
</grantee>
<permissions>
<permission> <class>oracle.security.jps.service.credstore.CredentialAccessPermission</class>
<name>context=SYSTEM,mapName=*,keyName=*</name>
<actions>*</actions>
</permission>
</permissions>
</grant>
</jazn-policy>
</jazn-data>
To summarize: in regards to what gets removed, the important points to remember are the following:
All data inside the element <application> can be automatically removed at undeployment. In case of an LDAP-based policy store, the application scoped authorization policy data nodes get cleaned up.
All data inside the element <jazn-policy> cannot be automatically removed at undeployment.
Table 21-7 shows the setting that migrates application policies when the application is statically deployed. The MERGE or OVERWRITE operation takes place only if the application policies do not already exist in the domain.
Table 21-7 Settings to Migrate Policies with Static Deployments
|
JpsApplicationLifecycleListener |
Set |
|
jps.policystore.migration |
MERGE or OVERWRITE |
Table 21-8 shows the setting that skip the migration of application policies when the application is statically deployed.
Keep in mind the following suggestions:
When a LDAP-based policy store is used and the application is to be deployed to multiple managed servers, then choose to migrate to one of the servers only. The rest of the deployments should choose not to migrate policies. This ensures that the policies are migrated only once from the application store to the policy store.All the deployments must use the same application id.
Attempting policy migration to the same node for the same application multiple times (for example, on different managed servers) can result in policy migration failures. An alternative is to migrate the policy data to the store outside of the deployment process using the OPSS script migrateSecurityStore.
If, however, the application is deployed to several servers and the policy store is file-based, the deployment must include the administration server for the migration to update the policy file $DOMAIN_HOME/config/fmwconfig/system-jazn-data.xml.
The content of a wallet-based credential store is defined in a file that must be named cwallet.sso. A wallet-based credential store is also referred to as a file-based credential store.
For instructions on how to create a wallet, see section Common Wallet Operations in Oracle Fusion Middleware Administrator's Guide.
The location of the file cwallet.sso is specified in the configuration file jps-config.xml with the element <serviceInstance>, as illustrated in the following example:
<serviceInstance name="credstore" provider="credstoressp"> <property name="location" value="myCredStorePath"/> </serviceInstance>
For other types of credential storage, see chapter Managing Keystores, Wallets, and Certificates in Oracle Fusion Middleware Administrator's Guide.
The migration of application credentials at deployment is controlled by several parameters configured in the file META-INF/weblogic-application.xml.
For details about the specification of these parameters on WebSphere, see Oracle Fusion Middleware Third-Party Application Server Guide.
The parameter that controls credential migration is jps.credstore.migration. The listener is JpsApplicationLifecycleListener - Credentials.
This parameter specifies whether the migration should take place, and, when it does, whether it should merge with or overwrite matching credentials present in the target store.
On WebLogic, it is configured as illustrated in the following fragment:
<wls:application-param>
<wls:param-name>jps.credstore.migration</wls:param-name>
<wls:param-value>behaviorValue</wls:param-value>
</wls:application-param>
For details about the specification this parameter on WebSphere, see Oracle Fusion Middleware Third-Party Application Server Guide.
If set, this parameter's value must be one of the following: MERGE, OVERWRITE, or OFF. The OVERWRITE value is available on WebLogic only and when the server is running in development mode.
If not set, the migration of credentials takes place with the option MERGE.
JpsApplicationLifecycleListener - Credentials
This listener is supported only on WebLogic and it is configured as illustrated in the following fragment:
<wls:listener>
<wls:listener-class>
oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener
</wls:listener-class>
</wls:listener>
This section describes the manual settings required to migrate application credentials with the following behaviors:
Any value settings other than the ones described in the following sections are not recommended and may lead to unexpected migration behavior.
If the migration target is an LDAP-based credential store, it is recommended that the application be deployed to just one managed server or cluster. Otherwise, application credentials may not work as expected.
Note:
Credentials are not deleted upon an application undeployment. A credential may have started its life as being packaged with an application, but when the application is undeployed credentials are not removed.
The following matrix shows the setting that prevents the migration from taking place:
The following matrix shows the setting of required and optional parameters that migrates only credentials that are not present in the target store (optional parameters are enclosed in between brackets):
The components of a permission are illustrated in the following snippet from a system-jazn-data.xml file:
<grant>
<grantee>
<codesource>
<url>file:${oracle.deployed.app.dir}/<MyApp>${oracle.deployed.app.ext}</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>
oracle.security.jps.service.policystore.PolicyStoreAccessPermission
</class>
<name>context=SYSTEM</name>
<actions>getConfiguredApplications</actions>
</permission>
<permission>
<class>
oracle.security.jps.service.policystore.PolicyStoreAccessPermission
</class>
<name>context=APPLICATION,name=*</name>
<actions>getApplicationPolicy</actions>
</permission>
</permissions>
</grant>
This section describes the supported values for the elements <class>, <name>, and <actions> within a <permission>.
Important:
All permission classes used in policies must be included in the class path, so the policy provider can load them when a service instance is initialized.
Class name:
oracle.security.jps.service.policystore.PolicyStoreAccessPermission
When the permission applies to a particular application, use the following pattern for the corresponding element <name>:
context=APPLICATION,name=appStripeName
When the permission applies to all applications, use the following name pattern for the corresponding element <name>:
context=APPLICATION,name=*
When the permission applies to all applications and system policies, use the following name pattern for the corresponding element <name>:
context=APPLICATION
The list of values allowed in the corresponding element <actions> are the following (* stands for any allowed action):
* createPolicy getConfiguredApplications getSystemPolicy getApplicationPolicy createApplicationPolicy deleteApplicationPolicy grant revoke createAppRole alterAppRole removeAppRole addPrincipalToAppRole removePrincipalFromAppRole hasPermission containsAppRole
Class name:
oracle.security.jps.service.credstore.CredentialAccessPermission
When the permission applies to a particular map and a particular key in that map, use the following pattern for the corresponding element <name>:
context=SYSTEM,mapName=myMap,keyName=myKey
When the permission applies to a particular map and all keys in that map, use the following pattern for the corresponding element <name>:
context=SYSTEM,mapName=myMap,keyName=*
The list of values allowed in the corresponding element <actions> are the following (* stands for any allowed action):
* read write update delete
Class name:
oracle.security.jps.JpsPermission
When the permission applies to an assertion performed by a callback instance of oracle.security.jps.callback.IdentityCallback, use the following pattern for the corresponding element <name>:
IdentityAssertion
The only value allowed in the corresponding element <actions> is the following:
execute
This topic is for an administrator who is not using Oracle Fusion Middleware Control to perform reassociation to an LDAP-based store.
The credentials needed for an administrator to connect to and access an LDAP directory must be specified in a separate file named cwallet.sso (bootstrap credentials) and configured in the file jps-config.xml. These credentials are stored after the LDAP reassociation process. Bootstrap credentials are always file-based.
Every instance of an LDAP-based policy or credential store must specify bootstrap credentials in a <jpsContex> element that must be named bootstrap_credstore_context, as illustrated in the following excerpt:
<serviceInstances>
...
<serviceInstance location="./bootstrap" provider="credstoressp" name="bootstrap.cred">
<property value="./bootstrap" name="location"/>
</serviceInstance>
...
</serviceInstances>
<jpsContext name="bootstrap_credstore_context">
<serviceInstanceRef ref="bootstrap.cred"/>
</jpsContext>
In the example above, the bootstrap credential cwallet.sso is assumed located in the directory bootstrap.
An LDAP-based policy or credential store instance references its credentials using the properties bootstrap.security.principal.key and bootstrap.security.principal.map, as illustrated in the following instance of an LDAP-based policy store:
<serviceInstance provider="ldap.policystore.provider" name="policystore.ldap"> ... <property value="bootstrapKey" name="bootstrap.security.principal.key"/> ... </serviceInstance>
If the property bootstrap.security.principal.map is not specified in the service instance, its value defaults to BOOTSTRAP_JPS.
To modify or add bootstrap credentials with OPSS scripts, see Section 10.5.5, "modifyBootStrapCredential," and Section 10.5.6, "addBootStrapCredential."
Identity data can be migrated manually from a source repository to a target LDAP repository using the OPSS script migrateSecurityStore. The script produces an LDIF file that (after minor manual editing) can be imported into an LDAP-based identity store and can be used with any source 10g or 11g file-based identity store.
For example, this script can be used to convert user and role information in a 10.1.x jazn-data.xml file to user and role information in WebLogic LDIF format; the LDIF output file can then be imported into the WebLogic embedded LDAP identity store after changing the password for each user (see note at the end of this section).
This script is offline, that is, it does not require a connection to a running server to operate; therefore, the configuration file passed to the argument configFile need not be an actual domain configuration file, but it can be assembled just to specify the source and destination repositories of the migration.
This script can be run in interactive mode or in script mode, on WebLogic Server, and in interactive mode only, on WebSphere. In interactive mode, you enter the script at a command-line prompt and view the response immediately after. In script mode, you write scripts in a text file (with a py file name extension) and run it without requiring input, much like the directives in a shell script.
For platform-specific requirements to run an OPSS script, see Important Note.
Script and Interactive Modes Syntaxes
To migrate identities on WebLogic, use the script (first) or interactive (second) syntaxes (arguments are written in separate lines for clarity):
migrateSecurityStore -type idStore
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
[-dstLdifFile LdifFileLocation]
migrateSecurityStore(type="idStore", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext", [dstLdifFile="LdifFileLocation"])
For details about running OPSS scripts on WebSphere Application Server, see
The meaning of the arguments (all required except dstLdifFile) is as follows:
configFile specifies the location of a configuration file jps-config.xml relative to the directory where the script is run.
src specifies the name of a jps-context in the configuration file passed to the argument configFile, where the source store is specified.
dst specifies the name of another jps-context in the configuration file passed to the argument configFile, where the destination store is specified.
The destination store must be an LDAP-based identity store. For list of supported types, see Section 3.1.1, "Supported LDAP Identity Store Types."
dstLdifFile specifies the relative or absolute path to the LDIF file created. Applies only when the destination is an LDAP-based Oracle Internet Directory store, such as the embedded LDAP. Notice that the LDIF file is not imported into the LDAP server and, typically, requires manual editing.
The contexts passed to src and dst must be defined in the passed configuration file and must have distinct names. From these two contexts, the script determines the locations of the source and the target repositories involved in the migration.
Important:
The password of every user in the output LDIF file is not the real user password, but the fake string weblogic. In case the destination is an LDAP-based Oracle Internet Directory store, the fake string is change.
Therefore, before importing the LDIF file into the target LDAP store, the security administrator would typically edit this file and change the fake passwords for real ones.
The following sample shows a complete jps-config.xml file that illustrates the configuration of several services and properties; they apply to both Java EE and Java SE applications.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <jpsConfig xmlns="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd"> <property value="off" name="oracle.security.jps.jaas.mode"/> <propertySets> <propertySet name="saml.trusted.issuers.1"> <property value="www.oracle.com" name="name"/> </propertySet> </propertySets> <serviceProviders> <serviceProvider class="oracle.security.jps.internal.credstore.ssp.SspCredentialStoreProvider" name="credstoressp" type="CREDENTIAL_STORE"> <description>SecretStore-based CSF Provider</description> </serviceProvider> <serviceProvider class="oracle.security.jps.internal.idstore.ldap.LdapIdentityStoreProvider" name="idstore.ldap.provider" type="IDENTITY_STORE"> <description>LDAP-based IdentityStore Provider</description> </serviceProvider> <serviceProvider class="oracle.security.jps.internal.idstore.xml.XmlIdentityStoreProvider" name="idstore.xml.provider" type="IDENTITY_STORE"> <description>XML-based IdentityStore Provider</description> </serviceProvider> <serviceProvider class="oracle.security.jps.internal.policystore.xml.XmlPolicyStoreProvider" name="policystore.xml.provider" type="POLICY_STORE"> <description>XML-based PolicyStore Provider</description> </serviceProvider> <serviceProvider class="oracle.security.jps.internal.login.jaas.JaasLoginServiceProvider" name="jaas.login.provider" type="LOGIN"> <description>JaasLoginServiceProvider to conf loginMod servInsts</description> </serviceProvider> <serviceProvider class="oracle.security.jps.internal.keystore.KeyStoreProvider" name="keystore.provider" type="KEY_STORE"> <description>PKI Based Keystore Provider</description> <property value="owsm" name="provider.property.name"/> </serviceProvider> <serviceProvider class="oracle.security.jps.internal.audit.AuditProvider" name="audit.provider" type="AUDIT"> <description>Audit Service</description> </serviceProvider> <serviceProvider class="oracle.security.jps.internal.credstore.ldap.LdapCredentialStoreProvider" name="ldap.credentialstore.provider" type="CREDENTIAL_STORE"/> <serviceProvider class="oracle.security.jps.internal.policystore.ldap.LdapPolicyStoreProvider" name="ldap.policystore.provider" type="POLICY_STORE"> <property value="OID" name="policystore.type"/> </serviceProvider> </serviceProviders> <serviceInstances> <serviceInstance location="./" provider="credstoressp" name="credstore"> <description>File Based Credential Store Service Instance</description> </serviceInstance> <serviceInstance provider="idstore.ldap.provider" name="idstore.ldap"> <property value="oracle.security.jps.wls.internal.idstore.WlsLdapIdStoreConfigProvider" name="idstore.config.provider"/> </serviceInstance> <serviceInstance location="./system-jazn-data.xml" provider="idstore.xml.provider" name="idstore.xml"> <description>File Based Identity Store Service Instance</description> <property value="jazn.com" name="subscriber.name"/> </serviceInstance> <serviceInstance location="./system-jazn-data.xml" provider="policystore.xml.provider" name="policystore.xml"> <description>File Based Policy Store Service Instance</description> </serviceInstance> <serviceInstance location="./default-keystore.jks" provider="keystore.provider" name="keystore"> <description>Default JPS Keystore Service</description> <property value="JKS" name="keystore.type"/> <property value="oracle.wsm.security" name="keystore.csf.map"/> <property value="keystore-csf-key" name="keystore.pass.csf.key"/> <property value="enc-csf-key" name="keystore.sig.csf.key"/> <property value="enc-csf-key" name="keystore.enc.csf.key"/> </serviceInstance> <serviceInstance provider="audit.provider" name="audit"> <property value="None" name="audit.filterPreset"/> <property value="0" name="audit.maxDirSize"/> <property value="104857600" name="audit.maxFileSize"/> <property value="jdbc/AuditDB" name="audit.loader.jndi"/> <property value="15" name="audit.loader.interval"/> <property value="File" name="audit.loader.repositoryType"/> </serviceInstance> <serviceInstance provider="jaas.login.provider" name="saml.loginmodule"> <description>SAML Login Module</description> <property value="oracle.security.jps.internal.jaas.module.saml.JpsSAMLLoginModule" name="loginModuleClassName"/> <property value="REQUIRED" name="jaas.login.controlFlag"/> <propertySetRef ref="saml.trusted.issuers.1"/> </serviceInstance> <serviceInstance provider="jaas.login.provider" name="krb5.loginmodule"> <description>Kerberos Login Module</description> <property value="com.sun.security.auth.module.Krb5LoginModule" name="loginModuleClassName"/> <property value="REQUIRED" name="jaas.login.controlFlag"/> <property value="true" name="storeKey"/> <property value="true" name="useKeyTab"/> <property value="true" name="doNotPrompt"/> <property value="./krb5.keytab" name="keyTab"/> <property value="HOST/localhost@EXAMPLE.COM" name="principal"/> </serviceInstance> <serviceInstance provider="jaas.login.provider" name="digest.authenticator.loginmodule"> <description>Digest Authenticator Login Module</description> <property value="oracle.security.jps.internal.jaas.module.digest.DigestLoginModule" name="loginModuleClassName"/> <property value="REQUIRED" name="jaas.login.controlFlag"/> </serviceInstance> <serviceInstance provider="jaas.login.provider" name="certificate.authenticator.loginmodule"> <description>X509 Certificate Login Module</description> <property value="oracle.security.jps.internal.jaas.module.x509.X509LoginModule" name="loginModuleClassName"/> <property value="REQUIRED" name="jaas.login.controlFlag"/> </serviceInstance> <serviceInstance provider="jaas.login.provider" name="wss.digest.loginmodule"> <description>WSS Digest Login Module</description> <property value="oracle.security.jps.internal.jaas.module.digest.WSSDigestLoginModule" name="loginModuleClassName"/> <property value="REQUIRED" name="jaas.login.controlFlag"/> </serviceInstance> <serviceInstance provider="jaas.login.provider" name="user.authentication.loginmodule"> <description>User Authentication Login Module</description> <property value="oracle.security.jps.internal.jaas.module.authentication.JpsUserAuthenticationLoginModule" name="loginModuleClassName"/> <property value="REQUIRED" name="jaas.login.controlFlag"/> </serviceInstance> <serviceInstance provider="jaas.login.provider" name="user.assertion.loginmodule"> <description>User Assertion Login Module</description> <property value="oracle.security.jps.internal.jaas.module.assertion.JpsUserAssertionLoginModule" name="loginModuleClassName"/> <property value="REQUIRED" name="jaas.login.controlFlag"/> </serviceInstance> <serviceInstance provider="ldap.credentialstore.provider" name="credstore.ldap"> <property value="bootstrap" name="bootstrap.security.principal.key"/> <property value="cn=wls-jrfServer" name="oracle.security.jps.farm.name"/> <property value="cn=jpsTestNode" name="oracle.security.jps.ldap.root.name"/> <property value="ldap://stadw12.us.oracle.com:3060" name="ldap.url"/> </serviceInstance> <serviceInstance location="./bootstrap" provider="credstoressp" name="bootstrap.cred"> <property value="./bootstrap" name="location"/> </serviceInstance> <serviceInstance provider="ldap.policystore.provider" name="policystore.ldap"> <property value="OID" name="policystore.type"/> <property value="bootstrap" name="bootstrap.security.principal.key"/> <property value="cn=wls-jrfServer" name="oracle.security.jps.farm.name"/> <property value="cn=jpsTestNode" name="oracle.security.jps.ldap.root.name"/> <property value="ldap://stadw12.us.oracle.com:3060" name="ldap.url"/> </serviceInstance> </serviceInstances> <jpsContexts default="default"> <jpsContext name="default"> <serviceInstanceRef ref="keystore"/> <serviceInstanceRef ref="audit"/> <serviceInstanceRef ref="credstore.ldap"/> <serviceInstanceRef ref="policystore.ldap"/> </jpsContext> <jpsContext name="oracle.security.jps.fmw.authenticator.DigestAuthenticator"> <serviceInstanceRef ref="digest.authenticator.loginmodule"/> </jpsContext> <jpsContext name="X509CertificateAuthentication"> <serviceInstanceRef ref="certificate.authenticator.loginmodule"/> </jpsContext> <jpsContext name="SAML"> <serviceInstanceRef ref="saml.loginmodule"/> </jpsContext> <jpsContext name="bootstrap_credstore_context"> <serviceInstanceRef ref="bootstrap.cred"/> </jpsContext> </jpsContexts> </jpsConfig>
|
 Copyright © 2003, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|