15 Manually Configuring JavaEE Applications to Use OPSS

This chapter describes the manual configuration and packaging recommended for JavaEE 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 JavaEE 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:

Prior to using this information, it is strongly recommended to be familiar with the context it is used. For details, see Chapter 14, "Overview of Developing Secure Applications with Oracle Platform Security Services."

15.1 Configuring the Servlet Filter and the EJB Interceptor

Note:

Oracle JDeveloper automatically inserts the required servlet filter (JpsFilter) and EJB interceptor (JpsInterceptor) configurations for Oracle ADF applications.

You enter the configurations explained in this section manually only if you are packaging or configuring a JavaEE application that uses OPSS outside that environment.

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.

Both allow the configuration of 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 domain 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.

Application Name (Stripe)

This value is controlled by the following parameter:

application.name

The specification of this parameter is optional; 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 wants to use.

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.

Application Roles Support

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 false.

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 true. 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 
...

Authenticated Role Support

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>

JAAS Mode

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 18.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>

15.1.1 Interceptor Configuration Syntax

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.

15.1.2 Summary of Filter and Interceptor Parameters

The following table summarizes the description of the parameters used by the JpsFilter and the JpsInterceptor:

Table 15-1 Summary of JpsFilter and JpsInterceptor Parameters

Parameter Name Values Default Function Notes

application.name

Any valid string

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 domain 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

FALSE

To enable or disable the anonymous Subject.

Set to TRUE to create to allow the creation of a Subject with the anonymous user and the anonymous role.

remove.anonymous.role

TRUE or FALSE

TRUE

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.

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.

 

15.2 Choosing the Appropriate Class for Enterprise Groups and Users

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 I.6, "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> 

15.3 Packaging a JavaEE Application Manually

This section explains the packaging requirements for a servlet or an EJB (using custom policies and credentials) in a WAR file that is to be deployed with the Oracle WebLogic Administration Console.

Application policies are defined in the file jazn-data.xml. The only supported way to package this file with an application is 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 JavaEE 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 domain 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.

15.3.1 Packaging Policies with Application

Application policies are defined in the file jazn-data.xml. The only supported way to package this file with an application is 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 the 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.

15.3.2 Packaging Credentials with Application

Application credentials are defined in a file that must be named cwallet.sso. The only supported way to package this file with an application is 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 the 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 topcwallet.sso are disregarded.

15.4 Configuring a JavaEE Application to Use OPSS

This section describes several configurations that a developer would perform manually for a JavaEE application developed outside the Oracle JDeveloper environment, in the following sections:

15.4.1 Parameters Controlling Policy Migration

The migration of policies is controlled by several properties that configure two listeners that control the migration behavior. In addition, versioning of the application manifest is a requirement to support redeploy scenarios.

All parameters, except for versioning, are configured in the file META-INF/weblogic-application.xml, and versioning is configured in the file META-INF/MANIFEST.MF.

The parameters that control policy migration during application deployment are the following:

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 7.2.1, "Deploying JavaEE 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 listeners. 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 listeners, use the WLST command migrateSecurityStore to migrate application policies and credentials to the domain stores.

jps.policystore.migration

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.

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.

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.

Note:

If this property is not specified, then:
  • The first time the application is deployed, policy migration takes place.

  • The second and succeeding times the application is deployed, policy migration does not take place.

jps.policystore.applicationid

This parameter specifies the target stripe into which policies are migrated.

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>

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 must always be set as illustrated in the following fragment:

<wls:listener>
  <wls:listener-class>
    oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener
  </wls:listener-class>
</wls:listener>

JpsAppVersionLifecycleListener

This parameter controls the removal of policies at undeployment and the overwriting of policies at redeployment.

It is set as illustrated in the following fragment:

<wls:listener>
  <wls:listener-class>
    oracle.security.jps.wls.listeners.JpsAppVersionLifecycleListener
  </wls:listener-class>
</wls:listener>

Versioning the Application

This parameter controls the removal of policies at undeployment and the overwriting of policies at redeployment. If not set, on application undeployment, application policies are not removed.

It is set in the file META-INF/MANIFEST.MF of an EAR file, as illustrated in bold text in the following fragment:

Manifest-Version: 1.0
Created-By: 1.5.0_14 (Sun Microsystems Inc.)
Weblogic-Application-Version: V1.0

The version string (V1.0 in the example above) can be set to any string. Though the actual value does not matter, typically, application developers may use version information based on the history of changes.

jps.apppolicy.idstoreartifact.migration

This parameter 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>

jps.policystore.removal

This parameter specifies whether the removal of policies at undeployment should not take place.

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>

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 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>TRUEorFALSE</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.

Any validation errors are logged in the server log and they do not terminate the operation.

15.4.2 Policy Parameter Configuration According to Behavior

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.

15.4.2.1 To Skip Migrating All Policies

The following matrix shows two settings that prevent the migration from taking place:

Table 15-2 Settings to Skip Policy Migration


Setting 1- Valid at deploy or redeploy Setting 2- Valid at redeploy

JpsApplicationLifecycleListener

Set

Set

JpsAppVersionLifecycleListener

n/a

Not set

jps.policystore.migration

OFF

n/a


Typically, you would skip migrating policies at redeploy when you want to keep policies as they are; however, you would always want to migrate policies when the application is deployed for the first time.

15.4.2.2 To Migrate All Policies with Merging

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 15-3 Settings to Migrate Policies with Merging


Valid at deploy

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.

15.4.2.3 To Migrate All Policies with Overwriting

The following matrix shows the setting that migrates all policies overwriting matching target policies (optional parameters are enclosed in between brackets):

Table 15-4 Settings to Migrate Policies with Overwriting


Valid at redeploy

JpsApplicationLifecycleListener

Set

JpsAppVersionLifecycleListener

Set

jps.policystore.migration

OVERWRITE

Versioning in application manifest

Set

[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.

15.4.2.4 To Remove (or Prevent the Removal of) Application Policies

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 15-5 Settings to Remove Policies


Valid at undeploy

JpsApplicationLifecycleListener

Set

JpsAppVersionLifecycleListener

Set

Versioning in application manifest

Set

jps.policystore.removal

Not set (default)


The following matrix shows the setting that prevents the removal of application policies at undeployment:

Table 15-6 Settings to Prevent the Removal of Policies


Valid at undeploy

JpsApplicationLifecycleListener

Set

JpsAppVersionLifecycleListener

Set

Versioning in application manifest

Set

jps.policystore.removal

OFF


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.

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 code-based 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.

15.4.2.5 Recommendations

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 domain 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 WLST command 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 domain policy file $DOMAIN_HOME/config/fmwconfig/system-jazn-data.xml.

15.4.3 Using a Wallet-Based Credential Store

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.

15.4.4 Parameters Controlling Credential Migration

The migration of credentials is defined by a parameter that configures the listener that controls the migration behavior. This parameter is configured in the file META-INF/weblogic-application.xml.

The parameter that controls credential migration is jps.credstore.migration. The listener is JpsApplicationLifecycleListener - Credentials.

jps.credstore.migration

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.

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>

If set, this parameter's value must be one of the following: MERGE, OVERWRITE, or OFF. The OVERWRITE value is available only 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 specified as illustrated in the following fragment:

<wls:listener>
  <wls:listener-class>  
     oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener
  </wls:listener-class>
</wls:listener>

15.4.5 Credential Parameter Configuration According to Behavior

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 it life as being packaged with an application, but when the application is undeployed credentials are not removed.

15.4.5.1 To Skip Migrating Credentials

The following matrix shows the setting that prevents the migration from taking place:

Table 15-7 Settings to Skip Credential Migration


Valid at deploy or redeploy

jps.credstore.migration

OFF


15.4.5.2 To Migrate Credentials with Merging

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):

Table 15-8 Settings to Migrate Credentials with Merging


Valid at deploy or redeploy

JpsApplicationLifecycleListener

Set

jps.credstore.migration

MERGE


15.4.5.3 To Migrate Credentials with Overwriting

This operation is valid only when the WebLogic server is running in development mode. The following matrix shows the setting that migrates all credentials overwriting matching target credentials:

Table 15-9 Settings to Migrate Credentials with Overwriting


Valid at deploy or redeploy

JpsApplicationLifecycleListener

Set

jps.credstore.migration

OVERWRITE

jps.app.credential.overwrite.allowed

This system property must be set to TRUE


15.4.6 Supported Permission Classes

The components of a permission are illustrated in the following snippet from a system-jazn-data.xml file:

<grant>
  <grantee>
    <codesource>
      <url>file:/path/foo.jar</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 classpath, so the policy provider can load them when a service instance is initialized.

15.4.6.1 Policy Store Permission

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

15.4.6.2 Credential Store Permission

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

15.4.6.3 Generic Permission

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

15.4.7 Specifying Bootstrap Credentials Manually

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 bootstrap credential store 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 bootstrap credentials with an WLST command, see Section 9.5.2.5, "modifyBootStrapCredential."

15.4.8 Migrating Identities with the Command migrateSecurityStore

Identity data can be migrated manually from a source repository to a target repository using the WLST command migrateSecurityStore.

This command 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.

The commands listed below can be run in interactive mode or in script mode. In interactive mode, a command is entered at a command-line prompt and view the response immediately after. In script mode, commands are written in a text file (with a py file name extension) and run without requiring input, much like the directives in a shell script.

Important:

Before invoking a security-related WLST command in a shell, you must run the script wlst.sh, as illustrated in the following sample:
> sh $ORACLE_HOME/common/bin/wlst.sh

This ensures that the required JARs are added to the classpath. Failure to run the above script in a new shell renders the WLST commands unusable.

Before running an online command, connect to the server as follows:

>java weblogic.WLST
>connect('servername', 'password', 'localhost:portnum')

Script and Interactive Modes Syntaxes

To migrate identities, 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"])
                     

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 command 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 can be XML-based or LDAP-based backed by an Oracle Internet Directory server. No other destination is supported.

  • dstLdifFile specifies the location where the LDIF file is created. Required only if destination is an LDAP-based Oracle Internet Directory store. Notice that the LDIF file is not imported into the LDAP server.

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 command determines the locations of the source and the target repositories involved in the migration.

After an LDIF file is generated, the next step typically involves manual editing this file to customize the attributes of the LDAP repository where the LDIF file would, eventually, be imported.

15.4.9 Example of Configuration File jps-config.xml

The following sample shows a complete jps-config.xml file that illustrates the configuration of several services and properties; they apply to both JavaEE and JavaSE 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>