The application stripe is optionally specified in the application web.xml file, and it is used at runtime to determine which set of policies are applicable. If unspecified, it defaults to the application ID (which includes the application name).

To set the application stripe, use the application.name parameter. This setting is optional and case-sensitive. If unspecified, it defaults to the name of the application.

To specify the application stripe, configure either the filter or the context-param elements in web.xml:

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

<context-param>
 <description>JPS custom stripe id</description>
 <param-name>application.name</param-name>
 <param-value>stripeid</param-value>
</context-param>

If your application contains application MBeans that access the security store and your the name of your application is different from the name of the stripe they access, then you must use the context-param configuration like the previous one to specify the stripe name.

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

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

To add application roles to a subject, set the add.application.roles parameter to true. Not to add them, set it to false. The default value is true. The principal class for an application role is the oracle.security.jps.service.policystore.ApplicationRole class.

To enable the use of the anonymous user, set enable.anonymous to true. To disable it, set it to false. The default value is true.

To remove the anonymous role from a subject, set remove.anonymous.role to true. To retain it, set it to false. The default value is false.

The names and the principal classes for the anonymous user and role are:

anonymous
oracle.security.jps.internal.core.principals.JpsAnonymousUserImpl
anonymous-role
oracle.security.jps.internal.core.principals.JpsAnonymousRoleImpl

The following example illustrates the setting of the anonymous user and role in the web.xml file, and the use of the JpsFilter filter by the MyServlet Java servlet:

<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 example illustrates the setting of remove.anonymous.role in the ejb-jar.xml file, and the use of the interceptor by 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>

To add the authenticated role to a subject, set the add.authenticated.role property to true. Not to add it, set it to false. The default value is true.

The name and principal class for the authenticated role are:

authenticated-role
oracle.security.jps.internal.core.principals.JpsAuthenticatedRoleImpl

The following example illustrates the configuration of the add.authenticated.role property and the use of the JpsFilter filter by the MyServlet Java servlet, in the web.xml file:

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

To set JAAS mode use the oracle.security.jps.jaas.mode parameter with one of the following values:

doAs
doAsPrivileged
off
undefined
subjectOnly

The default value is doAsPrivileged.

The following example illustrates the use of the JpsFilter filter by the MyServlet Java servlet:

<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 example illustrates a doAs setting and the use of the JpsInterceptor interceptor:

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

Application policies are defined in the jazn-data.xml file. The only supported way to include this file with an application is to package it in the META-INF directory of the application EAR file.

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. No other policy package combination is supported, and policy files other than jazn-data.xml are disregarded.

Application credentials are defined in the cwallet.sso file. The only supported way to include this file with an application is to package it in the META-INF directory of the application EAR file.

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. No other credential package combination is supported, and credential files other than the cwallet.sso file are disregarded.

You control the migration of application policies at deployment with parameters specified in the META-INF/weblogic-application.xml file. If you do not use Fusion Middleware Control to manage your application, then you must enter these configurations manually.

Set thejps.deployment.handler.disabled system property to true to disable the migration of policies and credentials at deployment for all applications regardless of particular settings in the weblogic-application.xml files.

When you deploy an application that incudes policies and credentials to a Managed Server running in a computer different from where the Administration Server is running, do not use the life cycle listener to control migration at deployment, because the data maintained by the Managed Server and the Administration Server would end up not synchronized. Instead, use the migrateSecurityStore command to migrate those policies and credentials to the security store.

The parameters that configure the migration and removal of policies are the following:

• Migration

  • jps.policystore.migration

  • jps.apppolicy.idstoreartifact.migration

  • jps.policystore.removal

• Listener

  • JpsApplicationLifecycleListener

• Principal Validation

  • jps.policystore.migration.validate.principal

• Target of Migration (application stripe)

  • jps.policystore.applicationid

• jps.policystore.migration
  
• jps.policystore.applicationid
  
• jps.apppolicy.idstoreartifact.migration
  
• jps.policystore.removal
  
• jps.policystore.migration.validate.principal
  
• JpsApplicationLifecycleListener
  

The following sections describe recommendations and the settings required in typical scenarios:

• Recommendations
  
• Skipping Migrating Policies
  
• Migrating Merging Policies
  
• Migrating Overwriting Policies
  
• Removing or Not Removing Policies
  
• Migrating Policies in a Static Deployment
  

A file credential store is the cwallet.sso file. The location of this file is specified in the jps-config.xml file with the <serviceInstance> element:

<serviceInstance name="credstore" provider="credstoressp">
   <property name="location"  value="myCredStorePath"/>
</serviceInstance>

• jps.credstore.migration
  

The following sections describe recommendations and the settings required in typical scenarios.

Note that application credentials are not removed when you undeploy the application.

• Skipping Migrating Credentials
  
• Migrating Merging Credentials
  
• Migrating Overwriting Credentials
  

The following sections describe the values you use in the <class>, <name>, and <actions> elements within a <permission> element in the system-jazn-data.xml file:

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.

• Security Store Permission Class
  
• Credential Store Permission Class
  
• Generic Permission Class
  

You specify the credentials needed to connect and access the domain repository in the cwallet.sso file, which is configured in the jps-config.xml file. These credentials are called bootstrap credentials and are always kept in a file.

Bootstrap credentials are configured in a context named bootstrap_credstore_context:

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

where the cwallet.sso file is assumed present in the bootstrap directory.

The bootstrap.security.principal.key and bootstrap.security.principal.map properties specify the bootstrap map and key:

<serviceInstance provider="ldap.policystore.provider" name="policystore.ldap">
  ...
  <property value="bootstrapKey" name="bootstrap.security.principal.key"/>
  ...
</serviceInstance>

If the bootstrap.security.principal.map property is unspecified, then it defaults to BOOTSTRAP_JPS.

To modify or add bootstrap credentials, see modifyBootStrapCredential and addBootStrapCredential in WLST Command Reference for Infrastructure Security.