PK  Aoa,mimetypeapplication/epub+zipPK AiTunesMetadata.plist[ artistName Oracle Corporation book-info cover-image-hash 866855920 cover-image-path OEBPS/dcommon/oracle-logo.jpg package-file-hash 201957253 publisher-unique-id E10043-12 unique-id 265257119 genre Oracle Documentation itemName Oracle® Fusion Middleware Application Security Guide, 11g Release 1 (11.1.1) releaseDate 2012-03-14T12:42:53Z year 2012 PKY`[PK AMETA-INF/container.xml PKYuPK AOEBPS/apjpscfg.htm OPSS Configuration File Reference

A OPSS Configuration File Reference

This appendix describes the element hierarchy and attributes in the file that configures OPSS services. By default, this file is named jps-config.xml (for Java EE applications) or jps-config-jse.xml (for Java SE applications) and is located in the directory $DOMAIN_HOME/config/fmwconfig.

For Java SE applications, an alternative location can be specified using the system property oracle.security.jps.config.

The configuration file is used to configure the policy, credential, and identity stores, the login modules, and the audit service. For a complete example of a configuration file see Section 21.4.9, "Example of Configuration File jps-config.xml."

To configure services programmatically, see Section E.2, "Configuring OPSS Services with MBeans."

This appendix includes the following sections:

A.1 Top- and Second-Level Element Hierarchy

The top element in the file jps-config.xml is <jpsConfig>. It contains the following second-level elements:

Table A-1 describes the function of these elements. The annotations between curly braces{} indicate the number of occurrences the element is allowed. For example, {0 or more} indicates that the element can occur 0 or more times; {1} indicates that the element must occur once.

These elements are not application-specific configurations: all items in the configuration file pertain to an entire domain and apply to all managed servers and applications deployed in the domain.

Table A-1 First- and Second-Level Elements in jps-config.xml

ElementsDescription
<jpsConfig> {1}

Defines the top-level element in the configuration file.

    <property> {0 or more}

Defines names and values of properties. It can also appear elsewhere in the hierarchy, such as under the elements <propertySet>, <serviceProvider>, and <serviceInstance>.

    <propertySets> {0 or 1}
        <propertySet> {1 or more}
            <property> {1 or more}

Groups one or more <propertySet> elements so that they can referenced as a group.

    <extendedProperty> {0 or more}
        <name> {1}
        <values> {1}
            <value> {1 or more}

Defines a property that has multiple values. It can also appear elsewhere in the hierarchy, such as under the elements extendedProperty and serviceInstance.

    <extendedPropertySets> {0 or 1}
        <extendedPropertySet> {1 or more}
            <extendedProperty> {1 or more}
                <name> {1}
                <values> {1}
                    <value> {1 or more}

Groups one or more <extendedPropertySet> elements so that they can referenced a group.

    <serviceProviders> {0 or 1}
        <serviceProvider> {1 or more}
            <description> {0 or 1}
            <property> {0 or more}

Groups one or more <serviceProvider> elements, each of which defines an implementation of an OPSS service, such as a policy store provider, a credential store provider, or a login module.

    <serviceInstances> {0 or 1}
        <serviceInstance> {1 or more}
            <description> {0 or 1}
            <property> {0 or more}
            <propertySetRef> {0 or more}
            <extendedProperty> {0 or more}
                <name> {1}
                <values> {1}
                    <value> {1 or more}
            <extendedPropertySetRef> {0 or more}

Groups one or more <serviceInstance> elements, each of which configures and specifies property values for a service provider defined in a <serviceProvider> element.

    <jpsContexts> {1}
        <jpsContext> {1 or more}
            <serviceInstanceRef> {1 or more}

Groups one or more <jpsContext> elements, each of which is a collection of service instances that an application can use.


A.2 Lower-Level Elements

This section describes, in alphabetical order, the complete set of elements that can occur in under the second-level elements described in the Top- and Second-Level Element Hierarchy.


<description>

This element describes the corresponding entity (a service instance or service provider).

Parent Elements

<serviceInstance> or <serviceProvider>

Child Element

None.

Occurrence

<description> can be a child of <serviceInstance> or <serviceProvider>.

Example

The following example sets a description for a service provider.

<serviceProvider ... >
   <description>XML-based IdStore Provider</description>
   ...
</serviceProvider>

 


<extendedProperty>

This element defines an extended property in the following scenarios:

Table A-2 Scenarios for <extendedProperty>

Location in jps-config.xmlFunction

Directly under <jpsConfig>

Defines an extended property for general use. As a child of <jpsConfig>, an extended property can specify, for example, all the base DNs in an LDAP-based authenticators.

Directly under <extendedPropertySet>

Defines an extended property for general use that is part of an extended property set.

Directly under <serviceInstance>

Defines an extended property for a particular service instance.


An extended property typically includes multiple values. Use a <value> element to specify each value. Several LDAP identity store properties are in this category, such as the specification of the following values:

Parent Elements

<extendedPropertySet>, <jpsConfig>, or <serviceInstance>

Child Elements

<name> or <values>

Occurrence

<extendedProperty> can be a child of <extendedPropertySet>, <jpsConfig>, or <serviceInstance>.

Example

The following example sets a single value:

<extendedProperty>
   <name>user.search.bases</name>
   <values>
      <value>cn=users,dc=us,dc=oracle,dc=com</value>
   </values>
</extendedProperty>

<extendedPropertySet>

This element defines a set of extended properties. The extended property set can then be referenced by an <extendedPropertySetRef> element to specify the given properties as part of the configuration of a service instance.

Attributes

NameDescription

name              

Designates a name for the extended property set. No two <extendedPropertySet> elements may have the same name attribute setting within a configuration file.

Values: string

Default: n/a (required)


Parent Element

<extendedPropertySets>

Child Element

<extendedProperty>

Occurrence

Required within <extendedPropertySets>, one or more:

<extendedPropertySets> {0 or 1}
    <extendedPropertySet> {1 or more}
        <extendedProperty> {1 or more}
            <name> {1}
            <values> {1}
                <value> {1 or more}

<extendedPropertySetRef>

This element configures a service instance by referring to an extended property set defined elsewhere in the file.

Attributes

NameDescription

ref               

Refers to an extended property set whose extended properties are used for the service instance defined in the <serviceInstance> parent element. The ref value of <extendedPropertySetRef> must match the name value of an <extendedPropertySet> element.

Values: string

Default: n/a (required)


Parent Element

<serviceInstance>

Child Element

None.

Occurrence

Optional, zero or more.

<serviceInstances> {0 or 1}
    <serviceInstance> {1 or more}
        <description> {0 or 1}
        <property> {0 or more}
        <propertySetRef> {0 or more}
        <extendedProperty> {0 or more}
            <name> {1}
            <values> {1}
                <value> {1 or more}
        <extendedPropertySetRef> {0 or more}

<extendedPropertySets>

This element specifies a set of properties.

Parent Element

<jpsConfig>

Child Element

<extendedPropertySet>

Occurrence

Optional, zero or one.

<jpsConfig>
    <extendedPropertySets> {0 or 1}
        <extendedPropertySet> {1 or more}
            <extendedProperty> {1 or more}
                <name> {1}
                <values> {1}
                    <value> {1 or more}

<jpsConfig>

This is the root element of a configuration file.

Parent Element

None.

Child Elements

<extendedProperty>, <extendedPropertySets>, <jpsContexts>, <property>, <propertySets>, <serviceInstances>, or <serviceProviders>

Occurrence

Required, one only.

Example

<jpsConfig xmlns="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd"
    schema-major-version="11" schema-minor-version="1">
...
</jpsConfig>

 


<jpsContext>

This element declares an OPSS context, a collection of service instances common to a domain, either by referring to a set of service instances that comprise the context (typical usage), or by referring to another context. Each <jspContext> in a configuration file must have a distinct name.

Attributes

NameDescription

name

Designates a name for the OPSS context. Each context must have a unique name.

Values: string

Default: n/a (required)


Parent Element

<jpsContexts>

Child Element

<serviceInstanceRef>

Occurrence

There must be at least one <jpsContext> element under <jpsContexts>. A <jpsContext> element contains the <serviceInstanceRef> element.

<jpsContexts> {1}
    <jpsContext> {1 or more}
        <serviceInstanceRef> {1 or more}

Example

The following example illustrates the definition of two contexts; the first one, named default, is the default context (specified by the attribute default in <jpsContexts>), and it references several service instances by name.

The second one, named anonymous, is used for unauthenticated users, and it references the anonymous and anonymous.loginmodule service instances.

<serviceInstances>
...
   <serviceInstance provider="credstoressp" name="credstore">
      <description>File Based Default Credential Store Service Instance</description>
      <property name="location" value="${oracle.instance}/config/JpsDataStore/JpsSystemStore"/>
   </serviceInstance>
...
   <serviceInstance provider="anonymous.provider" name="anonymous">
      <property value="anonymous" name="anonymous.user.name"/>
      <property value="anonymous-role" name="anonymous.role.name"/>
   </serviceInstance>
...
   <serviceInstance provider="jaas.login.provider" name="anonymous.loginmodule">
      <description>Anonymous Login Module</description>
      <property value="oracle.security.jps.internal.jaas.module.anonymous.AnonymousLoginModule"
                name="loginModuleClassName"/>
      <property value="REQUIRED"
                name="jaas.login.controlFlag"/>
   </serviceInstance>
...
</serviceInstances>
...
<jpsContexts default="default">
...
   <jpsContext name="default">
      <!-- This is the default JPS context. All the mandatory services and Login Modules must be
           configured in this default context -->
      <serviceInstanceRef ref="credstore"/>
      <serviceInstanceRef ref="idstore.xml"/>
      <serviceInstanceRef ref="policystore.xml"/>
      <serviceInstanceRef ref="idstore.loginmodule"/>
      <serviceInstanceRef ref="idm"/>
   </jpsContext>
   <jpsContext name="anonymous">
       <serviceInstanceRef ref="anonymous"/>
       <serviceInstanceRef ref="anonymous.loginmodule"/>
   </jpsContext>
...
</jpsContexts>

 


<jpsContexts>

This element specifies a set of contexts.

Attributes

NameDescription

default         

Specifies the context that is used by an application if none is specified. The default value of the <jpsContexts> element must match the name of a <jpsContext> child element.

Values: string

Default: n/a (required)

Note: The default context must configure all mandatory services and login modules.


Parent Element

<jpsConfig>

Child Element

<jpsContext>

Occurrence

Required, one only.

<jpsConfig>
    <jpsContexts> {1}
        <jpsContext> {1 or more}

Example

See <jpsContext> for an example.

 


<name>

This element specifies the name of an extended property.

Parent Element

<extendedProperty>

Child Element

None

Occurrence

Required, one only.

<extendedProperty> {0 or more}
    <name> {1}
    <values> {1}
        <value> {1 or more}

Example

See <extendedProperty> for an example.

 


<property>

This element defines a property in the following scenarios:

Table A-3 Scenarios for <property>

Location in jps-config.xmlFunction

Directly under <jpsConfig>

Defines a one-value property for general use.

Directly under <propertySet>

Defines a multi-value property for general use that is part of a property set.

Directly under <serviceInstance>

Defines a property for use by a particular service instance.

Directly under <serviceProvider>

Defines a property for use by all service instances of a particular service provider.


For a list of properties, see Appendix F, "OPSS System and Configuration Properties".

Attributes

NameDescription

name  

Specifies the name of the property being set.

Values: string

Default: n/a (required)

value

Specifies the value of the property being set.

Values: string

Default: n/a (required)


Parent Elements

<jpsConfig>, <propertySet>, <serviceInstance>, or <serviceProvider>

Child Element

None.

Occurrence

Under a<propertySet>, it is required, one or more; otherwise, it is optional, zero or more.

Example

The following example illustrates a property to disable JAAS mode for authorization:

<jpsConfig ... >
   ...
   <property name="oracle.security.jps.jaas.mode" value="off"/>
   ...
</jpsConfig>

For additional examples, see <propertySet> and <serviceInstance>.

 


<propertySet>

This element defines a set of properties. Each property set has a name so that it can be referenced by a <propertySetRef> element to include the properties as part of the configuration of a service instance.

Attributes

NameDescription

name              

Designates a name for the property set. No two <propertySet> elements may have the same name within a jps-config.xml file.

Values: string

Default: n/a (required)


Parent Element

<propertySets>

Child Element

<property>

Occurrence

Required within a<propertySets>, one or more

<propertySets> {0 or 1}
    <propertySet> {1 or more}
        <property> {1 or more}

Example

<propertySets>
...
   <!-- For property that points to valid Access SDK installation directory -->
   <propertySet name="access.sdk.properties">
      <property name="access.sdk.install.path" value="$ACCESS_SDK_HOME"/>
   </propertySet>
...
</propertySets>

<serviceInstances>
...
   <serviceInstance provider="jaas.login.provider" name="oam.loginmodule">
      <description>Oracle Access Manager Login Module</description>
      <property
          value="oracle.security.jps.internal.jaas.module.oam.OAMLoginModule"
          name="loginModuleClassName"/>
      <property value="REQUIRED" name="jaas.login.controlFlag"/>
      <propertySetRef ref="access.sdk.properties"/>
   </serviceInstance>
...
</serviceInstances>

<propertySetRef>

This element configures a service instance by referring to a property set defined elsewhere in the file.

Attributes

NameDescription

ref              

Refers to a property set whose properties are used by the service instance defined in the <serviceInstance> parent element. The ref value of a <propertySetRef> element must match the name of a <propertySet> element.

Values: string

Default: n/a (required)


Parent Element

<serviceInstance>

Child Element

None.

Occurrence

Optional, zero or more.

<serviceInstances> {0 or 1}
    <serviceInstance> {1 or more}
        <description> {0 or 1}
        <property> {0 or more}
        <propertySetRef> {0 or more}
        <extendedProperty> {0 or more}
            <name> {1}
            <values> {1}
                <value> {1 or more}
        <extendedPropertySetRef> {0 or more}

Example

See <propertySet> for an example.

 


<propertySets>

This element specifies a set of property sets.

Parent Element

<jpsConfig>

Child Element

<propertySet>

Occurrence

Optional. If present, there can be only one <propertySets> element.

<jpsConfig>
    <propertySets> {0 or 1}
        <propertySet> {1 or more}
            <property> {1 or more}

Example

See <propertySet> for an example.

 


<serviceInstance>

This element defines an instance of a service provider, such as an identity store service instance, policy store service instance, or login module service instance.

Each provider instance specifies the name of the instance, used to refer to the provider within the configuration file; the name of the provider being instantiated; and, possibly, the properties of the instance. Properties include the location of the instance and can be specified directly, within the instance element itself, or indirectly, by referencing a property or a property set. To change the properties of a service instance, you can use the procedure explained in Section E.1, "Configuring OPSS Service Provider Instances with a WLST Script."

Set properties and extended properties of a service instance in the following ways:

Attributes

NameDescription

name

Designates a name for this service instance. Note that no two <serviceInstance> elements may have the same name attribute setting within a jps-config.xml file.

Values: string

Default: n/a (required)

provider

Indicates which service provider this is an instance of.

The provider value of a <serviceInstance> element must match the name value of a <serviceProvider> element.

Values: string

Default: n/a (required)


Parent Element

<serviceInstances>

Child Elements

<description>, <extendedProperty>, <extendedPropertySetRef>, <property>, or <propertySetRef>

Occurrence

Required within <serviceInstances>, one or more.

<serviceInstances> {0 or 1}
    <serviceInstance> {1 or more}
        <description> {0 or 1}
        <property> {0 or more}
        <propertySetRef> {0 or more}
        <extendedProperty> {0 or more}
            <name> {1}
            <values> {1}
                <value> {1 or more}
        <extendedPropertySetRef> {0 or more}

Examples

Example 1   

The following example illustrates the configuration of a file-based identity store service. For a file-based identity store, the subscriber name is the default realm. The example sets the lo cation using the location property.

<serviceInstances>
   <serviceInstance name="idstore.xml" provider="idstore.xml.provider">
      <!-- Subscriber name must be defined for XML Identity Store -->
      <property name="subscriber.name" value="jazn.com"/>
      <!-- This is the location of XML Identity Store -->
      <property name="location" value="./system-jazn-data.xml"/>
   </serviceInstance>
...
</serviceInstances>
Example 2   

The following example illustrates the configuration a credential store service. It uses the location property to set the location of the credential store.

<serviceInstances>
   <serviceInstance provider="credstoressp" name="credstore">
      <description>File Based Default Credential Store Service
                  Instance</description>
      <property name="location"
                value="${oracle.instance}/config/JpsDataStore/JpsSystemStore" />
   </serviceInstance>
...
</serviceInstances>
Example 3   

The following example illustrates the configuration of an LDAP-based identity store using Oracle Internet Directory:

<serviceInstance name="idstore.oid" provider="idstore.ldap.provider">
   <property name="subscriber.name" value="dc=us,dc=oracle,dc=com"/>
   <property name="idstore.type" value="OID"/>
   <property name="security.principal.key" value="ldap.credentials"/>
   <property name="security.principal.alias" value="JPS"/>
   <property name="ldap.url" value="ldap://myServerName.com:389"/>
   <extendedProperty>
      <name>user.search.bases</name>
      <values>
         <value>cn=users,dc=us,dc=oracle,dc=com</value>
      </values>
   </extendedProperty>
   <extendedProperty>
      <name>group.search.bases</name>
      <values>
         <value>cn=groups,dc=us,dc=oracle,dc=com</value>
      </values>
   </extendedProperty>
   <property name="username.attr" value="uid"/>
   <property name="groupname.attr" value="cn"/>
</serviceInstance>
Example 4   

The following example illustrates the configuration of an audit provider:

<serviceInstances>
   <serviceInstance name="audit" provider="audit.provider">
      <property name="audit.filterPreset" value="Low"/>
      <property name="audit.specialUsers" value ="admin, fmwadmin" />
      <property name="audit.customEvents" value ="JPS:CheckAuthorization,           CreateCredential, OIF:UserLogin"/>
      <property name="audit.loader.jndi" value="jdbc/AuditDB"/>
      <property name="audit.loader.interval" value="15" />
      <property name="audit.maxDirSize" value="102400" />
      <property name="audit.maxFileSize" value="10240" />      
      <property name=" audit.loader.repositoryType " value="Db" />      
   </serviceInstance>
  </serviceInstances>

See Also:


 


<serviceInstanceRef>

This element refers to service instances.

Attributes

NameDescription

ref              

Refers to a service instance that are part of the context defined in the <jpsContext> parent element. The ref value of a <serviceInstanceRef> element must match the name of a <serviceInstance> element.

Values: string

Default: n/a (required)


Parent Element

<jpsContext>

Child Element

None

Occurrence

Required within a <jpsContext>, one or more.

<jpsContexts> {1}
    <jpsContext> {1 or more}
        <serviceInstanceRef> {1 or more}

Example

See <jpsContext> for an example.

 


<serviceInstances>

This element is the parent of a <serviceInstance> element.

Parent Element

<jpsConfig>

Child Element

<serviceInstance>

Occurrence

Optional, zero or one.

<jpsConfig>
    <serviceInstances> {0 or 1}
        <serviceInstance> {1 or more}
            <description> {0 or 1}
            <property> {0 or more}
            <propertySetRef> {0 or more}
            <extendedProperty> {0 or more}
                <name> {1}
                <values> {1}
                    <value> {1 or more}
            <extendedPropertySetRef> {0 or more}

Example

See <serviceInstance> for an example.

 


<serviceProvider>

This element defines a service provider. Each provider specifies the type of the provider, such as credential store, authenticators, policy store, or login module; the name of the provider, used to refer to the provider within the configuration file; and the Java class that implements the provider and that is instantiated when the provider is created. Furthermore, the element property specifies settings used to instantiate the provider.

It specifies the following data:

Attributes

NameDescription

type

Specifies the type of service provider being declared; it must be either of the following:

CREDENTIAL_STORE

IDENTITY_STORE

POLICY_STORE

AUDIT

LOGIN

ANONYMOUS

KEY_STORE

IDM (for pluggable identity management)

CUSTOM

The implementation class more specifically defines the type of provider, such as by implementing a file-based identity store or LDAP-based policy store, for example.

Values: string (a value above)

Default: n/a (required)

name

Designates a name for this service provider. This name is referenced in the provider attribute of <serviceInstance> elements to create instances of this provider. No two <serviceProvider> elements may have the same name attribute setting within a configuration file.

Values: string

Default: n/a (required)

class

Specifies the fully qualified name of the Java class that implements this service provider (and that is instantiated to create instances of the service provider).

Values: string

Default: n/a (required)


Parent Element

<serviceProviders>

Child Elements

<description> or <property>

Occurrence

Required within the <serviceProviders> element, one or more.

<serviceProviders> {0 or 1}
    <serviceProvider> {1 or more}
        <description> {0 or 1}
        <property> {0 or more}

Examples

The following example illustrates the specification of a login module service provider:

<serviceProviders>
   <serviceProvider type="LOGIN" name="jaas.login.provider"
        class="oracle.security.jps.internal.login.jaas.JaasLoginServiceProvider">
      <description>This is Jaas Login Service Provider and is used to configure
       login module service instances</description>
   </serviceProvider>
</serviceProviders>

The following example illustrates the definition of an audit service provider:

 <serviceProviders>
     <serviceProvider name="audit.provider" type="AUDIT" class="oracle.security.jps.internal.audit.AuditProvider">
     </serviceProvider>
    </serviceProviders>

See <serviceInstance> for other examples.

 


<serviceProviders>

This element specifies a set of service providers.

Parent Element

<jpsConfig>

Child Element

<serviceProvider>

Occurrence

Optional, one only.

<jpsConfig>
    <serviceProviders> {0 or 1}
        <serviceProvider> {1 or more}
            <description> {0 or 1}
            <property> {0 or more}

Example

See <serviceProvider> for an example.

 


<value>

This element specifies a value of an extended property, which can have multiple values. Each <value> element specifies one value.

Parent Element

<values>

Child Element

None.

Occurrence

Required within <values>, one or more.

    <extendedProperty> {0 or more}
        <name> {1}
        <values> {1}
            <value> {1 or more}

Example

See <extendedProperty> for an example.

 


<values>

This element is the parent element of a <value> element.

Parent Element

<extendedProperty>

Child Element

<value>

Occurrence

Required within <extendedProperty>, one only.

<extendedProperty> {0 or more}
    <name> {1}
    <values> {1}
        <value> {1 or more}

Example

See <extendedProperty> for an example.

 

PK,{'PK AOEBPS/cover.htmO Cover

Oracle Corporation

PK[pTOPK AOEBPS/audintro.htmn Introduction to Oracle Fusion Middleware Audit Framework

12 Introduction to Oracle Fusion Middleware Audit Framework

In Oracle Fusion Middleware 11g Release 1 (11.1.1), auditing provides a measure of accountability and answers the "who has done what and when" types of questions. This chapter introduces auditing in Oracle Fusion Middleware. It contains the following topics:

12.1 Benefits and Features of the Oracle Fusion Middleware Audit Framework

This section contains these topics:

12.1.1 Objectives of Auditing

With compliance becoming an integral part of any business requirement, audit support is also becoming a focus in enterprise deployments. Customers are looking for application vendors to provide out-of-the-box audit support. In addition, middleware customers who are deploying custom applications would like to centralize the auditing of their deployed applications wherever audit is appropriate.

IT organizations are looking for several key audit features driven by compliance, monitoring, and analytics requirements.

Compliance

Compliance is obviously a major requirement in the enterprise. With regulations such as Sarbanes-Oxley (financial) and Health Insurance Portability and Accountability Act (healthcare), many customers must now be able to audit on identity information and user access on applications and devices. These include events like:

  • User profile change

  • Access rights changes

  • User access activity

  • Operational activities like starting and stopping applications, upgrades, and backups

This allows compliance officers to perform periodic reviews of compliance policies.

Monitoring

The audit data naturally provides a rich set of data for monitoring purpose. In addition to any log data and component metrics that are exposed, audit data can be used to create dashboards and to build Key Performance Indicators (KPIs) for alerts to monitor the health of the various systems on an ongoing basis.

Analytics

Audit data can also be used in assessing the efficacy of controls through analysis on the audit data. The data can also be used for risk analysis. Based on historical data, a risk score can be calculated and assigned to any user. Any runtime evaluation of user access can include the various risk scores as additional criteria to protect access to the systems.

12.1.2 Today's Audit Challenges

To satisfy the audit requirements, IT organizations often battle with the deficiencies in audit support for their deployed applications. There is no reliable standard for:

  • Audit Record Generation

  • Audit Record Format and Storage

  • Audit Policy Definition

As a result, today's audit solutions suffer from a number of key drawbacks:

  • There is no centralized audit framework.

  • The quality of audit support is inconsistent from application to application.

  • Audit data is scattered across the enterprise.

  • Complex data correlation is required before any meaningful cross-component analysis can be conducted.

  • Audit policies and their configurations are also scattered.

These factors are costing IT organization considerable amount of time and resources to build and maintain any reasonable audit solutions. With the data scattered among individual silos, and the lack of consistency and centralization, the audit solutions also tend to be fragile with idiosyncrasies among applications from different vendors with their current audit capabilities.

12.1.3 Oracle Fusion Middleware Audit Framework in 11g

Oracle Fusion Middleware Audit Framework, introduced in11g Release 1 (11.1.1), is designed to provide a centralized audit framework for the middleware family of products. The framework provides audit service for the following:

  • Middleware Platform - This includes Java components such as Oracle Platform Security Services (OPSS) and Oracle Web Services. These are components that are leveraged by applications deployed in the middleware. Indirectly, all the deployed applications leveraging these Java components will benefit from the audit framework auditing events that are happening at the platform level.

  • Java EE applications - The objective is to provide a framework for Java EE applications, including Oracle's own Java EE-based components. Java EE applications are able to create application-specific audit events.

  • System Components - For system components in the middleware that are managed by Oracle Process Manager and Notification Server, the audit framework also provides an end-to-end structure similar to that for Java components.


See Also:

Understanding Key Oracle Fusion Middleware Concepts in the Oracle Fusion Middleware Administrator's Guide.


12.2 Overview of Audit Features

Key features of the Oracle Fusion Middleware Audit Framework include:

12.3 Oracle Fusion Middleware Audit Framework Concepts

This section introduces basic concepts of the Oracle Fusion Middleware Audit Framework:

12.3.1 Audit Architecture

The Oracle Fusion Middleware Audit Framework consists of the following key components:

  • Audit APIs

    These are APIs provided by the audit framework for any audit-aware components integrating with the Oracle Fusion Middleware Audit Framework. During runtime, applications may call these APIs where appropriate to audit the necessary information about a particular event happening in the application code. The interface allows applications to specify event details such as username and other attributes needed to provide the context of the event being audited.

  • The audit framework provides these APIs:

    • audit service API

    • audit client API

  • Audit Events and Configuration

    The Oracle Fusion Middleware Audit Framework provides a set of generic events for convenient mapping to application audit events. Some of these include common events such as authentication. The framework also allows applications to define application-specific events.

    These event definitions and configurations are implemented as part of the audit service in Oracle Platform Security Services. Configurations can be updated through Enterprise Manager (UI) and WLST (command-line tool)

  • The Audit Bus-stop

    Bus-stops are local files containing audit data records before they are pushed to the audit data store. In the event that no audit data store is configured, audit data remains in these bus-stop files. The bus-stop files are simple text files that can be queried easily to look up specific audit events. When an audit data store is in place, the bus-stop acts as an intermediary between the component and the audit data store. The local files are periodically uploaded to the audit data store based on a configurable time interval.

    A key advantage of the audit data store is that audit data from multiple components can be correlated and combined in reports, for example, authentication failures in all middleware components, instances and so on.

  • Audit Loader

    As its name implies, the audit loader loads audit data from the audit bus-stop into the audit data store, if one is configured. For Java component auditing, the audit loader is is a startup class that is started as part of the container start-up. For system components, the audit loader is a periodically spawned process that is invoked by OPMN.

  • Audit Data Store

    The audit data store is a database that contains a pre-defined Oracle Fusion Middleware Audit Framework schema, created by Repository Creation Utility (RCU). Once configured, all the audit loaders are aware of the audit data store and upload data to it periodically. The audit data in the store is expected to be cumulative and will grow overtime. Ideally, this should not be an operational database used by any other applications - rather, it should be a standalone RDBMS used for audit purposes only.

    The audit database can store audit events generated by Oracle components as well as user applications integrated with the audit framework.

  • Audit Metadata Store

    The audit metadata store contains audit event definitions for components and applications.

  • Audit Configuration Mbeans

    All audit configuration is managed through audit configuration MBeans. For Java components and applications, these MBeans are present in the domain administration server and the audit configuration is centrally managed. For system components, separate MBean instances are present for every component instance. Enterprise Manager UI and command-line tools manage Audit configuration using these MBeans.

  • Oracle Business Intelligence Publisher

    The data in the audit data store is exposed through pre-defined reports in Oracle Business Intelligence Publisher. The reports allow users to drill down the audit data based on various criteria. For example:

    • Username

    • Time Range

    • Application Type

    • Execution Context Identifier (ECID)

    You can also use Oracle Business Intelligence Publisher to create your own audit reports.

Figure 12-1 Audit Event Flow

Surrounding text describes Figure 12-1 .

Audit Flow

The process can be illustrated by looking at the actions taken in the framework when an auditable event (say, login) occurs within an application server instance:


Note:

The architecture shown in Figure 12-1 contains an audit data store; if your site did not configure an audit data store, the audit records reside in the bus-stop files.


  1. During application deployment or audit service start-up, a client such as a Java EE application or Oracle component registers with the audit service.

  2. The service reads the application's pre-configured audit definition file and updates the metadata store with the audit definitions.

  3. When a user accesses the component or application, an audit API function is called to audit the event.

  4. The audit framework checks if events of this type, status, and with certain attributes need to be audited.

  5. If so, the audit function is invoked to create the audit event structure and collect event information like the status, initiator, resource, ECID, and so on.

  6. The event is stored on a local file in an intermediate location known as the bus-stop; each component has its own bus-stop.

  7. If a database is configured for an audit store, the audit loader pulls the events from the bus-stops, uses the application's metadata to format the data, and moves the data to the audit store.

  8. Reports can also be generated from the audit data using Oracle BI Publisher. A set of pre-defined reports are available. (See Chapter 14, "Using Audit Analysis and Reporting".)

Application Behavior in Case of Audit Failure

It is important to note that an application does not stop execution if it is unable to record an audit event for any reason.

12.3.2 Key Technical Concepts

This section introduces key concepts in the Oracle Fusion Middleware Audit Framework.

Audit-Aware Components

The term "audit-aware" refers to components that are integrated with the Oracle Fusion Middleware Audit Framework so that audit policies can be configured and events can be audited for those components. Oracle Internet Directory is an example of an audit-aware component.

Stand-alone applications can integrate with the Oracle Fusion Middleware Audit Framework through configuration with the jps-config.xml file. For details, see see Chapter 28.

Audit Metadata Store

The audit metadata store contains audit event definitions for components as well as applications integrated with the audit framework.

Audit Data Store

The audit data store is the repository for audit event data.


Note:

The metadata store is separate from the audit data store.


Audit Loader

The Audit Loader is a module of the Oracle WebLogic Server instance and provides process control for that instance. The audit loader is responsible for collecting the audit records for all components running in that instance and loading them to the audit data store.

Audit Policy

An audit policy is a declaration of the type of events to be captured by the audit framework for a particular component. For Java components, the audit policy is defined at the domain level. For system components, the audit policy is managed at the component instance level.

Oracle Fusion Middleware Audit Framework provides several pre-defined policy types:

  • None

  • Low (audits fewer events, definition is component-dependent)

  • Medium (audits many events, definition is component-dependent)

  • Custom (implements filters to narrow the scope of audited events)

Audit Policy Component Type

This refers to the component type to be audited; for example, Oracle Internet Directory is a source of auditable events during authentication.

For lists of the events that can be audited for each component, see Section C.1, "Audit Events".

Event Filters

Certain audit events implement filters to control when the event is logged. For example, a successful login event for the Oracle Internet Directory component may be filtered for specific users.

For details, see Section 13.3, "Managing Audit Policies".

Oracle Platform Security Services

Oracle Platform Security Services, a key component of the Oracle Fusion Middleware 11g, is the Oracle Fusion Middleware security implementation for Java features such as Java Authentication and Authorization Service (JAAS) and Java EE security.

For more information about OPSS, see Section 1.1, "What is Oracle Platform Security Services?".

12.3.3 Audit Metadata Storage

Audit metadata refers to information about audit events, their attributes and categories.

For details, see Chapter 28.

12.3.4 Audit Data Storage

As shown in Figure 12-1, audit data can reside in two types of storage:

  • bus-stop files for intermediate storage of audit data. Each component instance writes to its own bus-stop.

    Bus-stop files are the default out-of-the-box storage mechanism for audit records:

    • For Java components, there is one bus-stop for each Oracle WebLogic Server instance. Audit records generated for all Java EE components running in a given Oracle WebLogic Server instance are stored in the same bus-stop.

    • For system components, there is a separate bus-stop for each component; thus, for example, each instance of Oracle Internet Directory has its own bus-stop.

    Bus-stop files are text-based and easy to query. For further details, see Section 12.3.1, "Audit Architecture"

  • permanent storage in a database; this is known as the audit data store.

    If using a database, audit records generated by all components in all Oracle Fusion Middleware 11g instances in the domain are stored in the same store. You must use an audit data store to utilize Oracle Business Intelligence Publisher reports.

You can move from file-based storage to an audit data store. This requires a specific configuration procedure. See Section 13.2.3, "Configure a Database Audit Data Store for Java Components" for details.

Advantages of Using a Database Store

Having the audit records in the bus-stop files has some practical limitations:

  • you cannot view domain-level audit data

  • reports cannot be run on Oracle BI Publisher

Thus, there are certain advantages to using a database audit data store:

  • You can use Oracle Business Intelligence Publisher for reporting.

  • The database store centralizes records from all components in the domain, whereas the bus-stop stores audit records on a per-instance basis.

  • performance may be improved compared to file-based storage

For these reasons, Oracle recommends that customers switch to a database store for enhanced auditing capabilities.

12.3.5 Analytics

With Oracle Fusion Middleware 11g, you can utilize Oracle Business Intelligence as a full-featured tool for structured reporting.

A large number of pre-defined reports are available, such as:

  • Users created/deleted

  • User transactions

  • Authentication and authorization failures

  • Policy violations

With Oracle Business Intelligence:

  • You can select records based on criteria like username, date-time range, and so on.

    Note that Oracle Business Intelligence works with the database audit store only, and is not usable with bus-stop files.

BI Publisher page
Description of the illustration cafintro1.gif

The pre-defined audit report types available with Oracle Business Intelligence include:

  • errors and exceptions

  • operational

  • user activity

  • authentication and authorization history

  • transaction history

For further details, see Section C.2, "Pre-built Audit Reports." You can also use the audit schema details to create custom audit reports as needed.

PKZnnPK AOEBPS/whatsnew.htm], What's New in This Guide

What's New in This Guide

This chapter describes the most important changes introduced in releases 11gR1, 11gR1 PS1, 11gR1 PS2, Oracle Identity Management 11gR1, 11gR1 PS3, Oracle Identity Management 11gR1 PS1, and 11gR1 PS5.

New Features in Release 11gR1 PS5

The features introduced in release 11gR1 PS5 include the following:

Documentation updates include the following:

New Features in Oracle Identity Management 11gR1 PS1

The features introduced in Oracle Indentity Management 11gR1 PS1 include the following:

New Features in Release 11gR1 PS3

The features introduced in release 11gR1 PS3 include the following:

New Features in Oracle Identity Management 11gR1

The features introduced in Oracle Identity Management 11gR1 include the following:

Additions to This Guide

New material in this guide includes:

New Features in Release 11gR1 PS2

The features introduced in release 11gR1 PS2 include the following:

New Features in Release 11gR1 PS1

The features introduced in release 11gR1 PS1 include the following:

New Features in Release 11gR1

The single most important new feature in the 11gR1 release is the introduction of the Oracle WebLogic Server as the environment where applications run and where security is provisioned.

The features introduced in release 11gR1 include the following:

Desupported Features from 10.1.3.x

The features de-supported in release 11gR1 include the following:

Links to Upgrade Documentation

To upgrade from a previous release to the current, see any of the following documents:

PKvb,],PK AOEBPS/underjps.htmY} Introduction to Oracle Platform Security Services

1 Introduction to Oracle Platform Security Services

Oracle Platform Security Services (OPSS) is a security platform that can be used to secure applications deployed in any of the supported platforms or in standalone applications. This chapter introduces the main features of this platform in the following sections:

The scope of this document does not include Oracle Web Services security. For details about that topic, see Oracle Fusion Middleware Security and Administrator's Guide for Web Services.

For an overview of Oracle Fusion Middleware security topics, see Oracle Fusion Middleware Security Overview.

1.1 What is Oracle Platform Security Services?

OPSS provides enterprise product development teams, systems integrators, and independent software vendors with a standards-based, portable, integrated, enterprise-grade security framework for Java SE and Java EE applications.

OPSS is the underlying security platform that provides security to Oracle Fusion Middleware including WebLogic Server, Server Oriented Architecture (SOA) applications, Oracle WebCenter, Oracle Application Development Framework (ADF) applications, and Oracle Entitlement Server. OPSS is designed to be portable to third-party application servers, so developers can use OPSS as the single security framework for both Oracle and third-party environments, thus decreasing application development, administration, and maintenance costs.

OPSS provides an abstraction layer in the form of application programming interfaces (APIs) that insulate developers from security and identity management implementation details. With OPSS, developers do not need to know the details of, for example, cryptographic key management, repository interfaces, or other identity management infrastructures. Using OPSS, in-house developed applications, third-party applications, and integrated applications benefit from the same, uniform security, identity management, and audit services across the enterprise.

For OPSS-related news, including FAQs, a whitepaper, and code examples, and forum discussions, see http://www.oracle.com/technology/products/id_mgmt/opss/index.html.

1.1.1 OPSS Main Features

OPSS complies with the following standards: role-based-access-control (RBAC); Java Enterprise Edition (Java EE); and Java Authorization and Authentication Services (JAAS).

Built upon these standards, OPSS provides an integrated security platform that supports:

  • Authentication

  • Identity assertion

  • Authorization, based on fine-grained JAAS permissions

  • The specification and management of application policies

  • Secure storage and access of system credentials through the Credential Store Framework

  • Secure storage and access of keys and certificates through the Keystore Service

  • Auditing

  • Role administration and role mappings

  • The User and Role API

  • Identity Virtualization

  • Security configuration and management

  • SAML and XACML

  • Oracle Security Developer Tools, including cryptography tools

  • Policy Management API

  • Java Authorization for Containers (JAAC)

Details about a given OPSS feature functionality are found in subsequent chapters of this guide.

For details about the WebLogic Auditing Provider, see section Configuring the WebLogic Auditing Provider in Oracle Fusion Middleware Securing Oracle WebLogic Server.

1.1.2 Supported Server Platforms

OPSS is supported in the following application server platforms:

  • Oracle WebLogic Server

  • IBM WebSphere Application Server - Network Deployment (ND) 7.0

  • IBM WebSphere Application Server 7.0

This guide documents OPSS features relevant to the Oracle WebLogic Server that apply uniformly to all other platforms. Those topics that apply specifically to third-party servers are found in Oracle Fusion Middleware Third-Party Application Server Guide.

1.2 OPSS Architecture Overview

OPSS comprises the application server's security and Oracle's Fusion Middleware security. Figure 1-1 illustrates the layered architecture that combines these two security frameworks:

Figure 1-1 The OPSS Architecture

Surrounding text describes Figure 1-1 .

The top layer includes the OPSS security services; the next layer includes the service providers, and the bottom layer includes the OPSS security store with a repository of one of three kinds.

Security Services Providers

Security Services Provider Interface (SSPI) provides Java EE container security in permission-based (JACC) mode and in resource-based (non-JACC) mode, and resource-based authorization for the environment.

SSPI is a set of APIs for implementing pluggable security providers. A module implementing any of these interfaces can be plugged into SSPI to provide a particular type of security service, such as custom authentication or a particular role mapping.

For details, see section The Security Service Provider Interfaces (SSPIs) in Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server.

Oracle Platform Security Services

Java Authorization (JAZN) functionality includes the Credential Store Framework (CSF), the Common Audit Framework (CAF), Keystore Service, and other components, and combined with SSPI as Oracle Platform Security Services (OPSS).

1.2.1 Benefits of Using OPSS

The benefits that OPSS offers include the following:

  • Allows developers to focus on application and domain problems

  • Supports enterprise deployments

  • Supports several LDAP servers and SSO systems

  • Is certified on the Oracle WebLogic Server

  • Pre-integrates with Oracle products and technologies

  • Offers a consistent security experience for developers and administrators

  • Provides a uniform set of APIs for all types of applications

  • Optimizes development time by offering abstraction layers (declarative APIs)

  • Provides a simplified application security maintenance

  • Allows changing security rules without affecting application code

  • Eases the administrator's job

  • Integrates with identity management systems

  • Integrates with legacy and third-party security providers

OPSS combines SSPI and JPS to provide a framework where the application server and Oracle applications can seamlessly run in a single environment.

OPSS supports security for Java EE applications and for Oracle Fusion Middleware applications, such as Oracle WebCenter and Oracle SOA Suite.

Developers can use OPSS APIs to secure all types of applications and integrate them with other security artifacts, such as LDAP servers, RDBMS, and custom security components.

Administrators can use OPSS to deploy large enterprise applications with a small, uniform set of tools and administer all security in them. OPSS simplifies the maintenance of application security because it allows the modification of security configuration without changing the application code.

By default and out-of-the-box, Oracle WebLogic Server stores users and groups in its embedded LDAP repository. Domains can be configured, however, to use identity data in other kinds of LDAP repositories, such as Oracle Internet Directory, ActiveDirectory, Novell eDirectory, and OpenLDAP. In addition, Oracle WebLogic Server provides a generic, default LDAP authenticator that can be used with other LDAP servers not in the preceding list.

Out-of-the-box, policies and credentials are stored in file-based stores; these stores can be moved (or reassociated) to an LDAP repository backed by an Oracle Internet Directory.

Out-of-the-box, keys and certificates are stored in a file-based keystore, which can be reassociated with a database or an LDAP repository.


Note:

This guide does not attempt to describe in detail WebLogic security features; wherever specific information about SSPI is used or assumed, the reader is referred to the appropriate document.


1.3 Oracle ADF Security Overview

Oracle ADF is an end-to-end Java EE framework that simplifies development by providing out-of-the-box infrastructure services and a visual and declarative development experience.

Oracle ADF Security is based on the JAAS security model, and it uses OPSS. Oracle ADF Security supports LDAP- or file-based policy and credential stores, uses permission-based fine-grained authorization provided by OPSS, and simplifies the configuration of application security with the aid of visual declarative editors and the Oracle ADF Security wizard, all of them available in Oracle JDeveloper 11g (any reference to this tool in this guide stands for its 11g release).

Oracle ADF Security authorization allows protecting components (flows and pages), is integrated with Oracle JDeveloper at design time, and is available at run time when the application is deployed to the integrated server where testing of security features is typically carried out.

During the development of an Oracle ADF application, the authenticators are configured with the Oracle WebLogic Server Administration Console for the particular domain where the application is deployed, and the policy store is file-based and stored in the file jazn-data.xml. For deployment details, see Section 6.3.1, "Deploying to a Test Environment."

To summarize, Oracle ADF Security provides:

For related information, see Scenario 2: Securing an Oracle ADF Application.

1.4 OPSS for Administrators

Depending on the application type, the guidelines to administer application security with Oracle WebLogic Administration Console, OPSS scripts, Fusion Middleware Control, or Oracle Entitlements Server are as follows:

For details about security administration, see Chapter 5, "Security Administration."

1.5 OPSS for Developers

This section summarizes the main OPSS features typically used when securing applications, in the following scenarios:

For other use cases, see Section 19.2, "Security Integration Use Cases."

1.5.1 Scenario 1: Enhancing Security in a Java EE Application

A Java EE application can be enhanced to use OPSS APIs such as the CSF, User and Role, or Policy Management: user attributes, such as a user's email, phone, or address, can be retrieved using the Identity Governance Framework API or the User and Role API; external system credentials (stored in a wallet or in a LDAP-based store) can be retrieved using the CSF API; authorization policy data can be managed with the policy management APIs; and application keys and certificates can be managed with Keystore Service APIs.

Java EE applications, such as servlets, JSPs, and EJBs, deployed on Oracle WebLogic Server can be configured to use authentication and authorization declaratively, with specifications in the file web.xml, or programmatically, with calls to isUserInRole and isCallerInRole.

Custom authenticators include the standard basic, form, and client certification methods. Authentication between servlets and EJBs is controlled using user roles and enterprise groups, typically stored in an LDAP repository, a database, or a custom authenticators.

1.5.2 Scenario 2: Securing an Oracle ADF Application

Oracle Application Development Framework (ADF) is a Java EE development framework available in Oracle JDeveloper that simplifies the development of Java EE applications by minimizing the need to write code that implements the application's infrastructure, thus allowing developers to focus on the application features. Oracle ADF provides these infrastructure implementations as part of the Oracle JDeveloper framework, therefore enhancing the development experience with visual and declarative approaches to Java EE development.

Oracle ADF implicitly uses OPSS, and, for most part, the developer does not have to code directly to OPSS APIs; of course, the developer can nevertheless use direct calls to OPSS APIs.

Oracle ADF leverages container authentication and subsequently uses JAAS based authorization to control access to Oracle ADF resources. These authorization policies may include application-specific roles and JAAS authorization permissions. Oracle ADF connection credentials are stored securely in the credential store.

Oracle ADF and Oracle WebCenter applications deployed on Oracle WebLogic Server include WebLogic authenticators, such as the default WebLogic authenticator, and may include a single sign-on solution (Oracle Access Manager or Oracle Application Server Single Sign-On).

Usually, applications also use one or several of the following OPSS features: anonymous and authenticated role support, policy management APIs, and the Credential Store Framework.

For details about these topics, see the following sections:

For details on how to develop and secure Oracle ADF applications, see chapter 29 in Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

1.5.3 Scenario 3: Securing a Java SE Application

Most of the OPSS features that work in Java EE applications work in Java SE applications, but there are some differences, which are noted in this section.

Configuration

All OPSS-related configuration and data files are located under configuration directory in the domain home. For example, the configuration file for a Java SE environment is defined in the file jps-config-jse.xml by default installed in the following location:

$DOMAIN_HOME/config/fmwconfig/jps-config-jse.xml

To specify a different location, use the following switch:

-Doracle.security.jps.config=pathToConfigFile

The syntax of this file is identical to that of the file jps-config.xml. This file is used by code running in WebLogic containers. For details, see Appendix A, "OPSS Configuration File Reference."

For details about security configuration for Java SE applications, see Section 22.2, "Authentication for Java SE Applications," and Section 23.1, "Configuring Policy and Credential Stores in Java SE Applications."

Required JAR in Class Path

To make OPSS services available to a Java SE application, ensure that the following JAR file is added to your class path, located in the modules area of the Oracle installation home:

$ORACLE_HOME/oracle_common/modules/oracle.jps_11.1.1/jps-manifest.jar

Login Modules

Java SE applications can use standard JAAS login modules. However, to use the same login module on WLS, implement a custom authentication provider that invokes the login module. The SSPI interfaces allow integrating custom authentication providers in WLS.

The login module recommended for Java SE applications is the IdentityStore login module.

For details, see section Authentication Providers in Oracle Fusion Middleware Developing Security Providers for Oracle WebLogic Server.

PK Configuring Single Sign-On with Oracle Access Manager 11g

16 Configuring Single Sign-On with Oracle Access Manager 11g

The chapter provides information on configuring single sign-on using Oracle Access Manager 11g. It includes the following major sections:

16.1 Introduction to Oracle Access Manager 11g SSO

Oracle Access Manager 11g is part of Oracle's enterprise class suite of security products. Intended for use in new and existing SSO deployments, Oracle Access Manager 11g provides a full range of Web perimeter security functions that include Web single sign-on; authentication and authorization; policy administration, and more.

Oracle Access Manager 11g single sign-on (SSO) and single log-out (SLO) supports a variety of application platforms including:

  • SOA

  • WebCenter

Oracle Access Manager 11g supports integration with a variety of applications, as described in the Oracle Fusion Middleware Integration Guide for Oracle Access Manager.

  • Oracle Identity Navigator

  • Oracle Identity Federation

  • Oracle Identity Manager

  • Oracle Adaptive Access Manager

As described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service, Oracle Access Manager 11g differs from Oracle Access Manager 10g in that identity administration features have been transferred to Oracle Identity Manager 11g. This includes user self-service and self registration, workflow functionality, dynamic group management, and delegated identity administration.

Console Protection for Oracle Identity Management Applications

Oracle Access Manager 11g and other Oracle Identity Management applications are deployed in a WebLogic container. Individual administration consoles include Oracle Access Manager, Oracle Adaptive Access Manager, Oracle Identity Navigator, Oracle Identity Manager, Oracle WebLogic Server, and Oracle Entitlements Server.

These are protected by default using pre-configured Authentication Providers in the WebLogic Administration Console and a pre-registered IAMSuiteAgent with Oracle Access Manager 11g. OAM 11g SSO policies are pre-seeded. No further configuration is needed for the consoles.

Preview of OAM 11g Deployments

You can configure Oracle Access Manager in a new WebLogic administration domain or in an existing WebLogic administration domain using the Oracle Fusion Middleware Configuration Wizard.

See "Requirements for the Provider with Oracle Access Manager"

Oracle Access Manager 11g provides new server-side components that maintain backward compatibility with new or existing policy-enforcement agents. Dynamic Server-initiated updates are performed for any policy or configuration changes.

  • Oracle Access Manager Console (installed on WebLogic Administration Server) replaces the OAM 10g Policy Manager

  • OAM Server (installed on a WebLogic Managed Sever; replaces the OAM 10g Access Server)

Oracle Access Manager 11g provides single sign-on (SSO), authentication, authorization, and other services to registered Agents (in any combination) protecting resources:

  • 11g WebGates

  • 10g WebGates

  • Java-based IAMSuiteAgent

  • OSSO Agents (10g mod_osso)

You can integrate with Oracle Access Manager 11g, any Web applications currently using Oracle ADF Security and the OPSS SSO Framework.

Only users with sufficient privileges can log in to the Oracle Access Manager Administration Console or use OAM administrative command-line tools. Your enterprise might require independent sets of administrators: one set of users responsible for OAM administration and a different set for WebLogic administration. For more information, see "Defining a New OAM Administrator Role" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

Overview of OAM 11g

The following outlines some of the basic features of Oracle Access Manager 11g:

Provisioning/Remote Registration: A new remote registration tool enables administrators inside or outside the network to register agents and policies. A username and password must be set in the primary User Identity Store for OAM 11g.

Authentication: Oracle Access Manager 11g application domains aggregate resources and security policies (one policy per resource). Oracle Access Manager 11g authentication policies include a specific scheme. Supported authentication modules include LDAP, X.509, and Kerberos. Authentication user mapping is performed against the primary user-identity provider by the centralized credential collector.

Authorization: Oracle Access Manager 11g performs authorization based on security policies defined in the application domain and persisted in the database. Authorization policies define the resource and constraint evaluation.

Responses: Administrators can set session attributes using authentication and authorization Responses. Aside from session attributes, a Response can also obtain user-related data and request-related data. Responses, once set, are then sent as either HTTP Headers or Cookies to the agent that helps manifest them. For cookie values and header variables, Responses can retrieve session attributes previously set by another Response. For example, session attributes set by a Response upon authentication can be retrieved as a header value during authorization.

Session Management: Oracle Access Manager 11g session management services track active user sessions through a high performance distributed cache system based on technology from Oracle Coherence. Each Oracle Access Manager runtime instance is a node within the distributed cache system. Secure communication between the nodes is facilitated using a symmetric key. The Oracle Access Manager runtime instances move user session data in the local cache into the distributed cache for other nodes to pick up. Each Oracle Access Manager runtime instance can also configure the replication factor and determine how session data is distributed. Administrators can configure the session lifecycle, locate and remove specific active sessions, and set a limit on the number of concurrent sessions a user can have at any time. Out-of-band session termination prevents unauthorized access to systems when a user has been terminated.

Keys: The Oracle Access Manager 11g runtime is deployed as an application to a WebLogic Managed Server or Cluster. New Oracle Access Manager 11g WebGates support a shared secret per agent trust model. 11g WebGates use agent/host specific cookies, which offers superior security. Oracle Access Manager 11g WebGates are all trusted at the same level; a cookie specific for the WebGate is set and cannot be used to access any other WebGate-protected applications on a user's behalf. Cookie-replay types of attacks are prevented.

SSO and SLO: The Oracle Access Manager 11g Server Session Token forms the basis for SSO between Oracle Access Manager and OSSO Agents. Logout is driven through Oracle Access Manager 11g Server Global Logout, which terminates the central session and logs out the user from each agent that was visited.

  • With Oracle Access Manager 10g WebGates, logout removes the ObSSOCookie and then redirects to the Global Logout page.

  • With Oracle Access Manager 11g WebGates and mod_osso agents, logout redirects to the Global Logout page and each agent is called back to remove the agent-specific cookie.

Logging and Auditing: Oracle Access Manager 11g components use the same logging infrastructure and guidelines as any other component in Oracle Fusion Middleware 11g. Oracle Access Manager 11g provides agent and server monitoring functions. Oracle Access Manager 11g auditing functions are based on the Common Audit Framework; audit-report generation is supported using Oracle Business Intelligence Publisher.

Access Tester: The new Oracle Access Manager 11g Access Tester enables IT professionals and administrators to simulate interactions between registered Oracle Access Manager Agents and Servers. This is useful when testing security policy definitions or troubleshooting issues involving agent connections.

Transition from Test to Production: Oracle Access Manager 11g enables moving configuration or policy data from one Oracle Access Manager 11g deployment to another (from a small test deployment to a production deployment, for example). Support for the creation of new topologies is based on templates. You can also copy and move policy changes.

Co-existence and Upgrades for OSSO 10g: The Oracle-provided Upgrade Assistant scans the existing OracleAS 10g SSO server configuration, accepts as input the 10g OSSO policy properties file and schema information, and transfers configured partner applications into the destination Oracle Access Manager 11g SSO.


See Also:


16.1.1 Previewing Pre-Seeded OAM 11g Policies for Use by the 10g AccessGate

This topic is required for only 10g custom AccessGates. Skip this topic if it does not apply to your environment.

The Application Authenticator application domain is delivered with OAM 11g. It is pre-seeded with the policy objects that enables integration with applications deployed in WebLogic environments using the OAM Authentication Provider as the security provider. It is not associated with WebGate provisioning. When you provision a WebGate or AccessGate to use this (or another existing application domain), you will decline having policies created automatically.

The Application Authenticator application domain comes into play with the custom 10g AccessGate used with the OAM Authenticator (and the Identity Asserter for Oracle Web Services Manager). In this case, the custom AccessGate (not WebGate) contacts the WebLogic Server directly with a token to authenticate the user before OAM 11g is contacted.

The Application Authenticator application domain protects only resources of type wl_authen and is seeded with two authentication policies and one authorization policy. The following wl_authen resources are also seeded in this domain:

  • /Authen/Basic

  • /Authen/SSOToken

  • /Authen/UsernameAssertion protected by LDAPNoPasswordValidationScheme


Note:

Only resources of type wl_authen are allowed in this domain; no other resource types can be added. Policies and Responses for wl_authen resources can be added. However, ideally, you will not need to modify this domain.


Figure 16-1 illustrates details of the seeded Application Authenticator application domain in the OAM 11g Administration Console. The page shown describes the pre-seeded User ID Assertion authentication policy, which protects the /Authen/UsernameAssertion resource. The authentication scheme for this policy is also shown along with the resources that are protected by the policy.

Figure 16-1 Pre-seeded Resources in the User ID Assertion Authentication Policy

Surrounding text describes Figure 16-1 .

Figure 16-2 illustrates pre-seeded Responses for the User ID Assertion authentication policy. For more information about Responses, see the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

Figure 16-2 Pre-seeded Responses in the User ID Assertion Policy

Surrounding text describes Figure 16-2 .

Figure 16-3 illustrates the pre-seeded Application SSO authentication policy, the resources protected by this policy, and the authentication scheme.

Figure 16-3 Pre-seeded Application SSO Authentication Policy and Resources

Surrounding text describes Figure 16-3 .

Figure 16-4 illustrates Pre-seeded Responses for the Application SSO authentication policy in the application domain.

Figure 16-4 Pre-seeded Responses for the Application SSO Authentication Policy

Surrounding text describes Figure 16-4 .

Figure 16-5 illustrates the pre-seeded Application SSO authorization policy and Resources in the application domain.

Figure 16-5 Pre-seeded Application SSO Authorization Policy and Resources

Surrounding text describes Figure 16-5 .

Authorization Constraints: There are no pre-seeded Application SSO authorization policy Constraints in this application domain. However, you can add constraints as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

Authorization Responses: There are no pre-seeded Application SSO authorization policy Responses in the application domain. However, you can add responses as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

16.2 Deploying the Oracle Access Manager 11g SSO Solution

This section introduces how to implement OAM 11g with the Authentication Provider when you have applications that are (or will be) deployed in a WebLogic container.

This section provides the following topics to help you implement OAM 11g SSO when you have applications deployed in a WebLogic container. Aside from these uniquely OAM 11g methods, implementing OAM solutions are the same whether you have OAM 11g or OAM 10g:


See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service for details about the scenario for Identity Propagation with the OAM Token.


16.2.1 Installing the Authentication Provider with Oracle Access Manager 11g

The following overview outlines the tasks that must be completed to install the required components and files for the Oracle Access Manager 11g SSO solution using the Authentication Provider. While many of these tasks are nearly the same for Oracle Access Manager 11g and Oracle Access Manager 10g, there are a few differences.


See Also:

Oracle Fusion Middleware Installation Guide for Oracle Identity Management for installation and initial configuration details for Oracle Access Manager 11g.


Task overview: Installing components for use with the Authentication Provider and OAM 11g

  1. Install and set up Oracle Internet Directory for Oracle Access Manager.

  2. Install and set up Oracle WebLogic Server 10.3.1+.

  3. Optional: Install a Fusion Middleware product (Oracle Identity Manager, Oracle SOA Suite, or Oracle Web Center for example):


    Note:

    Without a Fusion Middleware application, you must acquire the required JAR and WAR files as described in later procedures.


  4. Install OHS 11g for the Oracle Access Manager WebGate, if needed:

    • Identity Asserter: Requires Oracle HTTP Server 11g Web server configured as a reverse proxy in front of Oracle WebLogic Server.

      WebGate: For identity assertion with the OAM Identity Asserter, a perimeter Webgate is required (installed and configured) on the OHS Web Server.

    • Authenticator or Oracle Web Services Manager: No Web server is required for the custom AccessGate. The protected resource is accessed using its URL on the Oracle WebLogic Server.

  5. Authentication Provider Files: Confirm the required JAR and WAR files as follows:

    1. Confirm the location of required JAR files in the following Fusion Middleware path:

      ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamAuthnProvider.jar
      
    2. Locate the console-extension WAR file in the following path:

      ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprov 
      ider.war
      
    3. Copy the WAR file to the following path in the WebLogic Server home:

      WL_HOME/server/lib/console-ext/autodeploy/oamauthenticationprovider.war
      
  6. Oracle Access Manager 11g:

    1. Install Oracle Access Manager and perform initial configuration as described in Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

    2. Trusted Header Assertion: Go to My Oracle Support, retrieve Bundle Patch 02 (Oracle Access Manager Bundle Patch 11.1.1.5.2), and apply it as described in the companion readme file: http://support.oracle.com.

  7. AccessGate for the Authenticator (or for Oracle Web Services Manager):

16.2.2 Converting Oracle Access Manager Certificates to Java Keystore Format

Oracle recommends that all Java components and applications use JKS as the keystore format. This topic provides steps to convert Oracle Access Manager X.509 certificates to Java Keystore (JKS) format. These steps, when followed properly, generate the JKS stores that can be used while the Java NAP client wants to communicate with an OAM Server in Simple or Cert (certificate) mode.


Note:

This procedure is required regardless of the SSO mechanism you choose.


When communicating in Simple or Cert mode, the OAM Server uses a key, server certificate, and CA chain files:

  • aaa_key.pem: the random key information generated by the certificate-generating utilities while it sends a request to a Root CA. This is your private key. The certificate request for WebGate generates the certificate-request file aaa_req.pem. You must send this WebGate certificate request to a root CA that is trusted by the OAM Server. The root CA returns the WebGate certificates, which can then be installed either during or after WebGate installation.

  • aaa_cert.pem: the actual certificate for the OAM Server, signed by the Root CA.

  • aaa_chain.pem: the public certificate of the Root CA. This is used when peers communicating in Simple or Cert mode perform an SSL handshake and exchange their certificates for validity. In Simple Mode, the aaa_chain.pem is the OpenSSL certificate located inOAMServer_install_dir/access/oblix/tools/openssl/simpleCA/cacert.pem

Here, aaa is the name you specify for the file (applicable only to Cert and chain files).

You can edit an existing certificate with a text editing utility to remove all data except that which is contained within the CERTIFICATE blocks. You then convert the edited certificate to JKS format, and import it into the keystore. Java KeyTool does not allow you to import an existing Private Key for which you already have a certificate. You must convert the PEM format files to DER format files using the OpenSSL utility.

To convert an Oracle Access Manager certificate to JKS format and import it

  1. Install and configure Java 1.6 or the latest version.

  2. Copy the following files before editing to retain the originals:

    • aaa_chain.pem

    • aaa_cert.pem

    • cacert.pem, only if configuring for Simple mode

  3. Edit aaa_chain.pem using TextPad to remove all data except that which is contained within the CERTIFICATE blocks, and save the file in a new location to retain the original.

    -----BEGIN CERTIFICATE-----
    ...
    CERTIFICATE
    ...
    -----END CERTIFICATE-----
    
  4. Run the following command for the edited aaa_chain.pem:

    JDK_HOME\bin\keytool" -import -alias root_ca -file aaa_chain.pem -keystore 
    rootcerts
    

    Here you are assigning an alias (short name) root_ca to the key. The input file aaa_chain.pem is the one that you manually edited in step 3. The keystore name is rootcerts.

    You must give a password to access the keys stored in the newly created keystore.


    Note:

    To ensure security, Oracle recommends that you allow the keytool to prompt you to enter the password. This prompt occurs automatically when the "-storepass" flag is omitted from the command line.


  5. Enter the keystore password, when asked. For example:

    Enter keystore password: <keystore_password>
    Re-enter new keystore password: <keystore_password>
    
  6. Enter Yes when asked if you trust this tool:

    Trust this certificate? [no]: yes
    
  7. Confirm that the certificate has been imported to the JKS format by executing the following command and then the password.

    JDK_HOME\bin\keytool" -list -v -keystore "rootcerts"
    Enter keystore password: <keystore_password>
    
  8. Look for a response like the following:

    Keystore type: JKS
    Keystore provider: SUN
    Your keystore contains n entries
    Alias name: root_ca
    Creation date: April 19, 2009
    Entry type: trustedCertEntry
    
    Owner: CN=NetPoint Simple Security CA - Not for General Use, OU=NetPoint, 
    O="Oblix, Inc.", L=Cupertino, ST= California , C=US
    
    Issuer: CN=NetPoint Simple Security CA - Not for General Use, OU=NetPoint, 
    O="Oblix, Inc.", L=Cupertino, ST= California ,C=US
    
    Serial number: x
    Valid from: Tue Jul 25 23:33:57 GMT+05:30 2000 until: Sun Jul 25 23:33:57
    GMT+05:30 2010
    
    Certificate fingerprints
      MD5:  CE:45:3A:66:53:0F:FD:D6:93:AD:A7:01:F3:C6:3E:BC
      SHA1: D6:86:9E:83:CF:E7:24:C6:6C:E1:1A:20:28:63:FE:FE:43:7F:68:95
      Signature algorithm name: MD5withRSA
      Version: 1
    *******************************************
    
  9. Repeat steps 3 through 7 for the other PEM files (except aaa_chain.pem unless there is a chain).

  10. Convert the aaa_key.pem file to DER format using the OpenSSL utility in the OAM Server installation directory path. For example:

    OAM_Server_HOME\access\oblix\tools\openssl>openssl pkcs8 -topk8  
    -nocrypt -in aaa_key.pem -inform PEM -out aaa_key.der –outform DER 
    

    Here the input file is aaa_key.pem and the output file is aaa_key.der. Additional options include:

    Table 16-1 Options to Create DER Format Files from PEM

    OptionDescription

    -topk8

    Reads a traditional format private key and writes a PKCS#8 format key. This reverses the default situation where a PKCS#8 private key is expected on input and a traditional format private key is written.

    -nocrypt

    An unencrypted PrivateKeyInfo structure is expected for output.

    -inform

    Specifies the input format. If a PKCS#8 format key is expected on input, then either a DER or PEM encoded version of a PKCS#8 key is expected. Otherwise the DER or PEM format of the traditional format private key is used.

    -outform

    Specifies the output format. If a PKCS#8 format key is expected on output, then either a DER or PEM encoded version of a PKCS#8 key is expected. Otherwise the DER or PEM format of the traditional format private key is used.


  11. Simple or Cert Mode: In the PEM file (in this case, aaa_cert.pem), enter the pass phrase for the OAM Server if it is configured for Simple or Cert mode.

    Passphrase for the certificate
    
  12. Run the following command to convert the aaa_cert.pem file to DER format.

    AccessServer_install_dir\access\oblix\tools\openssl>openssl x509 -in  
    aaa_cert.pem -inform PEM -out aaa_cert.der -outform DER
    
  13. Import the DER format files into a Java keystore using the ImportKey utility. For example:

    Java_install_dir\doc>java -Dkeystore=jkscerts ImportKey aaa_key.der   
    aaa_cert.der
    
  14. Review the results in the window, which should look something like the following example:

    Using keystore-file : jkscerts
    One certificate, no chain
    Key and certificate stored
    Alias:importkey  Password:your_password 
    

16.2.3 Session Token: Provisioning an OAM Agent with Oracle Access Manager 11g

This task is required for only the session token mechanism (ObSSOCookie). If you are implementing either a trusted header assertion or clear text header mechanism, skip this topic.

Provisioning is the process of registering an agent and creating an application domain to use OAM 11g authentication and authorization services.You must provision a WebGate with OAM 11g whether you are preparing to install a fresh 11g or 10g instance or you have a legacy 10g WebGate installed.

The term WebGate is used for WebGates (and for the custom 10g AccessGates used with the Authenticator and the Identity Asserter for Oracle Web Services Manager). Unless explicitly stated, topics apply equally to both.

When you have multiple agents, each one can be provisioned independently or you can use a single OAM Agent registration for multiple agents.


Note:

The Application Authenticator application domain is pre-seeded and delivered with OAM 11g. When you provision an OAM Agent to use this (or another existing) application domain, decline the option of having policies automatically created.


The following topics are provided:

16.2.3.1 About WebGate Provisioning Methods for Oracle Access Manager 11g

This task is required for only the session token mechanism (ObSSOCookie). If you are implementing either a trusted header or clear text header mechanism, skip this topic.

Table 16-2 outlines the methods and tools you can use to provision WebGates for use with OAM 11g. The remote registration tool enables you to specify a small amount or all WebGate parameters using templates.

Table 16-2 Provisioning Methods for OAM 11g

MethodDescription

Oracle Access Manager Administration Console

Enables OAM Administrators to manually enter information and set parameters directly in Oracle Access Manager. This method is required if you are using the Authenticator, or if you have Oracle Web Services Manager policies protecting Web services.

Remote Registration

Application administrators who are implementing the Identity Asserter for single sign-on, can register the WebGate using the command line. This also creates a new application domain with security policies for a fresh or existing Web Tier.

Required parameters are provisioned using values for your environment specified in a template. Default values are accepted for non-required parameters. After registration, values can be modified in the Oracle Access Manager Console.


During remote registration, you must provide the details discussed in Table 16-3.


See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service for a complete list of WebGate parameters


Table 16-3 Required Registration Details for OAM Agents

OAM Agent ElementDescription

<serverAddress>

Points to a running instance of the Oracle Access Manager Administration Console, including the host and port.

<webDomain>

OSSO requests only

Defines the Web server domain under which the Agent Base URL is stored internally.

<agentName>

Defines a unique identifier for the agent on the OAM (Administration) Server.

For every agent on the same server instance, this tag must be unique to avoid re-registering the same agent.

Re-registering an agent on the same server instance is not supported.

<hostIdentifier>

This identifier represents the Web server host. The field is filled in automatically when you specify a value for the OAM Agent Name. If the agent name or host identifier of the same name already exists, an error occurs during registration.

<protectedResourcesList>

Specifies the resource URLs that you want the OAM Agent to protect with some authentication scheme. The resource URLs should be relative paths to the agentBaseUrl.

<publicResourcesList>

Specifies the resource URLs that you want to keep public (not protected by the OAM Agent). The resource URLs should be relative paths to the agentBaseUrl. For instance, you might want to specify the Home page or the Welcome page of your application


16.2.3.2 Provisioning a WebGate with Oracle Access Manager 11g

This task is required for only the session token mechanism (ObSSOCookie). If you are implementing either a trusted header or clear text header mechanism, skip this topic.

Provisioning a WebGate or AccessGate involves the same steps. You can provision a new instance for use with the Authentication Provider or you can refer to an existing registration when configuring the provider.

In this example, an OAM 10g WebGate is provisioned using the OAMRequest_short.xml template. The registered agent is named my-wl-agent1, protecting /.../*, and declaring a public resource, /public/index.html. Your values will be different.


Note:

When provisioning an OAM 11g WebGate, use the OAM11gRequest_short.xml template.



See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service


To provision a WebGate with OAM 11g

  1. Acquire the Tool: On the computer to host the WebGate, acquire the remote registration tool and set up the script for your environment. For example:

    1. Locate RREG.tar.gz file in the following path:

      WLS_home/Middleware/domain_home/oam/server/rreg/client/RREG.tar.gz 
      
    2. Untar RREG.tar.gz file to any suitable location. For example: rreg/bin/oamreg.

    3. In the oamreg script, set the following environment variables based on your situation (client side or server side) and information in Table 6–7 in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service:


      OAM_REG_HOME = exploded_dir_for_RREG.tar/rreg
      JDK_HOME = Java_location_on_the_computer
  2. Create the registration request:

    1. Locate the *Request_short.xml file and copy it to a new location and name. For example:

      WLS_home/Middleware/domain_home/oam/server/rreg/bin/oamreg/
      

      Copy: OAMRequest_short.xml (or OAM 11gRequest.xml)

      To: my-wl-agent1.xml

    2. Edit my-wl-agent1.xml to include details for your environment, and set automatic policy creation to false. For example:

      <OAMRegRequest>
          <serverAddress>http://sample.us.oracle.com:7001</serverAddress>
          <hostIdentifier>my-wl</hostIdentifier>
          <agentName>my-wl-agent1</agentName>
          <primaryCookieDomain>.us.example.com</primaryCookieDomain>
          <autoCreatePolicy>false</autoCreatePolicy>
          <logOutUrls><url>/oamsso/logout.html</url></logOutUrls>
      </OAMRegRequest>
      

      See Also:

      "Creating the Registration Request" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service


  3. Provision the agent. For example:

    1. Locate the remote registration script.


      Linux: rreg/bin/oamreg.sh
      Ensure the script has executable permission: chmod +x oamreg.sh

      Windows: rreg\bin\oamreg.bat

    2. From the directory containing the script, execute the script using inband mode. For example:

      $ ./bin/oamreg.sh inband input/my-wl-agent1.xml

      Welcome to OAM Remote Registration Tool!
      Parameters passed to the registration tool are:
      Mode: inband
      Filename: ...
      
    3. When prompted, enter the following information using values for your environment:

      Enter your agent username: userame
         Username:  userame
      Enter agent password: ********
      Do you want to enter a Webgate password?(y/n)
          n
      iv.Do you want to import an URIs file?(y/n)
          n
      
    4. Review the final message to confirm that this was a successful registration:

      Inband registration process completed successfully! Output artifacts are 
      created in the output folder"
      
  4. Confirm in the Console: Log in to the Oracle Access Manager Console and review the new registration:

    1. From the OAM 11g Console System Configuration tab, Access Manager Settings section, expand the SSO Agents nodes to search for the agent you just provisioned:


      Access Manager Settings
      SSO Agents
      OAM Agents
      Search
    2. In the Search Results table, click the agent's name to display the registration page and review the details, which you will use later. For example:

      Agent Name—During WebGate installation, enter this as the WebGate ID. If you deploy the custom 10g AccessGate, enter this as the AccessGate Name when configuring the OAM Authentication Provider in the WebLogic Administration Console.

      Access Client Password—During WebGate installation, enter this as the WebGate password. If no password was entered, you can leave the field blank.

      Access Server Host Name—Enter the DNS host name for the primary OAM 11g Server with which this WebGate is registered.

    3. OAM Proxy Port—From the Oracle Access Manager Console, System Configuration tab, Common Configuration section, open Server Instances and locate the port on which the OAM Proxy is running.

  5. Ignore the Obaccessclient.xml file, which is created during provisioning, for now.

  6. Proceed as needed for your environment:

16.2.4 Configuring Identity Assertion for SSO with Oracle Access Manager 11g

This section describes the unique steps needed to configure Oracle Access Manager 11g Identity Assertion for Single Sign-On with your application.

Task overview: Deploying the Identity Asserter for SSO with OAM 11g includes

  1. Finishing all prerequisite tasks for the mechanism you are implementing:

  2. Establishing Trust with Oracle WebLogic Server

  3. Configuring Providers in the WebLogic Domain

  4. Trusted Header Assertion: Configuring Digital Signature Verification

  5. Trusted Header Assertion: Configuring Policies

  6. Configuring Centralized Log Out for Oracle Access Manager 11g

  7. Synchronizing the User and SSO Sessions: SSO Synchronization Filter

  8. Testing Oracle Access Manager Identity Assertion for Single Sign-on

16.2.4.1 Establishing Trust with Oracle WebLogic Server

The following topics explain the tasks you must perform to set up the application for single sign-on with the Oracle Access Manager Identity Asserter.

Task overview: Establishing Trust with Oracle WebLogic Server

  1. Setting Up the Application Authentication Method for Identity Asserter for Single Sign-On

  2. Confirming mod_weblogic for Oracle Access Manager Identity Asserter

  3. Clear Text Header: Establishing Trust between Oracle WebLogic Server and Other Entities

16.2.4.1.1 Setting Up the Application Authentication Method for Identity Asserter for Single Sign-On

This topic describes how to create the application authentication method for Oracle Access Manager Identity Assertion.

When you use the Oracle Access Manager Identity Asserter, all web.xml files in the application EAR file must specify CLIENT-CERT in the element auth-method for the appropriate realm.

You can add comma separated values here when you want applications accessed directly over the WebLogic Server host:port to be authenticated by the container. For instance: <auth-method>CLIENT-CERT,FORM</auth-method>.

The auth-method can use BASIC, FORM, or CLIENT-CERT values. While these look like similar values in Oracle Access Manager, the auth-method specified in web.xml files are used by Oracle WebLogic Server (not Oracle Access Manager).

To specify authentication in web.xml for the Identity Asserter

  1. Locate the web.xml file in the application EAR file:

    my_app/WEB-INF/web.xml  
    
  2. Locate the auth-method in login-config and enter CLIENT-CERT.

    <login-config>
      <auth-method>CLIENT-CERT</auth-method>
    </login-config>
    
  3. Save the file.

  4. Redeploy and restart the application.

  5. Repeat for each web.xml file in the application EAR file.

  6. Proceed to "Confirming mod_weblogic for Oracle Access Manager Identity Asserter".

16.2.4.1.2 Confirming mod_weblogic for Oracle Access Manager Identity Asserter

Oracle Oracle HTTP Server includes the mod_weblogic plug-in module (mod_wl_ohs.so in 11g) which is already enabled. You can perform the following procedure to confirm this or skip this procedure.

With Oracle HTTP Server 11g, the mod_weblogic configuration is present in mod_wl_ohs.conf by default, and the path of this file is included in httpd.conf. If the mod_weblogic configuration is not present then you must edit httpd.conf.

To configure mod_weblogic for the Oracle Access Manager Identity Asserter

  1. Locate httpd.conf. For example:

    ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
    
  2. Confirm that the following statement is in the file with appropriate values for your deployment (add or uncomment this, if needed):

    <IfModule mod_weblogic.c>
       WebLogicHost myHost.myDomain.com
         WebLogicPort myWlsPortNumber
    </IfModule>
     
    <Location http://request-uri-pattern>
       SetHandler weblogic-handler
    </Location>
    
  3. Save the file.

  4. Proceed as needed for your implementation:

16.2.4.1.3 Clear Text Header: Establishing Trust between Oracle WebLogic Server and Other Entities

The Oracle WebLogic Connection Filtering mechanism must be configured for creating access control lists and for accepting requests from only the hosts where Oracle HTTP Server and the front-end Web server are running.


Note:

This filter is required for security when you use Identity Assertion with the Clear Text Header mechanism. This task is optional when you use one of the other mechanisms.


A network connection filter is a component that controls the access to network level resources. It can be used to protect resources of individual servers, server clusters, or an entire internal network. For example, a filter can deny non-SSL connections originating outside of a corporate network. A network connection filter functions like a firewall since it can be configured to filter protocols, IP addresses, or DNS node names. It is typically used to establish trust between Oracle WebLogic Server and foreign entities.

To configure a connection filter to allow requests from only mod_weblogic and the host where OHS 11g is running, perform the procedure here.


Note:

This chapter uses the generic name of the WebLogic Server plug-in for Apache: mod_weblogic. For Oracle HTTP Server 11g, the name of this plug-in is mod_wl_ohs; the actual binary name is mod_wl_ohs.so. Examples show exact syntax for implementation.


WebLogic Server provides a default connection filter: weblogic.security.net.ConnectionFilterImpl. This filter accepts all incoming connections and also provides static factory methods that allow the server to obtain the current connection filter. To configure this connection filter to deny access, simply enter the connection filters rules in the WebLogic Server Administration Console.

You can also use a custom connection filter by implementing the classes in the weblogic.security.net package. Like the default connection filter, custom connection filters are configured in the WebLogic Server Administration Console.

Connection Filter Rules: The format of filter rules differ depending on whether you are using a filter file to enter the filter rules or you enter the filter rules in the Administration Console. When entering the filter rules on the Administration Console, enter them in the following format:

targetAddress localAddress localPort action protocols

Table 16-4 provides a description of each parameter in a connection filter.

Table 16-4 Connection Filter Rules

ParameterDescription

target

Specifies one or more systems to filter

localAddress

Defines the host address of the WebLogic Server instance. (If you specify an asterisk (*), the match returns all local IP addresses.)

localPort

Defines the port on which the WebLogic Server instance is listening. (If you specify an asterisk, the match returns all available ports on the server.)

action

Specifies the action to perform. This value must be allow or deny

protocols

Is the list of protocol names to match. The following protocols may be specified: http, https, t3, t3s, giop, giops, dcom, ftp, ldap. If no protocol is defined, all protocols match a rule.


The Connection Logger Enabled attribute logs successful connections and connection data in the server. This information can be used to debug problems relating to server connections.


See Also:

"Configuring Security in a WebLogic Domain" in Oracle Fusion Middleware Securing Oracle WebLogic Server


To configure a connection filter to allow requests from Oracle HTTP Server host

  1. Log in to the Oracle WebLogic Administration Console.

  2. Click Domain under Domain Configurations.

  3. Click the Security tab, click the Filter tab.

  4. Click the Connection Logger Enabled attribute to enable the logging of accepted messages for use when debugging problems relating to server connections.

  5. Specify the connection filter to be used in the domain:

    • Default Connection Filter: In the Connection Filter attribute field, specify weblogic.security.net.ConnectionFilterImpl.

    • Custom Connection Filter: In the Connection Filter attribute field, specify the class that implements the network connection filter, which should also be specified in the CLASSPATH for Oracle WebLogic Server.

  6. Enter the appropriate syntax for the connection filter rules.

  7. Click Save.

  8. Restart the Oracle WebLogic Server.

  9. Proceed to "Configuring Providers in the WebLogic Domain".

16.2.4.2 Configuring Providers in the WebLogic Domain

The information here applies equally to OAM 11g and OAM 10g. This topic is divided as follows:

16.2.4.2.1 About Oracle WebLogic Server Authentication and Identity Assertion Providers

This topic introduces only a few types of Authentication Providers for a WebLogic security realm, if you are new to them.

Each WebLogic security realm must have one at least one Authentication Provider configured. The WebLogic Security Framework is designed to support multiple Authentication Providers (and thus multiple LoginModules) for multipart authentication. As a result, you can use multiple Authentication Providers as well as multiple types of Authentication Providers in a security realm. The Control Flag attribute determines how the LoginModule for each Authentication Provider is used in the authentication process.

Oracle WebLogic Server offers several types of Authentication and Identity Assertion providers including, among others:

  • The default WebLogic Authentication Provider (Default Authenticator) allows you to manage users and groups in one place, the embedded WebLogic Server LDAP server. This Authenticator is used by the Oracle WebLogic Server to login administrative users.

  • Identity Assertion uses token-based authentication; the Oracle Access Manager Identity Asserter is one example. This must be configured to use the appropriate action for the installed WebGate (either 10g or 11g).

  • LDAP Authentication Providers store user and group information in an external LDAP server. They differ primarily in how they are configured by default to match typical directory schemas for their corresponding LDAP server.

    Oracle WebLogic Server 10.3.1+ provides OracleInternetDirectoryAuthenticator.

When you configure multiple Authentication Providers, use the JAAS Control Flag for each provider to control how the Authentication Providers are used in the login sequence. You can choose the following the JAAS Control Flag settings, among others:

  • REQUIRED—The Authentication Provider is always called, and the user must always pass its authentication test. Regardless of whether authentication succeeds or fails, authentication still continues down the list of providers.

  • SUFFICIENT—The user is not required to pass the authentication test of the Authentication Provider. If authentication succeeds, no subsequent Authentication Providers are executed. If authentication fails, authentication continues down the list of providers.

  • OPTIONAL—The user is allowed to pass or fail the authentication test of this Authentication Provider. However, if all Authentication Providers configured in a security realm have the JAAS Control Flag set to OPTIONAL, the user must pass the authentication test of one of the configured providers.

When additional Authentication Providers are added to an existing security realm, the Control Flag is set to OPTIONAL by default. You might need to change the setting of the Control Flag and the order of providers so that each Authentication Provider works properly in the authentication sequence.


See Also:

"Configuring Authentication Providers" in Oracle Fusion Middleware Securing Oracle WebLogic Server for a complete list of Authentication Providers and details about configuring the Oracle Internet Directory provider to match the LDAP schema for user and group attributes


16.2.4.2.2 About the Oracle WebLogic Scripting Tool (WLST)

This topic introduces WLST, if you are new to it.

You can add providers to a WebLogic domain using either the Oracle WebLogic Administration Console or Oracle WebLogic Scripting Tool (WLST) command-line tool.

WLST is a Jython-based command-line scripting environment that you can use to manage and monitor WebLogic Server domains. Generally, you can use this tool online or offline. You can use this tool interactively on the command line in batches supplied in a file (Script Mode, where scripts invoke a sequence of WLST commands without requiring your input), or embedded in Java code.

When adding Authentication Providers to a WebLogic domain, you can use WLST online to interact with an Authentication Provider and add, remove, or modify users, groups, and roles.

When you use WLST offline to create a domain template, WLST packages the Authentication Provider's data store along with the rest of the domain documents. If you create a domain from the domain template, the new domain has an exact copy of the Authentication Provider's data store from the domain template. However, you cannot use WLST offline to modify the data in an Authentication Provider's data store.


Note:

You cannot use WLST offline to modify the data in an Authentication Provider's data store.


16.2.4.2.3 Configuring Oracle WebLogic Server for a Web Application Using ADF Security, OAM SSO, and OPSS SSO

On the Oracle WebLogic Server, you can run a Web application that uses Oracles Application Development Framework (Oracle ADF) security, integrates with Oracle Access Manager Single Sign On (SSO), and uses Oracle Platform Security Services (OPSS) SSO for user authentication. However before the Web application can be run, you must configure the domain-level jps-config.xml file on the application's target Oracle WebLogic Server for the Oracle Access Manager security provider.

The domain-level jps-config.xml file is in the following path and should not be confused with the deployed application's jps-config.xml file:

domain_home/config/fmwconfig/jps-config.xml 

You can use an Oracle Access Manager-specific WLST script to configure the domain-level jps-config.xml file, either before or after the Web application is deployed. This Oracle JRF WLST script is named as follows:

Linux: wlst.sh

Windows: wlst.cmd

The Oracle JRF WLST script is available in the following path if you are running through JDev:

     $JDEV_HOME/oracle_common/common/bin/

In a standalone JRF WebLogic installation, the path is:

     $Middleware_home/oracle_common/wlst

Note:

The Oracle JRF WLST script is required. When running WLST for Oracle Java Required Files (JRF), do not use the WLST script under $JDEV_HOME/wlserver_10.3/common/bin.


Command Syntax

addOAMSSOProvider(loginuri, logouturi, autologinuri)

Table 16-5 defines the expected value for each argument in the addOAMSSOProvider command line.

Table 16-5 addOAMSSOProvider Command-line Arguments

ArgumentDefinition

loginuri

Specifies the URI of the login page

autologinuri

Specifies the URI of the autologin page.

logouturi

Specifies the URI of the logout page


Prerequisites

Configuring Providers in the WebLogic Domain

To modify domain-level jps-config.xml for a Fusion Web application with Oracle ADF Security enabled

  1. On the computer hosting the Oracle WebLogic Server and the Web application using Oracle ADF security, locate the Oracle JRF WLST script. For example:

    cd $ORACLE_HOME/oracle_common/common/bin
    
  2. Connect to the computer hosting the Oracle WebLogic Server:

    connect login_id password hostname:port
    

    For example, the Oracle WebLogic Administration Server host could be localhost using port 7001. However, your environment might be different.

  3. Enter the following command-line arguments with values for the application with ADF security enabled:

    addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication", 
    logouturi="/oamsso/logout.html", autologinuri="/obrar.cgi")
    
  4. Stop and start the Oracle WebLogic Server.

  5. Perform the following tasks as described in:

16.2.4.2.4 Setting Up Providers for Oracle Access Manager 11g Identity Assertion

This topic describes how to configure providers in the WebLogic security domain to perform single sign-on with the Oracle Access Manager Identity Asserter. Several Authentication Provider types must be configured and ordered:

  • OAM Identity Asserter: REQUIRED (also specify a chosen Active Type for the mechanism you are using (Table 15-1))

  • OID Authenticator: SUFFICIENT

  • DefaultAuthenticator: SUFFICIENT

The following procedure uses the WebLogic Administration Console.


Note:

With an Oracle Fusion Middleware application installed, you have the required provider JAR file. Skip Step 1.


To set up Providers for Oracle Access Manager single sign-on in a WebLogic domain

  1. No Oracle Fusion Middleware Application: Obtain the Oracle Access Manager provider:

    1. Log in to Oracle Technology Network at:

      http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html   
      
    2. Locate the oamAuthnProvider ZIP file with Access Manager WebGates (10.1.4.3.0):

      oamAuthnProvider<version number>.zip  
      
    3. Extract and copy oamAuthnProvider.jar to the following path on the computer hosting Oracle WebLogic Server:

      BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar 
      
  2. With Oracle Fusion Middleware Application Installed:

    1. Locate oamauthenticationprovider.war in the following path:

      ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprovi
      der.war
      
    2. Copy oamauthenticationprovider.war to the following location:

      BEA_HOME/wlserver_10.x/server/lib/console-ext/autodeploy/oamauthentication
      provider.war  
      
  3. Log in to the WebLogic Administration Console.

  4. Click Security Realms, Default Realm Name, and click Providers.

  5. OAM Identity Asserter: Perform the following steps to add this provider:

    1. Click New, and then enter a name and select a type:

      Name: OAM Identity Asserter

      Type: OAMIdentityAsserter

      OK

    2. In the Authentication Providers table, click the newly added authenticator.

    3. Click the Common tab, set the Control Flag to REQUIRED.

    4. On the Common tab, specify one Chosen Active Type for your SSO mechanism (Table 15-1). For example:


      OAM_IDENTITY_ASSERTION
    5. Save the configuration.

  6. OID Authenticator: Perform the following steps to add this provider.

    1. Click Security Realms, Default Realm Name, and click Providers.

    2. Click New, enter a name, and select a type:

      Name: OID Authenticator

      Type: OracleInternetDirectoryAuthenticator

      OK

    3. In the Authentication Providers table, click the newly added authenticator.

    4. On the Settings page, click the Common tab, set the Control Flag to SUFFICIENT, and then click Save.

    5. Click the Provider Specific tab and specify the following required settings using values for your own environment:

      Host: Your LDAP host. For example: localhost

      Port: Your LDAP host listening port. For example: 6050

      Principal: LDAP administrative user. For example: cn=orcladmin

      Credential: LDAP administrative user password.

      User Base DN: Same searchbase as in Oracle Access Manager.

      All Users Filter: For example: (&(uid=*)(objectclass=person))

      User Name Attribute: Set as the default attribute for username in the LDAP directory. For example: uid

      Group Base DN: The group searchbase (same as User Base DN)

      Do not set the All Groups filter as the default works fine as is.

      Save.

  7. Default Authenticator: Perform the following steps to set up the Default Authenticator for use with the Identity Asserter:

    1. Go to Security Realms, Default Realm Name, and click Providers.

    2. Click Authentication, Click DefaultAuthenticator to see its configuration page.

    3. Click the Common tab and set the Control Flag to SUFFICIENT.

    4. Save.

  8. Reorder Providers:

    1. Click Security Realms, Default Realm Name, Providers.

    2. On the Summary page where providers are listed, click the Reorder button

    3. On the Reorder Authentication Providers page, select a provider name and use the arrows beside the list to order the providers as follows:

      OAM Identity Asserter (REQUIRED)

      OID Authenticator (SUFFICIENT)

      Default Authenticator (SUFFICIENT)

    4. Click OK to save your changes

  9. Activate Changes: In the Change Center, click Activate Changes.

  10. Reboot Oracle WebLogic Server.

  11. Proceed as follows:

As mentioned earlier, a login form shipped with 10g WebGate is used only with OAM 10g Access Server. For OAM 11g, neither the 10g WebGate nor 11g WebGate provide a login page.


Note:

The OAM 11g Server displays a login page. No set up is needed.


16.2.4.3 Trusted Header Assertion: Configuring Digital Signature Verification

This is a manual task. The Oracle Access Manager certificate public key is required for digital signature verification. The certificate, which is consumed by the Identity Asserter, must be in the .oamkeystore.

For the SSO Sync Filter to consume the certificate, you need to provide the truststore to the filter. SSO Sync Filter behavior can be altered for application requirements by passing various over-riding system properties to WebLogic. To do this, you add a property in Oracle WebLogic startup script (setDomainEnv.sh) under EXTRA_JAVA_PROPERTIES. The truststore location can be provided as the system property. By default filter will look for keystore at ssofilter.jar location. If not found then it looks in system property.

The following procedure guides as you retrieve the .oamkeystore password required to perform export and import operations. After you export and import the required OAM certificate, you provision the keystore to enable the Identity Asserter to consume the certificate. Finally, you choose the OAM_IDENTITY_ASSERTION token type, provision the certificate in the SSO Sync Filter, and confirm that the authorization policy enables Identity Assertion.

To configure digital signature verification for trusted header assertion

  1. Retrieve the .oamkeystore password using WLST script tool as follows:

    1. Locate the WLST tool in your $MW_HOME/Oracle_IDM1/common/bin.

    2. Execute wst.sh: $ ./wlst.sh.

    3. Confirm execution with the following onscreen messages:

      Initializing WebLogic Scripting Tool (WLST) ...
      
      Jython scans all the jar files it can find at first startup. Depending on 
      the system, this process may take a few minutes to complete, and WLST may
      not return a prompt right away
      
      Welcome to WebLogic Server Administration Scripting Shell
      
      Type help() for help on available commands
      
    4. Execute wls:/offline> connect() and supply information for your environment (WebLogic Administrator username and password and AdminServer URL). For example:

      Please enter your username: weblogic  
      Please enter your password: password 
      Please enter your server URL //localhost:7001  
      not return a prompt right away
      
      Connecting to ... 
      Successfully connected to Admin Server 'AdminServer' ... domain 'base_domain'.
      
      Warning: An insecure protocol was used to connect to the server. 
      To ensure on-the-wire security, the SSL port or Admin port should be used 
      instead. 
      wls:/base_domain/serverConfig
      
    5. Execute wls:/base_domain/serverConfig> domainRuntime() and check the following onscreen messages. For example:

      Location changed to domainRuntime tree. This is a read-only tree with   
      DomainMBean as the root
      
      For more help, use help(domainRuntime) 
      
      wls:/base_domain/domainRuntime>  
      
    6. Execute wls:/base_domain/domainRuntime> listCred(map="OAM_STORE",key="jks"). For example:

      Already in Domain Runtime Tree  
      PASSWORD: lleoi4sbkpo3bj8fg55k7jgbgh 
      wls:/base_domain/domainRuntime>   
      
  2. Export the alias to a certificate file using the JDK6 keytool, as follows:

    jdk/bin]$ keytool -exportcert -alias "assertion-cert" -keystore .oamkeystore 
    -storepass gtml6es9qderjc66f76hvtqm5a -storetype JCEKS -file assertion.cer
    
  3. Import the certificate file using the JDK6 keytool, as follows:


    Note:

    The keystore alias oam.assertion.cert and the keystore name oamiap-keystore.jks are fixed. Use those names only.


    jdk/bin $ keytool -importcert -trustcacerts -alias "oam.assertion.cert" -file   
    assertion.cer -keystore /scratch/oamiap-keystore.jks -storepass password 
    -storetype JKS 
    
  4. Provision the Identity Asserter keystore for consumption of the OAM certificate with the public key in oamiap-keystore.jks:

    1. From the WebLogic Console, Security Realm, Identity Asserter entry, add the absolute path of oamiap-keystore.jks in the provider-specific configuration.

    2. Select token type OAM_IDENTITY_ASSERTION in provider-specific configuration.

    3. Save this configuration.

    OAM Keystore Asserter
  5. Provision .oamkeystore in the SSO Sync Filter, as follows:

    By default, the filter looks for the keystore in the ssofilter.jar location. If not found there, the system property is checked.

    1. Default configuration: Place the keystore file oamiap-keystore.jks in the same location as ssofilter.jar. For example: $MW_HOME/oracle_common/modules/oracle.ssofilter_11.1.1

    2. Fallback Mechanism: Set the keystore file oamiap-keystore.jks as a systemproperty in setDomainEnv.sh ($MW_HOME/user_projects/domains/base_domain/bin/setDomainEnv.sh):

      -Dsso.filter.oam.keystore=/scratch/keystore/oamiap-keystore.jks
      
  6. Set System Properties for OAM_IDENTITY_ASSERTION, as follows:

    1. Stop the WebLogic Server.

    2. Open the file setDomainEnv.sh in $MW_HOME/user_projects/domains/base_domain/bin/setDomainEnv.sh

    3. Add the following property under EXTRA_JAVA_PROPERTIES, and save the file:

        -Dsso.filter.ssotoken=OAM_IDENTITY_ASSERTION
    
  7. Start the WebLogic Server.

  8. Proceed to "Trusted Header Assertion: Configuring Policies".

16.2.4.4 Trusted Header Assertion: Configuring Policies

To use OAM_IDENTITY_ASSERTION as a token type for the assertion, the Identity Assertion option must be enabled within the authorization policy that protects the resources. Default policies are generated during agent registration. You can also create policies manually using the Oracle Access Manager Console.

Figure 16-6 provides an example of an authorization policy for the Trusted Header Assertion mechanism.

Figure 16-6 Sample Authorization Policy for Trusted Header Assertion

Surrounding text describes Figure 16-6 .

The following procedure provides the steps to enable Identity Assertion within the Oracle Access Manager 11g authorization policy that protects the resources.

To enable Identity Assertion for Trusted Header Assertion

  1. From the Policy Configuration tab, navigation tree, open the following nodes:


    Application Domains
    Desired Domain
    Authorization Policies
    PolicyName
  2. Enable Identity Assertion (check the box).

  3. Resources:

    • On the Resource tab, confirm the desired resources are protected by this policy.

    • Add or remove resources as needed.

  4. Click Apply to save changes and close the Confirmation window.

  5. Close the page when you finish.

  6. Proceed with "Testing Oracle Access Manager Identity Assertion for Single Sign-on".

16.2.4.5 Testing Oracle Access Manager Identity Assertion for Single Sign-on

The following procedure describes how to test your Oracle Access Manager Identity Assertion setup, regardless of the mechanism you are using.

Alternatively, you can run Access Tester in Oracle Access Manager to test your policy domain, as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

To validate Oracle Access Manager Identity Assertion for Single Sign-on

  1. Enter the URL to access the protected resource in your environment. For example:

    http://ohs_server:port/<protected url>
    
  2. Provide appropriate credentials when the login form appears.

16.2.5 Configuring the Authenticator Function for Oracle Access Manager 11g

With the Authenticator function, the user is challenged for credentials based on the authentication method that is configured within the application web.xml. However, an Oracle Access Manager authentication scheme is required and available in the pre-seeded application domain that is delivered with Oracle Access Manager 11g. It protects the following resources (resource type wl_authen):

  • /Authen/Basic

  • /Authen/SSOToken

  • /Authen/UsernameAssertion

You can add Responses and Constraints to policies. However, no other configuration is needed.

For more information about the pre-seeded application domain, see "Previewing Pre-Seeded OAM 11g Policies for Use by the 10g AccessGate".

Prerequisites

Tasks to configure the Oracle Access Manager Authenticator are described in the following overview.

Task overview: Configuring the Authenticator function for OAM includes

  1. Ensuring that all prerequisite tasks have been performed

  2. Configuring Providers for the Authenticator in a WebLogic Domain

  3. Configuring the Application Authentication Method for the Authenticator

  4. Mapping the Authenticated User to a Group in LDAP

  5. Configuring Centralized Log Out for Oracle Access Manager 11g

  6. Testing the Oracle Access Manager Authenticator Implementation

16.2.5.1 Configuring Providers for the Authenticator in a WebLogic Domain

This topic includes a procedure that you can use to add and configure the appropriate Authentication providers in a WebLogic domain.

The Oracle Access Manager Authenticator must be configured along with the Default Authentication Provider in a WebLogic domain.

  • DefaultAuthenticator: SUFFICIENT

  • OAM Authenticator: OPTIONAL

The following procedure describes this task using the WebLogic Administration Console. You can also add these using the Oracle WebLogic Scripting Tool (WLST).


Note:

When an Oracle Fusion Middleware application is installed, you have the required files and can skip Step 1.


To configure providers for the Oracle Access Manager Authenticator in a WebLogic domain

  1. No Oracle Fusion Middleware Application: Obtain the Oracle Access Manager provider if you have no Oracle Fusion Middleware application.

    1. Log in to Oracle Technology Network at:

      http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html   
      
    2. Locate the oamAuthnProvider ZIP file with Access Manager WebGates (10.1.4.3.0). For example:

      oamAuthnProvider<version>.zip 
      
    3. Extract and copy the oamAuthnProvider.jar to the following path on the computer hosting Oracle WebLogic Server:

      BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar 
       
      
  2. Go to the Oracle WebLogic Administration Console.

  3. With Oracle Fusion Middleware Application Installed:

    1. Locate oamauthenticationprovider.war in the following path:

      ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprovi
      der.war 
      
    2. Copy oamauthenticationprovider.war to the following location:

      BEA_HOME/wlserver_10.x/server/lib/console-ext/autodeploy/oamauthentication
      provider.war  
      
  4. Go to the Oracle WebLogic Administration Console.

  5. Click Lock & Edit, if desired.

  6. OAM Authenticator:

    1. Click Security Realms and select the realm you want to configure.

    2. Select Providers, Authentication, and click New to display the Create a New Authentication Provider page

    3. Enter a name and select a type:

      Name OAMAuthN

      Type: OAMAuthenticator

      OK

    4. Click the name of the Authentication provider you have just created to display the Provider Configuration page.

    5. In the Provider Configuration page, set the required values as follows:

      Access Gate Name: The name of the AccessGate used by the Provider. This must match exactly the name of an OAM Agent registration in the Oracle Access Manager Console.


      Note:

      You can have one or more 10g OAM Agents registered with OAM 11g. Be sure to choose the correct Agent registration name.


      Access Gate Password: The same password, if any, that is as defined for the Agent registration (see the Oracle Access Manager Console).

      Primary Access Server: The host:port of the primary OAM Server that is associated with this AccessGate in the Oracle Access Manager Console.

      Advanced Configuration: Following are several advanced configuration values.

      Transport Security: The communication mode between OAM Server and AccessGate: open, simple, or cert.

      If transport security is Simple or Cert, include the following parameters and values:

      Trust Store: The absolute path of JKS trust store used for SSL communication between the provider and the OAM Server.

      Key Store: The absolute path of JKS key store used for SSL communication between the provider and the OAM Server.

      Key Store Pass Phrase: The password to access the key store.

      Simple mode pass phrase: The password shared by AccessGate and OAM Server for simple communication modes.

      Secondary OAM Server: The host:port of the secondary OAM Server that is associated with this AccessGate in the Oracle Access Manager Console.

      Maximum OAM Server Connections in Pool: The maximum number of connections that the AccessGate opens to the OAM Server. The default value is 10.


      Note:

      The Maximum OAM Server Connections in Pool (or Minimum OAM Server Connections in Pool) settings in the WebLogic Administration Console are different from the Maximum (or Minimum) Connections specified in the Oracle Access Manager Console.


      Minimum Access Server Connections in Pool: The minimum number of connections that the Authentication provider uses to send authentication requests to the OAM Server. The default value is 5.


      See Also:

      "Oracle Access Manager Authentication Provider Parameter List" for descriptions and values of the common and provider-specific parameters


    6. Ensure that the parameter Control Flag is set to OPTIONAL initially.


      Note:

      Do not set the parameter Control Flag to REQUIRED until you have verified that the Authentication Provided is operational and configured correctly.


  7. In the Change Center, click Activate Changes.

  8. DefaultAuthenticator: Under the Providers tab, select DefaultAuthenticator, which changes its control flag to SUFFICIENT.

  9. Reorder: Under the Providers tab, reorder the providers so that DefaultAuthenticator is first (OAMAuthenticator follows DefaultAuthenticator).


    Note:

    If the Oracle Access Manager Authenticator flag is set to REQUIRED, or if Oracle Access Manager Authenticator is the only Authentication provider, perform the next step to ensure that the LDAP user who boots Oracle WebLogic Server is included in the administrator group that can perform this task. By default the Oracle WebLogic Server Admin Role includes the Administrators group.


  10. Oracle Access Manager Authenticator REQUIRED or the Only Authenticator: Perform the following steps to set user rights for booting Oracle WebLogic Server.

    1. Create an Administrators group in the directory server, if one does not already exist (or any other group for which you want boot access).


      Note:

      To provide access to any other group, you must create that group in the directory server and add the user who boots WebLogic Server in that group.


    2. Confirm that the LDAP user who boots Oracle WebLogic Server is included in the Administrators (or other) group.

    3. From the WebLogic Administration Console, go to Security Realms, myrealm, Roles and Policies, Global Roles.

    4. Select View Conditions for the Admin Role.

    5. Add the group and click Save.

  11. Reboot the WebLogic Server.

  12. Once the server has started, reset the Authentication Provider parameter Control Flag to the appropriate value (REQUIRED, OPTIONAL, or SUFFICIENT).


    Note:

    The recommended value is REQUIRED. To prevent a known issue, see "JAAS Control Flag".


  13. Proceed with "Configuring the Application Authentication Method for the Authenticator".

16.2.5.2 Configuring the Application Authentication Method for the Authenticator

This topic describes how to create the application authentication method for Oracle Access Manager Authenticator.

When you use the Oracle Access Manager Authenticator, all web.xml files in the application EAR file must specify BASIC in the element auth-method for the appropriate realm.

The auth-method can use BASIC or FORM values. While these look like similar values in Oracle Access Manager, the auth-method specified in web.xml files are used by Oracle WebLogic Server (not Oracle Access Manager).


Note:

For the Oracle Access Manager Authenticator, Oracle recommends auth-method BASIC in login-config within web.xml.


To configure the application authentication method for the Authenticator

  1. Locate the web.xml file in the application EAR file:

    WEB-INF/web.xml 
    
  2. Locate the auth-method in login-config and enter BASIC. For example:

    <security-constraint>
    <web-resource-collection>
    <web-resource-name>protected</web-resource-name>
    <url-pattern>/servlet</url-pattern>
    </web-resource-collection>
    <auth-constraint>
    <role-name>auth-users</role-name>
    </auth-constraint>
    </security-constraint>
    <login-config>
    <auth-method>BASIC</auth-method>
    </login-config>
    <security-role>
    <description>Authenticated Users</description>
    <role-name>auth-users</role-name>
    </security-role>
    
  3. Save the file.

  4. Redeploy and restart the application.

  5. Repeat for each web.xml file in the application EAR file.

  6. Proceed with "Mapping the Authenticated User to a Group in LDAP".

16.2.5.3 Mapping the Authenticated User to a Group in LDAP

This topic describes how to map the authenticated user to a group in LDAP. To do this, you must edit the weblogic.xml file. For example, you might need to map your role-name auth-users to a group named managers in LDAP.

To map the authenticated user to a group in LDAP for the Oracle Access Manager Authenticator

  1. Go to the application's weblogic.xml file.

  2. Add the following information for your environment anywhere in the file:

    <weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app
    http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd" 
    xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">
    <security-role-assignment>
    <principal-name>managers</principal-name>
    <role-name>auth-users</role-name>
    </security-role-assignment>
    </weblogic-web-app>
    
  3. Save the file.

  4. Restart the WebLogic Server.

  5. Configure centralized logout as described in "Configuring Centralized Log Out for Oracle Access Manager 11g" and then return here to perform "Testing the Oracle Access Manager Authenticator Implementation".

16.2.5.4 Testing the Oracle Access Manager Authenticator Implementation

After performing all tasks to implement the Authenticator, you can test it by attempting to log in to the application using valid credentials. If the configuration is incorrect, a valid user is denied access.

The following procedure describes how to test your Authenticator setup. Alternatively, you can run Access Tester in Oracle Access Manager to test your policy domain, as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

To validate the Oracle Access Manager Authenticator implementation

  1. Enter the URL to access the protected resource in your environment. For example:

    http://yourdomain.com:port
    
  2. Provide appropriate credentials when the login form appears.

16.2.6 Configuring Identity Assertion for Oracle Web Services Manager and OAM 11g

This section describes how to set up the Oracle Access Manager Identity Asserter to enable validation of the token when you have Oracle Web Services Manager protecting Web services.

As discussed earlier, the Oracle Access Manager Identity Asserter works in two modes. The default mode of operation simply asserts the header that is set by WebGate at the perimeter, which handles most SSO situations. The alternate mode uses the custom AccessGate in oamAuthnProvider.jar. In this case, and with the absence of the header, the Identity Asserter contacts the OAM Server to validate the token. For more information about the token, see "Installing the Authentication Provider with Oracle Access Manager 11g".


Note:

The 10g custom AccessGate provided with the Authentication Provider is required for Identity Assertion for Oracle Web Services Manager.


With OAM 10g, you would need to manually create the policy domain and policies for this configuration. However, with OAM 11g, a pre-seeded application domain is delivered with policies that protect the following resources (resource type wl_authen):

  • /Authen/Basic

  • /Authen/SSOToken

  • /Authen/UsernameAssertion

You can add policies, Responses, or Constraints for resources of type wl_authen only. Ideally, however, you can use this application domain with no further configuration. For more information, see "Previewing Pre-Seeded OAM 11g Policies for Use by the 10g AccessGate".

When the Oracle Access Manager Identity Asserter is configured for both header and token validation modes, preference is given to the presence of the header. If the header is not present, the Identity Asserter contacts the OAM Server to validate the token. For more information on the token, see "Oracle Access Manager Authentication Provider Parameter List".

Prerequisites

Installing the Authentication Provider with Oracle Access Manager 11g

Session Token: Provisioning an OAM Agent with Oracle Access Manager 11g

Task overview: Deploying the Identity Asserter with Oracle Web Services Manager includes

  1. Configuring Providers in a WebLogic Domain for Oracle Web Services Manager

  2. Configuring Centralized Log Out for Oracle Access Manager 11g

  3. Testing the Identity Asserter with Oracle Web Services Manager

16.2.6.1 Configuring Providers in a WebLogic Domain for Oracle Web Services Manager

To use Oracle Access Manager Identity Asserter with Oracle Web Services Manager protected Web services, several Authentication providers must be configured and ordered in a WebLogic domain:

  • OAM Identity Asserter: REQUIRED

  • OID Authenticator: SUFFICIENT

  • DefaultAuthenticator: SUFFICIENT

This procedure is nearly identical to the one for the Oracle Access Manager Identity Asserter with OAM 11g. The difference in this case is that Oracle Web Services Manager requires the custom 10g AccessGate and additional provider-specific values:

  • Primary Access Server: Specify the primary OAM Server host and port. For example: mnop:8888

  • Access Gate Name: The name of the AccessGate registration protecting the application. For example: AG1

  • Access Gate Password: The AccessGate password as specified in the Oracle Access Manager Console.

You can add these using either the Oracle WebLogic Administration Console or Oracle WebLogic Scripting Tool (WLST) command-line tool.


Note:

With a Oracle Fusion Middleware application installed, you have the required provider file. Skip Step 1.


To set up providers in a WebLogic domain

  1. No Oracle Fusion Middleware Application: Obtain the Oracle Access Manager provider if you have no Oracle Fusion Middleware application.

    1. Log in to Oracle Technology Network at:

      http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html   
      
    2. Locate the oamAuthnProvider ZIP file with Access Manager WebGates (10.1.4.3.0). For example:

      oamAuthnProvider<version>.zip 
      
    3. Extract and copy the oamAuthnProvider.jar to the following path on theH] computer hosting Oracle WebLogic Server:

      BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar 
       
      
  2. Log in to the Oracle WebLogic Administration Console.

  3. OAM Identity Asserter: Perform the following steps to add this provider:

    1. Click Security Realms, Default Realm Name, and click Providers.

    2. Click Authentication, click New, and then enter a name and select a type:

      Name: OAM Identity Asserter

      Type: OAMIdentityAsserter

      OK

    3. In the Authentication Providers table, click the newly added authenticator.

    4. On the Common tab, set the Control Flag to REQUIRED, and click Save.

    5. Click the Common tab, specify ObSSOCookie as the chosen Active Type for the 10g custom AccessGate, and click Save.

    6. Click the Provider Specific tab and configure these parameters:

      Primary Access Server: Specify the primary OAM Server host and port. For example: abcd:7777

      Access Gate Name: The name of the OAM Agent registration protecting the application. For example: AG1

      Access Gate Password: The AccessGate password, if any, that was specified in during provisioning.

      Save.

  4. OID Authenticator: Perform the following steps to add this provider.

    1. Click Security Realms, Default Realm Name, and click Providers

    2. Click New, enter a name, and select a type:

      Name: OID Authenticator

      Type: OracleInternetDirectoryAuthenticator

      Click OK.

    3. In the Authentication Providers table, click the newly added authenticator.

    4. On the Settings page, click the Common tab, set the Control Flag to SUFFICIENT, and then click Save.

    5. Click the Provider Specific tab and specify the following required settings using values for your own environment:

      Host: Your LDAP host. For example: localhost

      Port: Your LDAP host listening port. For example: 6050

      Principal: LDAP administrative user. For example: cn=orcladmin

      Credential: LDAP administrative user password.

      User Base DN: Same searchbase as in Oracle Access Manager.

      All Users Filter: For example: (&(uid=*)(objectclass=person))

      User Name Attribute: Set as the default attribute for username in the LDAP directory. For example: uid

      Group Base DN: The group searchbase (same as User Base DN)


      Note:

      Do not set the All Groups filter as the default works fine as is.


      Click Save.

  5. Default Authenticator: Perform the following steps to set up the Default Authenticator for use with the Identity Asserter:

    1. Go to Security Realms, Default Realm Name, and click Providers.

    2. Click Authentication, Click DefaultAuthenticator to see its configuration page.

    3. Click the Common tab and set the Control Flag to SUFFICIENT.

    4. Click Save.

  6. Reorder Providers:

    1. Click Security Realms, Default Realm Name, Providers.

    2. On the Summary page where providers are listed, click the Reorder button

    3. On the Reorder Authentication Providers page, select a provider name and use the arrows beside the list to order the providers as follows:

      OAM Identity Asserter (REQUIRED)

      OID Authenticator (SUFFICIENT)

      Default Authenticator (SUFFICIENT)

    4. Click OK to save your changes

  7. Activate Changes: In the Change Center, click Activate Changes

  8. Reboot Oracle WebLogic Server.

  9. Proceed as follows:

16.2.6.2 Testing the Identity Asserter with Oracle Web Services Manager

To validate the use of the Oracle Access Manager Identity Asserter with Oracle Web Services Manager, you can access the Web service protected by the Identity Asserter and Oracle Web Services Manager policies. If access is granted, the implementation works. If not, see "Troubleshooting Tips".

16.3 Configuring Centralized Log Out for Oracle Access Manager 11g

This section introduces Centralized logout for Oracle Access Manager 11g.

With OAM 11g, centralized logout refers to the process of terminating an active user session. Guidelines include:

  • Applications must not provide their own logout page for use in an SSO environment.

  • Applications must make their logout links configurable with a value that points to the logout URL specified by the OAM WebGate Administrator.


Note:

Oracle strongly recommends that applications use the ADF Authentication servlet, which in turn interfaces with OPSS, where a domain wide configuration parameter can be used to specify the logout URL. This way applications need not be modified or redeployed to change logout configuration.


For more information, see:

16.3.1 Logout for 11g WebGate and OAM 11g

Several elements in the OAM 11g Agent registration page enable centralized logout for OAM 11g WebGates. After agent registration, the ObAccessClient.xml file is populated with the information.

11g WebGate logout options that you must have in the agent registration include the following:

  • Logout URL: Triggers the logout handler, which removes the cookie (ObSSOCookie for 10g WebGates; OAMAuthnCookie for 11g WebGates) and requires the user to re-authenticate the next time he accesses a resource protected by Oracle Access Manager.

  • Logout Callback URL: The URL to oam_logout_success, which clears cookies during the call back. This can be a URI format without host:port (recommended), where the OAM Server calls back on the host:port of the original resource request.

  • Logout Redirect URL: This parameter is automatically populated after agent registration completes.By default, this is based on the OAM Server host name with a default port of 14200.

  • Logout Target URL: The value for this is name for the query parameter that the OPSS applications passes to WebGate during logout. This query parameter specifies the target URL of the landing page after logout.

For more information, see "Configuring Centralized Logout for 11g WebGate with OAM 11g Server" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

16.3.2 Logout for 10g WebGate with Oracle Access Manager 11g

Logout is initiated when an application causes the invocation of the logout.html file configured for the OAM Agent (in this case, a 10g WebGate). The application might also pass end_url as a query string to logout.html. The end_url parameter could either be a URI or a URL.

Task overview: Configuring centralized logout for 10g WebGates

  1. Create a default logout page (logout.html) and make it available on the WebGate installation directory: For example, WebGate_install_dir/oamsso/logout.html.

  2. In your logout.html, confirm that the logOutUrls parameter is configured for each resource WebGate and that <callBackUri> is the second value as part of 'logOutUrls'.

  3. In your logout.html, confirm (from Step 1), confirm that the user is redirected to the central logout URI on the OAM 11g Server, "/oam/server/logout'.

  4. Optional: Allow the application to pass the end_url parameter indicating where to redirect the user after logout.

  5. Check the OHS Web server configuration file, httpd.conf, on which the 10g WebGate is configured and if the following lines exist delete them.

    <LocationMatch "/oamsso/*">
    Satisfy any
    </LocationMatch>
    

For more information, see "Configuring Centralized Logout for 10g WebGate with OAM 11g Servers" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

16.4 Synchronizing the User and SSO Sessions: SSO Synchronization Filter

In Fusion Middleware 11g, a new component that synchronizes the container user session and SSO session has been introduced. SSO Sync Filter is an Oracle WebLogic system filter implementation that intercepts all requests to the container, acts on protected resource requests, and attempts to synchronize the container's user session with the user identifying header in OSSO (Proxy-Remote-User) or the user data in the Oracle Access Manager SSO session cookie (ObSSOCookie).

SSO Synchronization Filter (SSO Sync Filter) is an implementation of the Servlet Filter based on Java Servlet Specification version 2.3. SSO sync filter relieves applications from tracking the SSO user session and synchronizing it with their respective sessions. Instead, applications would only need to synchronize with container's user session.

SSO Sync Filter intercepts each request to the container and determines whether to act on it based on certain HTTP headers that are attached to the request. Filter expects SSO agent to have set those headers in the Web Tier. When access is made to unprotected areas of the application, the filter acts as a pass through. Once a protected resource is accessed, SSO agents in the Web Tier, direct user to perform authentication with SSO system such as Oracle Access Manager. After the authentication, Oracle Access Manager Identity Asserter helps establish a user identity in form of JAAS Subject to the container and a user session is created. WebLogic maintains the user session data as part of HTTP Session Cookie (JSESSIONID).

Subsequent access to the application resources provides two pieces of information to the SSO Sync Filter:

  • User identifying header in OSSO (Proxy-Remote-User)

  • User data in the Oracle Access Manager SSO session cookie (ObSSOCookie)

The job of SSO Sync Filter is to make sure that the user identity in the container matches with that of the SSO session. If there is a mismatch, filter invalidates the container's user session. As a result, the downstream application would only have to track container user session and react in a consistent fashion regardless of SSO environment in use.

Notes:

  • Enabled and Active by Default: SSO Sync Filter fetches the user information from the configured tokens, gets the user from existing session (if any), invalidates the session and redirects to the requested URL in case the CurrentSessionUser does not match the incoming SSO User. Otherwise, the request is simply passed through.

    If you have not configured the OSSO or Oracle Access Manager Assertion Providers in your domain, the filter disables automatically during WebLogic Server start-up.

  • Active for All URI's by Default (/* ): No changes are required in the application code.

  • Configured for the OSSO Tokens/Header: Proxy-Remote-User, and performs a case insensitive match.

  • Configured for the Oracle Access Manager SSO Tokens/Header: OAM_REMOTE_USER and REMOTE_USER, and does a case insensitive match.

  • Configured for the Oracle Access Manager SSO Tokens/Header: OAM_IDENTITY_ASSERTION, a case insensitive match. For details, see "Trusted Header Assertion: Configuring Digital Signature Verification".

  • Global Logout: SSO Sync Filter is intended to provide the Single Logout Experience to the Oracle Fusion Middleware applications that use the OSSO or Oracle Access Manager Solutions. Is handled similarly to single sign-on. After global logout is performed, SSO filter reconciles the session when subsequent access to an application that has not cleaned up its session is made.

    Any application that use the OSSO or Oracle Access Manager Solutions is expected to invalidate its session before making a call to OSSO logout or Oracle Access Manager logout. For more information on OSSO logout, see Example 18-2, "SSO Logout with Dynamic Directives". For details about Oracle Access Manager logout, see "Configuring Global Logout for Oracle Access Manager 10g and 10g WebGates".

  • Application Session Time Out: SSO cookies typically track user inactivity/idle times and force users to login when a time out occurs. OSSO and Oracle Access Manager are no exception. Oracle Access Manager takes a sophisticated approach at this and specifically tracks Maximum Idle Session Time and Longest Idle Session Time along with SSO session creation time and time when it was last refreshed.

    The general recommendation for applications that are maintaining their own sessions when integrating with SSO systems is to configure their session time outs close to that of SSO session time outs so as to make user experience remains consistent across SSO and application session time outs.

You can alter the behavior of the SSO Sync Filter for application requirements by passing various over-riding system properties to WebLogic. To do this, you change the Oracle WebLogic startup script and check for EXTRA_JAVA_PROPERTIES in setDomainEnv.sh. The properties and Sync behavior is shown in Table 16-6.

Table 16-6 SSO Sync Filter Properties and Sync Behavior

AreaOverriding System PropertyDefault value of System propertyDefault Behavior of the Sync Filter

Status (Active or Inactive)

sso.filter.enable

Not configured

Enabled

Case sensitive matches

sso.filter.name.exact.match

Not configured

Case Ignore Match

Configured Tokens

sso.filter.ssotoken

Not configured

  • OSSO: Look for Proxy-Remote-User

  • Oracle Access Manager: Look for OAM_REMOTE_USER and REMOTE_USER.

    OAM_REMOTE_USER takes precedence.

URI Mappings

Not Applicable

Not Applicable

/*



You cannot enable the filter for selected applications. The SSO Sync Filter is a system filter. As such, it is activated for all deployed applications (the URI mapping is /*).


Note:

You cannot enable the filter for selected applications.


The following procedure gives some tips about modifying the SSO Sync filter properties and behavior.

To modify the SSO Sync Filter properties and behavior

  1. Disable the Filter: Change the system property "sso.filter.enable" to "false" (pass as -D to the jvm) and restart the Oracle WebLogic Server. This toggles the filter status.

  2. User-Identifying Header Differs from Pre-Configured Sync Filter Tokens: Over-ride the SSO token that the Sync Filter looks for using the system property "sso.filter.ssotoken".

    For example, pass to the WebLogic Server jvm in the WebLogic Server startup script -Dsso.filter.ssotoken=HEADERNAME, and restart the server.

When you contact Oracle Support you might be requested to set up debugging, as described in "Setting Up Debugging in the WebLogic Administration Console".

16.5 Troubleshooting Tips

For more information, see "Troubleshooting" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

PK3+a]H]PK AOEBPS/audreport.htm Using Audit Analysis and Reporting

14 Using Audit Analysis and Reporting

This chapter describes how to configure audit reporting and how to view audit reports. It contains these topics:

14.1 Setting up Oracle Business Intelligence Publisher for Audit Reports

When your audit data resides in a database, you can run pre-defined Oracle Business Intelligence Publisher reports and create your own reports on the data. This section contains these topics about configuring your environment for audit reports:


See Also:

Oracle Business Intelligence Publisher Enterprise documentation at:

http://www.oracle.com/technology/documentation/bi_pub.html


14.1.1 About Oracle Business Intelligence Publisher

Reports help auditors determine whether there are any violations with respect to various industry regulations such as HIPPA, SOX, and other regulatory compliance demands. Oracle Fusion Middleware Audit Framework is integrated with Oracle Business Intelligence Publisher for out-of-the box reports.

Pre-defined reports are available as part of the Oracle Fusion Middleware Audit Framework. These reports are integrated with Oracle Business Intelligence Publisher to work in conjunction with the audit data in the audit store.

Oracle Fusion Middleware Audit Framework ships with over twenty pre-built reports in 11g Release 1 (11.1.1). For convenience, the reports are grouped in Oracle Business Intelligence Publisher according to functional areas and by component.

The functional areas consists of the following:

  • Error and Exception reports like authentication and authorization failures

  • User Activities including transaction history and authorization history

  • Operational reports including created, deleted, and locked-out users

  • Audit Service Events

The component-specific reports, as the name implies, are grouped based on the components themselves, for example, Oracle HTTP Server reports and Oracle Identity Federation reports.

Other features of Oracle Business Intelligence Publisher include:

  • Flexible Report Displays

    You can view reports online, change report parameters, change output types (pdf, html, rtf, excel and others), modify the appearance of reports, export to the desired format, and send to an E-mail address, fax or other destination.

  • Report Filters

    You can filter audit records to be included in the report using a range of options including the ability to modify the SQL used to extract records from the audit repository.

  • Scheduling Reports

    You can schedule reports to be run based on a range of criteria such as filters, templates, formats, locale, viewing restrictions and so on.


    See Also:

    For more information about scheduling features, see the Oracle Business Intelligence Publisher Enterprise documentation at:

    http://www.oracle.com/technology/documentation/bi_pub.html


  • Custom Reporting

    You can design your own reports and specify the data model, layout, parameters, bursting (for example, you can enable delivery based on delivery preference).


See Also:


All the auditing reports available in Oracle Business Intelligence Publisher provide these report filtering and formatting options:

  • View - View the report using the current parameters.

  • Schedule - Set up a schedule for the report along with job parameters and data filters.

  • History

  • Edit - Modify the query and parameter display formats.

  • Configure - Set up runtime configuration controls.

  • Export

14.1.2 Install Oracle Business Intelligence Publisher

If you already have Oracle Business Intelligence Publisher 10.1.3.4 or later installed at your site, you can skip this section and go to Section 14.1.3, "Set Up Oracle Reports in Oracle Business Intelligence Publisher".

If you need to install Oracle Business Intelligence Publisher, follow the instructions provided with the Oracle Business Intelligence Publisher Companion CD.


See Also:

Oracle Business Intelligence Publisher Enterprise documentation at:

http://www.oracle.com/technology/documentation/bi_pub.html


14.1.3 Set Up Oracle Reports in Oracle Business Intelligence Publisher

In this section you configure Oracle Business Intelligence Publisher to work with the audit datasource.


Note:

11g Release 1 (11.1.1.4.0) PS3 reports can work only with an 11g Release 1 (11.1.1.4.0) PS3 schema; they cannot work with an earlier schema such as 11g Release 1 (11.1.1).

Details about upgrading schemas with the Patch Set Assistant are available in the Oracle Fusion Middleware Patching Guide.


Take these steps to set up Oracle Business Intelligence Publisher for use with audit reports:

  1. Navigate to the Reports folder in your Oracle Business Intelligence Publisher installation. By default, the Reports folder is at %BIP_HOME%\XMLP\Reports.

  2. Unjar the AuditReportTemplates.jar into your Reports folder. You should see a new folder called Oracle_Fusion_Middleware_Audit. You can find AuditReportTemplates.jar at:

    $MW_ORA_HOME/oracle_common/modules/oracle.iau_11.1.1/reports/
    AuditReportTemplates.jar
  3. Set up the data source for audit repository as follows:

    • Navigate to the Admin tab.

    • If you deployed on Oracle WebLogic Server in Step 1, set up JNDI as follows:

      • Click JNDI Connection.

      • Click Add DataSource.

      • Specify the DataSource details:

        Name the Data Source Audit.


        Note:

        The reports refer to the audit data source, so the naming convention is important.


        JNDI Name - 'jdbc/AuditDB'

      • Test for a successful connection. If the connection is not successful, check the values you entered.

      • Press Apply to save your changes.

    • If you deployed on Oracle Containers for Java EE in Step 1, set up JNDI as follows:

      • Click JDBC Connection.

      • Click Add DataSource.

      • Specify the DataSource details:

        Name the Data Source Audit.


        Note:

        The reports refer to the audit data source, so the naming convention is important.


        Enter the details for the URL, username, and password for the audit schema. (Note: The username and password consist of the audit schema name including a prefix, for example, username: dev_iau or test_iau.)

      • Test for a successful connection. If the connection is not successful, check the values you entered.

      • Press Apply to save your changes.

14.1.4 Set Up Audit Report Templates

You can use the standard audit reports in their default formats out-of-the-box. However, if you wish to customize the appearance and other related aspects of the reports, you do so by setting up audit report templates.

From a report's Edit dialog, you can click the Layout option in the left panel to control layouts and output formats. Using this feature, you can:

  • Customize the report template and design your own layout; for example you can rearrange fields and highlight selected field labels.

  • Restrict the formats to which the report output is generated - by default, a large number of output formats are available including HTML, PDF, Excel spreadsheet, RTF, and others.


See Also:

Oracle Business Intelligence Publisher User's Guide.


14.1.5 Set Up Audit Report Filters

You can use the standard audit reports in their default formats out-of-the-box. However, if you wish to customize the scope of data and other related aspects of the reports, you do so by setting up audit report filters.

Oracle Business Intelligence Publisher provides both basic and advanced filtering options for your audit reports.


See Also:

Oracle Business Intelligence Publisher User's Guide.


Basic Filters

Clicking on the report's Schedule button brings up a page which you can use to schedule and administer the report.

In the Report Parameters area you can provide high-level filters to restrict the report:

  • Date Filters

    • show only recent audit records such as last hour or last week

    • show records generated within a specified starting and ending dates

    • limit number of records returned

  • Selected Report Fields

    For example, the Authentication Failures report can be filtered by:

    • Username

    • Component Type

    • Component Name

    • Application Name

    • Domain Name

Advanced Filters

Clicking on the report's Edit button brings up a page at which you can specify more detailed report filters and properties. This page consists of two panels. The left panel lets you select what element of the report is to be modified through these options. For each element you select, the right panel displays the corresponding information.

  • Data Model - This contains the SQL query that fetches the raw data for the report. The query can be modified according to your needs.

  • List of Values - Shows all the report columns. Selecting on a column displays the underlying SQL query that filters data for the attribute. You can modify the query as needed; for example you can specify more restrictive filter values.

  • Parameters - Shows all the report columns, and lets you select any column to modify display settings for that column. For example, you can specify a date display format for timestamp fields.

  • Layouts and output formats - This feature is described in Section 14.1.6, "Configure Scheduler in Oracle Business Intelligence Publisher".

14.1.6 Configure Scheduler in Oracle Business Intelligence Publisher

Clicking on the report's Schedule button brings up a page which you can use to schedule and administer the report. Information you can specify on this page includes:


Note:

This feature assumes that the Oracle Business Intelligence Publisher repository is already configured.


  • Report Parameters - filters to restrict the data included in the report, for example records for the last hour only.

  • Job Properties - the job name, formatting locale and time zone, and so on.

  • Notification - one or more users to be notified by E-mail when the job completes or fails.

  • Time - report scheduling options; the report can be scheduled to run periodically or on a one-time basis.

  • Delivery - deliver the report to one or more users

14.2 Organization of Audit Reports

Oracle Fusion Middleware Audit Framework ships with a set of pre-defined reports that are designed to work, out-of-the-box, with Oracle Fusion Middleware components. These reports are organized into two main categories:

  • Common Reports

    These reports capture common events such as authentication success and failures, account-related status (lockout, disabled, and so on). Many components have implemented audit capability for these common events. The common reports are located under the Common Reports subfolder of the Audit Reports, and all audit-enabled events from across the components are captured in these reports.

    For example, "Authentication History" displays authentication history across all the components where authentication events are being captured.

    You can use these reports to examine audit records for a specific area across components or to examine the audit records of a single user across multiple components for that specific area.

  • Component-specific Reports

    These reports focus on individual components. They are needed because not all audit events may be relevant to each component. The Component Specific folder serves two purposes. First, it identifies the valid reports among the Common Reports that are relevant to the component and show only the audit records for that component. Secondly, for some components, component-specific reports have been defined to suit the specific needs of that component. While audit records themselves are generic for all the components, the representation of an audit record may have component-specific requirements. For example, an access policy may need to be shown in a format to be useful.

    For example, you can locate the Authentication History report in the Common folder, where it displays authentication events for all components. You can also find the same report under a component-specific folder, where it displays authentication events for that component only.

  • There is also a generic report at the top level called "All Events", which shows all the events across all audit-enabled components. The "All Events" report is also available in each component-specific folder, to show all the events for individual components.

    This report can be used to query audit data.

14.3 View Audit Reports

This section explains how to view audit reports using Oracle Business Intelligence Publisher.

Take these steps to view an audit report:

  1. Log in to Oracle Business Intelligence Publisher using a URL of the form:

    http://host.domain.com:port/xmlpserver/

  2. On the main page, click Oracle Fusion Middleware Audit under Shared Folders.

  3. The audit reports are organized into:

    • reports that are common to multiple components; these are further organized by report types

    • reports that are specific to a component; these are further organized by component


    See Also:

    Table 14-1 for a description of the standard reports.


  4. Navigate to the report of interest; for example, you can click on the Common Reports folder, then Errors and Exceptions, then click on All Errors and Exceptions.

    The report is displayed.

  5. The report display page contains these major areas:

    • Filters at the top of the page enable you to determine the type, scope, and number of records to include in the report. These filters include:

      • User

      • Start and End Dates

      • Last n time period

      • Component type and name

      • Application Name

      • Domain Name

      Use relevant filters to limit the report to the desired records.


      Note:

      Initially, the report is displayed with default filter values that you can modify.


    • Format control buttons enable you to determine:

      • the template type, which can be:

           HTML - This is the default display format.

           PDF - Displays a printable PDF view.

           Data - Displays an unformatted XML data set.

        To change the template type while viewing a report, select the type from the drop-down list and click View.

      • output format

      • delivery options

    • The report record display area. The appearance and number of columns depend on previously selected options and filters.

      Each column header also acts as a sort option.

  6. View, save or export the report as desired.

14.4 Example of Oracle Business Intelligence Publisher Reports

This section uses a common scenario to demonstrate how Oracle Business Intelligence Publisher reports are used to view audit data generated by Oracle Platform Security Services events.

In this example, some activity is generated on the credential store for an Oracle WebLogic Server domain. We then use Oracle Business Intelligence Publisher to take a look at the relevant report to see the audit records. Subsequently, a few other reports are examined.

  1. As the system administrator, locate the domain whose credentials are to be managed.

  2. Use the relevant commands to generate some credential management records; for example, create and delete some user credentials.


    See Also:

    Section 10.3, "Managing the Credential Store" for details about credential management.


  3. Log in to Oracle Business Intelligence Publisher using a URL of the form:

    http://host.domain.com:port/xmlpserver/

  4. Under the Reports tab, click on Shared Folders, and select Fusion Middleware Audit.

  5. On the main page, click Fusion Middleware Audit under Shared Folders.

  6. The audit report menu appears. Audit reports are organized in various folders by type.

  7. To view audit records for Oracle Platform Security Services, for example, navigate to the Component Specific folder, then Oracle Platform Security Services.

  8. The Oracle Platform Security Services folder contains several reports. Click All Events.

    The report shows activity in a default time range. Modify the time range to show only the day's events.

    The activity performed on that day appears on the page.

    Surrounding text describes audjpsrpt1.gif.

    Observe the different regions of the report and their functions: report filters, format control, scheduling, and the data display itself.

  9. In each report, the last data column is a Detail column. Click on a detail to view all the attributes of the specific audit record.

    Surrounding text describes audjpsrpt2.gif.
  10. Return to the main folder to view some other reports of interest. For example, in the Common Reports folder, navigate to the Account Management folder, and click Account Profile History.

    The Account Profile History report appears.

    Surrounding text describes audjpsrpt3.gif.
  11. Click on the Event Details for an event of interest:

    Surrounding text describes audjpsrpt4.gif.
  12. Finally, return to the Common Reports folder and select Errors and Exceptions. Select the All Errors and Exceptions report.

  13. A number of records are displayed. To narrow the report to records of interest, use the Event drop-down to select checkPermission events.

    One row is returned showing an authorization check failure:

    Surrounding text describes audcmnrpt1.gif.
  14. Click Details to obtain more information:

    Surrounding text describes audcmnrpt2.gif.

14.5 Audit Report Details

This section provides detailed reference information about the standard (pre-built) audit report.

The standard audit reports are grouped as follows:

  1. The All Events report

    This report contains all audit records generated in a pre-defined interval.

  2. Common Reports

    These are reports that contain audit records across multiple components.

  3. Component-Specific Reports

    Each report is dedicated to a specific component.

Common Reports

Common reports are organized as follows:

  • Account Management

    • Account Profile History

    • Accounts Deleted

    • Accounts Enabled

    • Accounts Disabled

    • Accounts Created

    • Accounts Locked Out

    • Password Changes

    • dashboard

  • User Activities

    • Authentication History

    • Multiple Logins from Same IP

    • Authorization History

    • Event Details

    • Related Audit Events

    • Dashboard

  • Errors and Exceptions

    • All Errors and Exceptions

    • Authorization Failures

    • Authentication Failures

    • Dashboard


Important:

Run the Event Details report only against an 11g Release 1 (11.1.1.4.0) PS3 (patch set 3) schema.


Component-Specific Reports

For a list of reports, see Section C.2.2, "Component-Specific Audit Reports".

14.5.1 List of Audit Reports in Oracle Business Intelligence Publisher

Table 14-1 provides a brief description of each audit report in Oracle Business Intelligence Publisher.


Note:

The folder path shown in the column titled "Located in Folder" is relative to the Oracle Fusion Middleware Audit folder. To get to this folder, log in to Oracle Business Intelligence Publisher, and navigate to Shared Folders, then Oracle Fusion Middleware Audit.


Table 14-1 List of Audit Reports

ReportDescriptionLocated in Folder

Accounts Created

shows accounts created in various components

Common Reports, then Account Management. Also in Component Specific folders.

Accounts Deleted

shows accounts deleted in various components

Common Reports, then Account Management. Also in Component Specific folders.

Accounts Disabled

shows accounts disabled in various components

Common Reports, then Account Management. Also in Component Specific folders.

Accounts Enabled

shows accounts enabled in various components

Common Reports, then Account Management. Also in Component Specific folders.

Accounts Locked Out

shows accounts locked out due to excessive authentication failures

Common Reports, then Account Management. Also in Component Specific folders.

Account Profile History

shows profile changes in accounts, such as change in address and password changes

Common Reports, then Account Management. Also in Component Specific folders.

All Errors and Exceptions

captures all errors and exceptions across components

Common Reports, then Errors and Exceptions. Also in Component Specific folders.

All Events

displays all audit events

Oracle Fusion Middleware Audit. Also in Component Specific folders.

Application Policy Management

displays application level policy management

Component Specific, then Oracle Platform Security Services.

Application Role Management

shows application role to enterprise role mappings

Component Specific, then Oracle Platform Security Services.

Assertion Activity

Assertion Activity in Oracle Identity Federation

Component Specific, then Oracle Identity Federation.

Assertion Template Management

lists assertion Template management operations in Oracle Web Services Manager

Component Specific, then Oracle Web Services Manager, then Policy Management

Authentication Failures

authentication errors and exceptions; can be cross-component or specific to a component.

Common Reports, then Errors and Exceptions. Also in Component Specific folders.

Authentication History

Authentications across all components

Common Reports, then User Activities. Also in Component Specific folders.

Authorization Failures

captures authorization failures

Common Reports, then Errors and Exceptions. Also in Component Specific folders.

Authorization History

Authorizations across all components

Common Reports, then User Activities. Also in Component Specific folders.

Confidentiality Enforcements

lists enforcements related to confidentiality in Oracle Web Services Manager

Component Specific, then Oracle Web Services Manager, then Policy Enforcements

Configuration Changes

configuration changes made in Fusion Middleware Audit Framework.

Component Specific, then Oracle Fusion Middleware Audit Framework

Credential Access

displays credential accesses by users and applications in Oracle Platform Security Services

Component Specific, then Oracle Platform Security Services.

Credential Management

displays credential management operations performed in Oracle Platform Security Services.

Component Specific, then Oracle Platform Security Services.

Federation User Activity

lists federation user activities in Oracle Identity Federation

Component Specific, then Oracle Identity Federation.

Message Integrity Enforcements

shows enforcements related to message integrity in Oracle Web Services Manager

Component Specific, then Oracle Web Services Manager, then Policy Enforcements

Multiple Logins from Same IP

lists machines from where successful logins are made into different user accounts.

Common Reports, then User Activities.

Password Changes

shows password changes done in various accounts.

Common Reports, then Account Management. Also in Component Specific folders.

Policy Attachments

shows Policy to web service endpoint attachments

Component Specific, then Oracle Web Services Manager

Policy Enforcements

general policy enforcements for Oracle Web Services Manager

Component Specific, then Oracle Web Services Manager, then Policy Enforcements

Profile Management Events

shows changes to Directory Integration Platform's profiles.

Component Specific, then Directory Integration Platform.

Request Response

shows requests sent and responses received from web services

Component Specific, then Oracle Web Services Manager

System Policy Management

displays system level policy management operations

Component Specific, then Oracle Platform Security Services.

Violations

Enforcement violations.

Component Specific, then Oracle Web Services Manager, then Policy Enforcements

Web Services Policy Management

shows policy management operations.

Component Specific, then Oracle Web Services Manager, then Policy Management


14.5.2 Attributes of Audit Reports in Oracle Business Intelligence Publisher

Table 14-2 lists the attributes that appear in the various audit reports. When viewing a report, you can use this table to learn more about the attributes that appear in the report.

Note the following:

  • Not all attributes appear in each report.

  • The user or users attribute, which appears in each report, can mean different things in different reports; see Table 14-1 for an explanation of this attribute.

  • Not all the attributes are displayed in Oracle Business Intelligence Publisher audit reports. If you wish to include some additional attributes in your custom reports, see Appendix C, "Oracle Fusion Middleware Audit Framework Reference".

Table 14-2 Attributes of Audit Reports

AttributeDescription

Activity

The type of action, either user- or system-initiated.

Application Name

The complete application path and name.

Application Server Instance

The instance of the application server in use.

Attempted

The action that was attempted, for example, a single sign-on attempted by the user.

Component Name

The name of the component instance.

Component Type

The type of component, for example Oracle Identity Federation.

Domain Name

Oracle WebLogic Server domain name.

ECID

The execution context ID.

Event Type

The type of event that occurred, for example, account creation.

Initiator

The user who initiated the event.

Internet Protocol Address, IP Address

The IP address of the user's machine from which the action was initiated.

Message Text

The text of the message; a description of the event.

Policy Name

The name of the policy involved in the action.

Time Range

The time range which allows you to limit your data set to a specific time interval, for example, the last 24 hours.

Timestamp

The date and time of the event.

Transaction ID

The transaction identifier.


14.6 Customizing Audit Reports

This section discusses advanced report generation and creation options:

14.6.1 Using Advanced Filters on Pre-built Reports

Clicking on the report's Edit button brings up a page at which you can specify more detailed report filters and properties. This page consists of two panels. The left panel lets you select what element of the report is to be modified through these options. For each element you select, the right panel displays the corresponding information.

  • Data Model - This contains the SQL query that fetches the raw data for the report. The query can be modified according to your needs.

  • List of Values - Shows all the report columns. Selecting on a column displays the underlying SQL query that filters data for the attribute. You can modify the query as needed; for example you can specify more restrictive filter values.

  • Parameters - Shows all the report columns, and lets you select any column to modify display settings for that column. For example, you can specify a date display format for timestamp fields.

  • Layouts and output formats - This feature is described in the following section.

14.6.2 Creating Custom Reports

Oracle Business Intelligence Publisher provides a complete set of capabilities for designing and creating custom reports.


See Also:


Here is a simple example illustrating the basic steps to customize an existing audit report with Oracle Business Intelligence Publisher.

  1. Log in to Oracle Business Intelligence Publisher as administrator.

    Surrounding text describes biplogin.gif.
  2. Navigate to the Oracle Fusion Middleware Audit folder.

    Surrounding text describes bipnav.gif.
  3. Create a folder to maintain your custom reports. Under Folder and Event Tasks, click New Folder.

    Enter a folder name.

    Surrounding text describes bipnewfolder.gif.
  4. The new folder, Custom BI Reports, appears on the main audit reports folder.

    Surrounding text describes bipnewmenu.gif.
  5. Select an existing report that will be a starting point to create a custom report, by clicking the icon to the left of the report. In this example the All Events report is selected:

    Surrounding text describes bipcopyreq.gif.

    Click Copy this report.

  6. This action copies the report to the clipboard. To send it to the new folder:

    • Select the Custom BI Reports folder.

    • Under Folder and Report Tasks, click Paste from clipboard.

    • A dialog box appears requesting confirmation. Click Yes.

      Surrounding text describes bipconfcopy.gif.

      The report is now moved from the clipboard to the custom folder:

      Surrounding text describes biprptpasted.gif.
    • Provide a descriptive name for the new report by selecting the icon to the left of the report, and clicking Rename this report.

      Surrounding text describes biprename.gif.
  7. Now you are ready to customize the report. Click Edit from the menu choices under the report title.

  8. The Edit page appears.

    Surrounding text describes bipeditpage.gif.

    Two panels are displayed; on the main panel titled General Settings, you can control basic features like the report title and runtime controls. To the left of the main panel, a second panel displays two sets of information that you can use to create relevant content for your report:

    • List of Values shows the fields that are being used currently in the report. When you click on a field, the main panel automatically displays the name and the SQL query used to select the values to include for that field.

    • Parameters shows the available parameters from which you can choose the ones to include in the report. Notice that a subset of the parameters is already in the report; for example, userid (which is the initiator of the audit event) provides the Users data, while timeRange provides the Time Range data.

    The palette of choices on the left panel is context-sensitive and provides information to help you build the report.

  9. You can use the Query Builder to customize the data to include in your report. For example, to include only login events for a component, you can:

    • Select ComponentName from the list of values and click Query Builder.

      Surrounding text describes bipcname.gif.
    • A table appears listing the available components. Select the component, say JPS. A second table appears showing the component event fields:

      Surrounding text describes bipqb1.gif.
    • In the JPS table select IAU_EVENTTYPE.

      Surrounding text describes bipqb2.gif.
    • Click Conditions, enter the condition login and click Save.

      Surrounding text describes bipqb3.gif.
  10. The condition is now included in the report. Be sure to click Save again on the upper left corner to commit your changes to the report definition.

    Surrounding text describes bipqb4.gif.
  11. You can now return to the report in the Custom BI Reports folder and view the data.

PKPK AOEBPS/title.htm{ Oracle Fusion Middleware Application Security Guide, 11g Release 1 (11.1.1)

Oracle® Fusion Middleware

Application Security Guide

11g Release 1 (11.1.1)

E10043-12

April 2012


Oracle Fusion Middleware Application Security Guide, 11g Release 1 (11.1.1)

E10043-12

Copyright © 2003, 2012, Oracle and/or its affiliates. All rights reserved.

Primary Author:  Carlos Subi

Contributing Author:  Vinaye Misra, Gail Flanegin

Contributor:  Amit Agarwal, Soumya Aithal, Moushmi Banerjee, Andre Correa, Marc Chanliau, Pratik Datta, Jordan Douglas, Guru Dutt, Todd Elwood, Vineet Garg, Vikas Ghorpade, Sandeep Guggilam, Shiang-Jia Huang, Dan Hynes, Michael Khalandovsky, Supriya Kalyanasundaram, Lakshmi Kethana, Ganesh Kirti, Ashish Kolli, Rohit Koul, Nithya Muralidharan, Frank Nimphius, Craig Perez, Sudip Regmi, Bhupindra Singh, Kk Sriramadhesikan, Mamta Suri, Kavita Tippana, Srikant Tirumalai, Ramana Turlapati, Jane Xu, Sam Zhou.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications..

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

This software and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

PKL'F{PK AOEBPS/part_gs.htm Basic OPSS Administration

Part II

Basic OPSS Administration

This part describes basic OPSS administration features in the following chapters:

PKNC PK AOEBPS/openid.htm 6 Using an OpenLDAP Identity Store

J Using an OpenLDAP Identity Store

This appendix describes the special set up required in case the identity store uses OpenLDAP 2.2.

J.1 Using an OpenLDAP Identity Store

To use OpenLDAP 2.2 as an identity store, proceed as follows:

  1. Use the WebLogic Server administration console to create a new authenticator provider. For this new provider:

    • Select OpenLDAPAuthenticator from the list of authenticators.

    • Set the control flag of the OpenLDAPAuthenticator to SUFFICIENT.

    • Set the control flag of the DefaultAuthenticator to SUFFICIENT.

    • Change the order of authenticators to make the OpenLDAPAuthenticator the first in the list.

    • In the Provider Specific page for the OpenLDAPAuthenticator, enter User Base DN and Group Base DN, and set the value of the objectclass in the Group From Name Filter to something other than groupofnames.

  2. From the Home directory of the OpenLDAP installation:

    • Open the file slapd.conf for edit.

    • In that file, insert the following line in the "include" section at the top:

      include ./schema/inetorgperson.schema
      
    • Save the file, and restart the OpenLDAP.

The above settings make possible adding the object class inetorgperson to every new external role you create in the OpenLDAP; this object class is required to map the external role to an application role.

PK0Z PK AOEBPS/apadvadmin.htm Administration with WLST Scripting and MBean Programming

E Administration with WLST Scripting and MBean Programming

This appendix describes advanced administrative tasks carried out with WLST scripts and MBean programming, in the following sections:

E.1 Configuring OPSS Service Provider Instances with a WLST Script

If your application uses the User and Role API and must access an authenticator user attribute different from the default attribute (which is cn), then using the WebLogic Administration Console, you would configure the authenticator to use the desired user attribute. But for the User and Role API to use an attribute different from the default, the authenticator must be, in addition, properly initialized.

The procedure below explains how to use a WLST script to change the authenticator initialization, so that the User and Role API uses the configured user attribute to access data in the configured authenticator.

For details about WebLogic scripting, see Oracle Fusion Middleware Oracle WebLogic Scripting Tool.

To add or update custom properties of a service instance, proceed as follows:

  1. Create a py script file with the following content:

    import sys
    connect('userName','userPass','t3://localHost:portNumber')
    domainRuntime()
    
    val = None
    key = None
    si = None
    for  i in range(len(sys.argv)):
        if sys.argv[i] == "-si":
            si = sys.argv[i+1]
        if sys.argv[i] == "-key":
            key  = sys.argv[i+1]
        if sys.argv[i] == "-value":
            val = sys.argv[i+1]
     
    on = ObjectName("com.oracle.jps:type=JpsConfig")
    sign = ["java.lang.String","java.lang.String","java.lang.String"]
    params = [si,key,val]
    mbs.invoke(on, "updateServiceInstanceProperty", params, sign)
    mbs.invoke(on, "persist", None, None)
    
  2. In the produced script, replace userName, userPass, localHost, and portNumber by the appropriate strings to connect to the administration server in the domain you are interested. Note that the use of connect requires that the server to which you want to connect be up and running when the script is invoked.

    Let's assume that the script is saved in the file /tmp/updateServiceInstanceProperty.py.

  3. Change to the directory $ORACLE_HOME/common/bin, which should contain the file wlst.sh:

    >cd $ORACLE_HOME/common/bin
    
  4. Run the following command:

    >wlst.sh /tmp/updateServiceInstanceProperty.py -si servInstName -key propKey -value propValue
    

    Where:

    • servInstName is the name of the service instance provider whose properties are to be modified.

    • propKey identifies the name of the property to insert or modify.

    • propValue is the name of the value to add or update.

    Any argument containing a space character must be enclosed with double quotes.

    Each invocation of the above command modifies the domain configuration file $DOMAIN_HOME/config/fmwconfig/jps-config.xml by adding or updating a property to the passed instance provider. If the passed key matches the name of an existing property, then that property is updated with the passed value.

  5. Restart the Oracle WebLogic server: the changes in configuration are not in effect until the server has been restarted.

Example of Use

Assume that the domain configuration file contains an authenticator named idstore.ldap. Then the following invocation:

wlst.sh /tmp/updateServiceInstanceProperty.py -si idstore.ldap -key "myPropName" -value "myValue"

adds (or updates) the specified property of that instance provider as illustrated in the following snippet:

<serviceInstance provider="idstore.ldap.provider" name="idstore.ldap">
   ...
   <property name="myPropName" value="myValue"/>
   ...
</serviceInstance>

When the authenticator is initialized with the above configuration, the User and Role API can use the user attribute mail to access user information in this authenticator.

E.2 Configuring OPSS Services with MBeans

Oracle Platform Security Services provides a set of JMX-compliant Java EE Beans that are used by Oracle Enterprise Manager Fusion Middleware Control and OPSS security scripts to manage, configure, and monitor Oracle Platform Security Services.

The use of MBeans is recommended in Java EE applications only.

Links to OPSS API javadocs, including the OPSS MBeans API javadoc, are available in Section H.1, "OPSS API References."

This section addresses the following topics:

E.2.1 List of Supported OPSS MBeans

Table E-1 lists the supported MBeans, their basic function, and the object name to use in custom WLST scripts or Java SE programs to perform a task:

Table E-1 List of OPSS MBeans

MBeanFunctionMBeanServer Connection Name

Jps Configuration

Manages domain configuration data, that is in the file jps-config.xml. This MBean provides the only way to modify configuration data.

Update or write operations require server restart to effect changes.

com.oracle.jps:type=JpsConfig

Credential Store

Manages credential data, that is, the store service configured in the default context.

Update or write operations do not require server restart to effect changes. All changes are effected immediately. Access is restricted to administrators only.

com.oracle.jps:type=JpsCredentialStore

Global Policy Store

Manages global policies in the policy store configured in the default context.

Update or write operations do not require server restart to effect changes. All changes are effected immediately.

com.oracle.jps:type=JpsGlobalPolicyStore

Application Policy Store

Manages application policies in the policy store configured in the default context.

Update or write operations do not require server restart to effect changes. All changes are effected immediately.

com.oracle.jps:type=JpsApplicationPolicyStore

Administration Policy Store

Validates whether a user logged into the current JMX context belongs to a particular role. It does not facilitate any configuration modifications.

com.oracle.jps:type=JpsAdminPolicyStore


E.2.2 Invoking an OPSS MBean

There are two basic ways to invoke an OPSS MBean:


Note:

An alternative way to invoke an MBean is using the MBean browser in Fusion Middleware Control. This approach, however, allows only a limited number of operations and it involves composite data creation.

To access this browser, login to Fusion Middleware Control and then proceed as follows:

  1. Select the menu item AdminServer > System MBean Browser, in the appropriate domain, to display the page System MBean Browser.

  2. In the pane where the hierarchy is displayed, expand the nodes Application Defined MBeans, com.oracle.jps, and Domain: myDomain (where myDomain stands for the name of your domain); this last one has under it one node per OPSS MBean.

  3. After expanding any of those nodes, select an item, that is an MBean, and user the tabs Attributes, Operations, and Notifications in the right pane to inspect current attribute values or to invoke methods in the selected MBean.

For example, the Jps Configuration MBean is found at the following location in this hierarchy:

Application Defined MBeans/com.oracle.jps/Domain:myDomain/JpsConfig/JpsConfig

For complete details about this browser, see the Fusion Middleware Control online help system.


E.2.3 Programming with OPSS MBeans

The following code sample illustrates how to invoke the Jps Configuration MBean over the WebLogic Server t3 protocol; in this sample, note the following important points:

  • It assumes that the following JAR files are in the class path:

    • $ORACLE_HOME/oracle_common/modules/oracle.jps_11.1.1/jps-api.jar

    • $ORACLE_HOME/oracle_common/modules/oracle.jps_11.1.1/jps-mbeans.jar

    • $ORACLE_HOME/oracle_common/modules/oracle.jmx_11.1.1/jmxframework.jar

    • $ORACLE_HOME/oracle_common/modules/oracle.idm_11.1.1/identitystore.jar

    • $WEBLOGIC_HOME/server/lib/wljmxclient.jar

  • The connection is established by the method init.

  • Any update operation is followed by a call to persist.

import java.io.IOException;
import java.net.MalformedURLException;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.HashMap;
import java.util.List;

import javax.management.InstanceNotFoundException;
import javax.management.MBeanException;
import javax.management.MBeanServerConnection;
import javax.management.MalformedObjectNameException;
import javax.management.ObjectName;
import javax.management.ReflectionException;
import javax.management.openmbean.CompositeData;
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;
import javax.naming.Context;
 
import oracle.security.jps.mas.mgmt.jmx.credstore.PortableCredential;
import oracle.security.jps.mas.mgmt.jmx.credstore.PortablePasswordCredential;
import oracle.security.jps.mas.mgmt.jmx.policy.PortableApplicationRole;
import oracle.security.jps.mas.mgmt.jmx.policy.PortableCodeSource;
import oracle.security.jps.mas.mgmt.jmx.policy.PortableGrant;
import oracle.security.jps.mas.mgmt.jmx.policy.PortableGrantee;
import oracle.security.jps.mas.mgmt.jmx.policy.PortablePermission;
import oracle.security.jps.mas.mgmt.jmx.policy.PortablePrincipal;
import oracle.security.jps.mas.mgmt.jmx.policy.PortableRoleMember;
import oracle.security.jps.mas.mgmt.jmx.util.JpsJmxConstants;
 
public class InvokeJpsMbeans {
    private static JMXConnector connector;
    private static MBeanServerConnection wlsMBeanConn;
    private static ObjectName configName;
    private static ObjectName credName;
    private static ObjectName appPolName;
    private static ObjectName gloPolName;
    private static ObjectName adminPolName;

    private final static String STR_NAME =String.class.getName();

    public static void main(String args[]) {
        // Intialize connection and retrieve connection object
        init();

        //Check registration
        if (isRegistered(configName)) 
            System.out.println("Jps Config MBean is registered");
        if (isRegistered(credName))
            System.out.println("Jps Credential Mbean is registered");
        if (isRegistered(appPolName)) 
            System.out.println("Jps Application policy Mbean is registered");
        if (isRegistered(gloPolName))
            System.out.println("Jps Global policy Mbean is registered");
        if (isRegistered(adminPolName)) 
           System.out.println("Jps Admin Policy Mbean is registered");

        //invoke MBeans
        invokeConfigMBeanMethods();
        invokeCredentialMBeanMethods();
        invokeApplicationPolicyMBeanMethods();
        invokeGlobalPolicyMBeanMethods();
        invokeAdminPolicyMBeanMethhods();
    }
    
    private static void invokeConfigMBeanMethods() {
        String KEY = "myKey";
        String VALUE = "myValue";
        String strVal;
        try {
            strVal = (String) wlsMBeanConn.invoke(configName, "updateProperty",
                     new Object[] { KEY, VALUE }, 
                     new String[] { STR_NAME, STR_NAME });
            wlsMBeanConn.invoke(configName,"persist",null,null);

            strVal = (String) wlsMBeanConn.invoke(configName, "getProperty", 
                     new Object[] { KEY }, new String[] { STR_NAME });
            System.out.println("Updated the property: " + strVal.equals(strVal));

            strVal = (String) wlsMBeanConn.invoke(configName, "removeProperty",
                     new Object[] { KEY }, new String[] { STR_NAME });
            wlsMBeanConn.invoke(configName,"persist",null,null);
        } catch (InstanceNotFoundException e) {
            // auto-generated catch block
            e.printStackTrace();
        } catch (MBeanException e) {
            // auto-generated catch block
            e.printStackTrace();
        } catch (ReflectionException e) {
            // auto-generated catch block
            e.printStackTrace();
        } catch (IOException e) {
            // auto-generated catch block
            e.printStackTrace();
        }
    }
 
private static void  invokeCredentialMBeanMethods() {
        
        String USER = "jdoe";
        String PASSWORD = "welcome1";
        String ALIAS = "mapName";
 String KEY = "keyValue";
         
 PortableCredential cred = new PortablePasswordCredential(USER, PASSWORD.toCharArray());
       
  try {
       //seed a password credential
       wlsMBeanConn.invoke(credName, "setPortableCredential", new Object[] { ALIAS, KEY, cred.toCompositeData(null) }, new String[] { STR_NAME, STR_NAME, CompositeData.class.getName() });
        boolean bContainsMap = (Boolean) wlsMBeanConn.invoke(credName, "containsMap", new Object[] { ALIAS }, new String[] { STR_NAME });
        System.out.println("Credstore contains map: " + ALIAS + " - " +bContainsMap);
 
        boolean bContainsCred = (Boolean) wlsMBeanConn.invoke(credName, "containsCredential", new Object[] { ALIAS, KEY }, new String[] { STR_NAME, STR_NAME });
        System.out.println("Contains Credential; " + bContainsCred);
 
        CompositeData cd = (CompositeData) wlsMBeanConn.invoke(credName, "getPortableCredential", new Object[] { ALIAS, KEY }, new String[] { STR_NAME, STR_NAME });
        cred = PortableCredential.from(cd);
 
        PortablePasswordCredential pc = (PortablePasswordCredential) cred;
 
        System.out.println("User name should be " +  USER + " Retrieved - " + pc.getName());
        System.out.println("Password should be " + PASSWORD + "retrieved - " +  new String(pc.getPassword()));
            
        //delete entire map
        wlsMBeanConn.invoke(credName, "deleteCredentialMap", new Object[] {ALIAS}, new String[] {STR_NAME} );
            
        } catch (InstanceNotFoundException e) {
            // auto-generated catch block
            e.printStackTrace();
        } catch (MBeanException e) {
            // auto-generated catch block
            e.printStackTrace();
        } catch (ReflectionException e) {
            // auto-generated catch block
            e.printStackTrace();
        } catch (IOException e) {
            // auto-generated catch block
            e.printStackTrace();
        }
 
    }

private static void invokeApplicationPolicyMBeanMethods() {
        //add grants to approles
        
        //first create application policy
        String TESTGET_APP_ROLES_MEMBERS = "testgetAppRolesMembers";
        try {
            wlsMBeanConn.invoke(appPolName, "deleteApplicationPolicy", new Object[] { TESTGET_APP_ROLES_MEMBERS }, new String[] { STR_NAME });
        } catch (Exception e ) {
            System.out.println("IGNORE: App " + TESTGET_APP_ROLES_MEMBERS + " might not exist");
        }
        try {
            wlsMBeanConn.invoke(appPolName, "createApplicationPolicy", new Object[] { TESTGET_APP_ROLES_MEMBERS }, new String[] { STR_NAME });
            // add remove members to applicaiton roles
            // Create App Role here
            String APP_ROLE_NAME = "ravenclaw_house";
            wlsMBeanConn.invoke(appPolName, "createApplicationRole", new Object[] { TESTGET_APP_ROLES_MEMBERS, APP_ROLE_NAME, null, null, null }, new String[] { STR_NAME, STR_NAME, STR_NAME, STR_NAME, STR_NAME });
            
            CompositeData cd = (CompositeData) wlsMBeanConn.invoke(appPolName, "getApplicationRole", new Object[] { TESTGET_APP_ROLES_MEMBERS, APP_ROLE_NAME }, new String[] { STR_NAME, STR_NAME });
            PortableApplicationRole appRole = PortableApplicationRole.from(cd);
            
            //Add custom principal here
            PortableRoleMember prm_custom = new PortableRoleMember("My.Custom.Principal","CustomPrincipal",null,null,null);
 
            CompositeData[] arrCompData = { prm_custom.toCompositeData(null) };
            cd = (CompositeData) wlsMBeanConn.invoke(appPolName, "addMembersToApplicationRole", new Object[] { TESTGET_APP_ROLES_MEMBERS, appRole.toCompositeData(null), arrCompData }, new String[] { STR_NAME, CompositeData.class.getName(), CompositeData[].class.getName() });
            
            // Chk if member got added
            CompositeData[] arrCD = (CompositeData[]) wlsMBeanConn.invoke(appPolName, "getMembersForApplicationRole", new Object[] { TESTGET_APP_ROLES_MEMBERS, appRole.toCompositeData(null) }, new String[] { STR_NAME, CompositeData.class.getName() });
            PortableRoleMember[] actRM = getRMArrayFromCDArray(arrCD);
            PortableRoleMember[] expRM = { prm_custom};
            chkRoleMemberArrays(actRM, expRM);
 
            cd = (CompositeData) wlsMBeanConn.invoke(appPolName, "removeMembersFromApplicationRole", new Object[] { TESTGET_APP_ROLES_MEMBERS, appRole.toCompositeData(null), arrCompData }, new String[] { STR_NAME, CompositeData.class.getName(), CompositeData[].class.getName() });
 
            // Chk if member got removed
            arrCD = (CompositeData[]) wlsMBeanConn.invoke(appPolName, "getMembersForApplicationRole", new Object[] { TESTGET_APP_ROLES_MEMBERS, appRole.toCompositeData(null) }, new String[] { STR_NAME, CompositeData.class.getName() });
            System.out.println("length should be zero :" + arrCD.length);
 
            // Remove the App Role
            wlsMBeanConn.invoke(appPolName, "removeApplicationRole", new Object[] { TESTGET_APP_ROLES_MEMBERS, APP_ROLE_NAME }, new String[] { STR_NAME, STR_NAME });
            wlsMBeanConn.invoke(appPolName, "deleteApplicationPolicy", new Object[] { TESTGET_APP_ROLES_MEMBERS }, new String[] { STR_NAME });
 
        } catch (InstanceNotFoundException e) {
            // auto-generated catch block
            e.printStackTrace();
        } catch (MBeanException e) {
            // auto-generated catch block
            e.printStackTrace();
        } catch (ReflectionException e) {
            // auto-generated catch block
            e.printStackTrace();
        } catch (IOException e) {
            // auto-generated catch block
            e.printStackTrace();
        }
    }

    private static PortableRoleMember[] getRMArrayFromCDArray(CompositeData[] arrCD) {
        PortableRoleMember[] actRM = new PortableRoleMember[arrCD.length];
        int idx = 0;
        for (CompositeData cdRM : arrCD) {
            actRM[idx++] = PortableRoleMember.from(cdRM);
        }
        return actRM;
    }

    private static void chkRoleMemberArrays(PortableRoleMember[] arrExpectedRM, PortableRoleMember[] arrActRM) {
 
        List < PortableRoleMember > lstExpRM = new ArrayList < PortableRoleMember >(Arrays.asList(arrExpectedRM));
        List < PortableRoleMember > lstActRM = new ArrayList < PortableRoleMember >(Arrays.asList(arrActRM));
 
        for (PortableRoleMember actRM : lstActRM) {
            for (int idx = 0; idx < lstExpRM.size(); idx++) {
                PortableRoleMember expRM = (PortableRoleMember) lstExpRM.get(idx);
                if (expRM.equals(actRM)) {
                    lstExpRM.remove(idx);
                    break;
                }
            }
        }
        System.out.println("List should be empty - " + lstExpRM.size());
    }

    private static void  invokeAdminPolicyMBeanMethhods() {
        //Connection is established as weblogic user, who by OOTB gets all permissions
        Boolean bool;
        try {
            bool = (Boolean) wlsMBeanConn.invoke(adminPolName,"checkRole",new Object[]{"Admin"}, new String[]{STR_NAME});
            System.out.println("Werblogic has Admin role: " + bool);
            bool = (Boolean) wlsMBeanConn.invoke(adminPolName,"checkRole",new Object[] {"Configurator"}, new String[]{STR_NAME});
            System.out.println("Werblogic has Configurator role: " + bool);
            bool = (Boolean) wlsMBeanConn.invoke(adminPolName,"checkRole", new Object[]{new String[] {"Operator", "Admin", "Configurator"}},
                    new String[]{String[].class.getName()});
            System.out.println("Werblogic has Admin,Operator,Configurator role: " + bool);
        } catch (InstanceNotFoundException e) {
            // auto-generated catch block
            e.printStackTrace();
        } catch (MBeanException e) {
            // auto-generated catch block
            e.printStackTrace();
        } catch (ReflectionException e) {
            // auto-generated catch block
            e.printStackTrace();
        } catch (IOException e) {
            // auto-generated catch block
            e.printStackTrace();
        }
    }

    private static void invokeGlobalPolicyMBeanMethods() {
        // lets create a grant in system policy
        PortablePrincipal CUSTOM_JDOE = new PortablePrincipal("oracle.security.jps.internal.core.principals.CustomXmlUserImpl", "jdoe", PortablePrincipal.PrincipalType.CUSTOM);
        PortablePrincipal CUSTOM_APP_ADMINS = new PortablePrincipal("oracle.security.jps.internal.core.principals.CustomXmlEnterpriseRoleImpl", "oc4j-app-administrators", PortablePrincipal.PrincipalType.CUSTOM);
        PortablePrincipal[] arrPrincs = {CUSTOM_JDOE, CUSTOM_APP_ADMINS};
        //code source URL        
        String URL = "http://www.oracle.com/as/jps-api.jar";
        PortableCodeSource pcs = new PortableCodeSource(URL);
        PortableGrantee pge = new PortableGrantee(arrPrincs, pcs);
        PortablePermission CSF_PERM = new PortablePermission("oracle.security.jps.service.credstore.CredentialAccessPermission", "context=SYSTEM,mapName=MY_MAP,keyName=MY_KEY", "read");
        PortablePermission[] arrPerms = {CSF_PERM};
        PortableGrant grnt = new PortableGrant(pge, arrPerms);
        CompositeData[] arrCompData = { grnt.toCompositeData(null) };
        try {
            System.out.println("Creating System Policy grant");
            wlsMBeanConn.invoke(gloPolName, "grantToSystemPolicy", new Object[] { arrCompData }, new String[] { CompositeData[].class.getName() });
            System.out.println("Deleting the created grant");
            wlsMBeanConn.invoke(gloPolName, "revokeFromSystemPolicy", new Object[] { arrCompData }, new String[] { CompositeData[].class.getName() });
            
        } catch (InstanceNotFoundException e) {
            // auto-generated catch block
            e.printStackTrace();
        } catch (MBeanException e) {
            // auto-generated catch block
            e.printStackTrace();
        } catch (ReflectionException e) {
            // auto-generated catch block
            e.printStackTrace();
        } catch (IOException e) {
            // auto-generated catch block
            e.printStackTrace();
        }
    }

    private static boolean isRegistered(ObjectName name) {
        try {
            return wlsMBeanConn.isRegistered(name);
        } catch (IOException e) {
            // auto-generated catch block
            e.printStackTrace();
        }
        return false;
    }
 
    private static void init() {
        String protocol = "t3";
        String jndi_root = "/jndi/";
        String wlserver = "myWLServer";
        String host =  "myHost.com";
        int port =  7001;
        String adminUsername = "myAdminName";
        String adminPassword = "myAdminPassw";
        JMXServiceURL url;
        try {
            url = new JMXServiceURL(protocol,host,port,jndi_root+wlserver);
            HashMap<String, Object> env = new HashMap<String, Object>();
            env.put(Context.SECURITY_PRINCIPAL, adminUsername);
            env.put(Context.SECURITY_CREDENTIALS, adminPassword);
            env.put(JMXConnectorFactory.PROTOCOL_PROVIDER_PACKAGES,
                    "weblogic.management.remote");
            connector = JMXConnectorFactory.connect(url, env);
            wlsMBeanConn = connector.getMBeanServerConnection();
                        //create object names
        // the next string is set to com.oracle.jps:type=JpsConfig
            configName = new
                 ObjectName(JpsJmxConstants.MBEAN_JPS_CONFIG_FUNCTIONAL);
// the next string is set to com.oracle.jps:type=JpsApplicationPolicyStore
            appPolName = new
                 ObjectName(JpsJmxConstants.MBEAN_JPS_APPLICATION_POLICY_STORE);
// the next string is set to com.oracle.jps:type=JpsGlobalPolicyStore
            gloPolName = new
                 ObjectName(JpsJmxConstants.MBEAN_JPS_GLOBAL_POLICY_STORE);
// the next string is set to com.oracle.jps:type=JpsAdminPolicyStore
            adminPolName = new
                 ObjectName(JpsJmxConstants.MBEAN_JPS_ADMIN_POLICY_STORE);
// the next string is set to com.oracle.jps:type=JpsCredentialStore
            credName = new ObjectName(JpsJmxConstants.MBEAN_JPS_CREDENTIAL_STORE);
        } catch (MalformedURLException e) {
            // take proper action
            e.printStackTrace();
        } catch (IOException e) {
            // take proper action
            e.printStackTrace();
        } catch (MalformedObjectNameException e) {
            // auto-generated catch block
            e.printStackTrace();
        }
    }
}

For further details about programmatic configuration of services, see part Part V, "Developing with Oracle Platform Security Services APIs"

E.3 Access Restrictions

The information in this section is not res=3tricted to OPPS MBeans but applies, more generally, to Oracle Fusion Middleware MBeans.

The security access to MBeans is based on logical roles rather than on security permissions. MBeans are annotated using role-based constraints that are enforced at run time by the JMX Framework.

This section illustrates the use of some annotations, describes what they mean, lists the particular access restrictions, and explains the mapping of logical roles to Oracle WebLogic Server enterprise groups.

E.3.1 Annotation Examples

The following code snippet illustrates the use of some enterprise group annotations (in bold text) in an MBean interface:

@Description(resourceKey = "demo.ScreenCustomizerRuntimeMBean.description",
             resourceBundleBaseName = "demo.runtime.Messages")
@ImmutableInfo("true")
@Since("1.1")
public interface ScreenCustomizerRuntimeMXBean {
  @Description(resourceKey = "demo.ScreenCustomizerRuntimeMBean.Active",
               resourceBundleBaseName = "demo.runtime.Messages") 
  @AttrributeGetterRequiredGlobalSecurityRole(GlobalSecurityRole.Operator)
    public boolean isActive();
  @AttrributeSetterRequiredGlobalSecurityRole(GlobalSecurityRole.Admin)
    public void setActive(boolean val);
 
  @Description(resourceKey =
                     "demo.ScreenCustomizerRuntimeMBean.ActiveVirtualScreenId",
               resourceBundleBaseName = "demo.runtime.Messages") 
  @DefaultValue("0")
  @LegalValues( {"0", "2", "4", "6", "8" })
  @RequireRestart(ConfigUptakePolicy.ApplicationRestart) 
  @OperationRequiredGlobalSecurityRole(GlobalSecurityRole.Admin)
     public void setActiveVirtualScreenId(int id) throws IllegalArgumentException;
  …
}

In the above code sample, the annotation:

  • @AtrributeGetterRequiredGlobalSecurityRole specifies that a user must belong to the role Operator to access the get method isActive.

  • @AtrributeSetterRequiredGlobalSecurityRole specifies that a user must belong to the role Admin to access the set method setActive.

  • @OperationRequiredGlobalSecurityRole specifies that a user must belong to the role Admin to access the MBean method setActiveVirtualScreenId.

Note that all three annotations above apply just to a specific item in the interface.

The following code snippet illustrates the use of another annotation (in bold text) with a different scope:

@Description(resourceKey = "demo.ScreenCustomizerRuntimeMBean.description",
             resourceBundleBaseName = "demo.runtime.Messages")
@ImmutableInfo("true")
@Since("1.1")
@MBeanRequiredGlobalSecurityRole(GlobalSecurityRole.Admin)
public interface ScreenCustomizerRuntimeMXBean { … }

In the above code sample, the annotation @MbeanRequiredGlobalSecurityRole specifies that a user must belong to the role Admin to access any operation or attribute of the MBean, that is, its scope is the entire MBean. Annotations with method or attribute scope override annotations that apply to the entire MBean.

The enumeration GlobalSecurityRole defines the set of global, logical roles that are mapped to actual roles in the environment before performing security checks. This enumeration includes the value NONE to indicate that any user has read and write access to the annotated operation or attribute.

For details, see the oracle.jmx.framework Javadoc documentation.

E.3.2 Mapping of Logical Roles to WebLogic Roles

Table E-2 shows the mapping of logical roles to enterprise groups.

Table E-2 Mapping of Logical Roles to WebLogic Groups

Logical RoleDefault PrivilegesWebLogic Group

Admin

Read and write access to all MBeans

Admin

Configurator

Read and write access to configuration MBeans

Admin

Operator

Read access to configuration MBeans; read and write access to all run time MBeans

Operator

Monitor

Read access to all MBeans

Monitor

ApplicationAdmin

Read and write access to all application MBeans

Admin

ApplicationConfigurator

Read and write access to all application MBeans

Admin

ApplicationOperator

Read access to application configuration MBeans; read and write access to application runtime MBeans

Operator

ApplicationMonitor

Read access to all application runtime and configuration MBeans

Monitor


For details about WebLogic roles, see sections Users, Groups, And Security Roles and in Oracle Fusion Middleware Securing Resources Using Roles and Policies for Oracle WebLogic Server.

E.3.3 Particular Access Restrictions

By default, all write and update operations require that the user be a member of the Admin or Configurator roles. In addition, operations annotated with the tag @Impact(value=1) require the user to be a member of the Admin role, and operations annotated with the tag @Impact(value=0) require the user to be a member of the Admin or Operator roles.

Table E-3 describes the roles required to access attributes and operations of Fusion Middleware Control MBeans:

Table E-3 Roles Required per Operation

Operations with impact valueMBean typeRequire any of the roles

INFO or attribute getter

System configuration MBean

Monitor, Operator, Configurator, Admin

INFO or attribute getter

Application configuration MBean

Monitor, Operator, Configurator, Admin, ApplicationMonitor, ApplicationOperator, ApplicationConfigurator, ApplicationAdmin

ACTION, ACTION_INFO, UNKNOWN, or attribute setter

System configuration MBean

Admin, Configurator

ACTION, ACTION_INFO, UNKNOWN, or attribute setter

Application configuration MBean

Admin, Configurator, ApplicationAdmin, ApplicationConfigurator

INFO or attribute getter

System runtime MBean

Monitor, Operator, Configurator, Admin

INFO or attribute getter

Application runtime MBean

Monitor, Operator, Configurator, Admin, ApplicationMonitor, ApplicationOperator, ApplicationAdmin

ACTION, ACTION_INFO, UNKNOWN, or attribute setter

System runtime MBean

Admin, Operator

ACTION, ACTION_INFO, UNKNOWN, or attribute setter

Application runtime MBean

Admin, Operator, ApplicationAdmin, ApplicationOperator


PKlL G=PK A OEBPS/loe.htm 1 List of Examples

List of Examples

PKa PK AOEBPS/polmodel.htm The OPSS Policy Model

20 The OPSS Policy Model

This chapter explains the OPSS policy and authorization models in the following sections:

20.1 The Security Policy Model

For details about the OPSS policy model and the security artifacts used in it, see Oracle Fusion Middleware Administrator's Guide for Oracle Entitlements Server.

20.2 Authorization Overview

This section compares and contrasts the authorization available in the Java EE and the JAAS models, in the following sections:

20.2.1 Introduction to Authorization

A Java 2 policy specifies the permissions granted to signed code loaded from a given location. A JAAS policy extends Java 2 grants by allowing an optional list of principals; permissions are granted only to code from a given location, possibly signed, and run by a user represented by those principals.

The Policy Store is a repository of system and application-specific policies and roles. Application roles can be granted (mapped) to enterprise users and groups specific to the application (such as administrative roles). A policy can grant permissions to any of these roles, groups, or users as principals.

For more details about policy-related security artifacts, see Chapter 3, "Policy Store Basics."

An application can delegate the enforcement of authorization to the container, or it can implement its own enforcement of policy checking with calls to methods such as checkPermission, checkBulkAuthorization, or getGrantedResources.

For details about policy checking with API calls, see Checking Policies.

20.2.2 The Java EE Authorization Model

The Java EE authorization model uses role membership to control access to EJB methods and web resources that are referenced by URLs; policies assign permissions to users and roles, and they are enforced by the container to protect resources.

In the Java EE model, authorization is implemented in either of the following ways:

  • Declaratively, where authorization policies are specified in deployment descriptors; the container reads those policies from deployment descriptors and enforces them. No special application code is required to enforce authorization.

  • Programmatically, where authorization policies are checked in application code; the code checks whether a subject has the appropriate permission to execute specific sections of code. If the subject fails to have the proper permission, the code throws an exception.

Table 20-1 shows the advantages and disadvantages of each approach.

Table 20-1 Comparing Authorization in the Java EE Model

Authorization TypeAdvantagesDisadvantages

Declarative

No coding needed; easy to update by modifying just deployment descriptors.

Authorization is coarse-grained and specified at the URL level or at the method level (for EJBs).

Programmatic

Specified in application code; can protect code at a finer levels of granularity.

Not so easy to update, since it involves code changes and recompilation.


A container can provide authorization to applications running in it in two ways: declaratively and programmatically; these topics and an example are explained in the following sections:

20.2.2.1 Declarative Authorization

Declarative authorization allows to control access to URL-based resources (such as servlets and pages) and methods in EJBs.

The basic steps to configure declarative authorization are the following:

  1. In standard deployment descriptors, specify the resource to protect, such as a web URL or an EJB method, and a logical role that has access to the resource.

    Alternatively, since Java EE 1.5 supports annotations, use code annotations instead of deployment descriptors.

  2. In proprietary deployment descriptors (such as web.xml), map the logical role defined in step 1 to an enterprise group.

For details, see the chapter Using Security Services in Oracle Fusion Middleware Enterprise JavaBeans Developer's Guide for Oracle Containers for Java EE.

20.2.2.2 Programmatic Authorization

Programmatic authorization provides a finer grained authorization than the declarative approach, and it requires that the application code invoke the method isUserInRole (for servlets and JSPs) or the method isCallerInRole (for EJBs), both available from standard Java APIs.

Although these methods still depend on role membership to determine authorization, they give finer control over authorization decisions since the controlling access is not limited at the resource level (EJB method or URL).

20.2.2.3 Java EE Code Example

The following example illustrates a servlet calling the method isUserInRole. It is assumed that the EAR file packing the servlet includes the configuration files web.xml and weblogic-application.xml, and that these files include the following configuration fragments:

web.xml

 <!-- security roles -->
 <security-role>
   <role-name>sr_developer</role-name>
 </security-role>

weblogic-application.xml

The following snippet shows the mapping between the user weblogic and the security role sr_developer:

<wls:security-role-assignment>
  <wls:role-name>sr_developer</wls:role-name>
  <wls:principal-name>weblogic</wls:principal-name>
</wls:security-role-assignment>

Code Example Invoking isUserInRole

import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletOutputStream;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.util.Date;

public class PolicyServlet extends HttpServlet {
 
 public PolicyServlet() {
        super();
    }

 public void init(ServletConfig config)
            throws ServletException {
        super.init(config);
    }

 public void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        final ServletOutputStream out = response.getOutputStream();
 
        response.setContentType("text/html");
        out.println("<HTML><BODY bgcolor=\"#FFFFFF\">");
        out.println("Time stamp: " + new Date().toString());
        out.println( "<br>request.getRemoteUser = " + request.getRemoteUser() + "<br>");
        out.println("request.isUserInRole('sr_developer') = " + request.isUserInRole("sr_developer") + "<br>");
        out.println("request.getUserPrincipal = " + request.getUserPrincipal() + "<br>");
        out.println("</BODY>");
        out.println("</HTML>");
    }
}

20.2.3 The JAAS Authorization Model

The JAAS authorization introduces permissions but can still use the notion of roles. An authorization policy binds permissions with a Subject (role, group, or user) and, optionally, with source code. Granting to a role is achieved through calls to addPrincipalsToAppRole.

Permissions are evaluated by calls to the AccessController, and the model allows fine-grained control to resources.

In this model, an authorization policy specifies the following information:

  • Application roles and enterprise groups.

  • Permissions granted to users, groups, and code sources. For users and groups, they determine what a user or the member of a group is allowed to access. For code sources, they determine what actions the code is allowed to perform.

When programming with this model, sensitive lines of code are preceded with calls to check whether the current user or role is granted the appropriate permissions to access the code. If the user has the appropriate permissions, the code is run. Otherwise, the code throws and exception.

For details about JAAS standard permissions, see http://java.sun.com/Java SE/6/docs/technotes/guides/security/permissions.html.

20.3 The JAAS/OPSS Authorization Model

JAAS/OPSS authorization is based on controlling the operations that a class can perform when it is loaded and run in the environment.

This section is divided into the following sections:

20.3.1 The Resource Catalog

OPSS supports the specification and runtime support of the resource catalog in file-, LDAP-, and DB-based policy stores.

Using the resource catalog provides the following benefits:

  • Describes policies and secured artifacts in human-readable terms.

  • Allows defining and modifying policies independently of and without knowledge of the application source code.

  • Allows browsing and searching secured artifacts.

  • Allows grouping of secured artifacts in building blocks (entitlements or permission sets) which can be later used in authorization policies.

20.3.2 Managing Policies

Resource catalog artifacts can be managed with the policy management API. Specifically, the following interfaces, all subinterfaces of the interface oracle.security.jps.service.policystore.EntityManager, are directly relevant to the artifacts in the resource catalog:

  • GrantManager - This interface includes methods to query grants using search criteria, to obtain list of grants that satisfy various combinations of resource catalog artifacts, and to grant or revoke permissions to principals.

  • PermissionSetManager - This interface includes methods to create, modify, and query permission sets (entitlements).

  • ResourceManager - This interface includes methods to create, delete, and modify resource (instances).

  • ResourceTypeManager - This interface includes methods to create, delete, modify, and query resource types.

For details about these interfaces, see the Javadoc document Oracle Fusion Middleware Java API Reference for Oracle Platform Security Services.

The following code snippet illustrates the creation of a resource type, a resource instance, actions, and a permission set:

import oracle.security.jps.service.policystore.entitymanager.*;
import oracle.security.jps.service.policystore.search.*;
import oracle.security.jps.service.policystore.info.resource.*;
import oracle.security.jps.service.policystore.info.*;
import oracle.security.jps.service.policystore.*;
import java.util.*;
 
public class example {
  public static void main(String[] args) throws Exception {
     ApplicationPolicy ap;

     ResourceTypeManager rtm = ap.getEntityManager(ResourceTypeManager.class);
     ResourceTypeSearchQuery query = new ResourceTypeSearchQuery();
     query.setANDMatch();
     query.addQuery(ResourceTypeSearchQuery.SEARCH_PROPERTY.NAME, false,      ComparatorType.EQUALITY, "resourceType", BaseSearchQuery.MATCHER.EXACT);
     List<ResourceTypeEntry> allResourceTypes = rtm.getResourceTypes(query);

     ResourceManager rm = ap.getEntityManager(ResourceManager.class);
     ResourceSearchQuery ResourceQuery = new ResourceSearchQuery();
     ResourceQuery.setANDMatch();
     ResourceQuery.addQuery(ResourceSearchQuery.SEARCH_PROPERTY.NAME, false,      ComparatorType.EQUALITY, "R2", BaseSearchQuery.MATCHER.EXACT);
     List<ResourceEntry> allResources = rm.getResources("RT2", ResourceQuery);

     PermissionSetManager psm = ap.getEntityManager(PermissionSetManager.class);
     PermissionSetSearchQuery pssq = new PermissionSetSearchQuery();
     pssq.setANDMatch();
     pssq.addQuery(PermissionSetSearchQuery.SEARCH_PROPERTY.NAME, false,      ComparatorType.EQUALITY, "PS1", BaseSearchQuery.MATCHER.EXACT);
     List<PermissionSetEntry> allPermSets = psm.getPermissionSets(pssq);

     RoleCategoryManager rcm = ap.getEntityManager(RoleCategoryManager.class);
     RoleCategorySearchQuery rcsq = new RoleCategorySearchQuery();
     rcsq.setANDMatch();
     rcsq.addQuery(RoleCategorySearchQuery.SEARCH_PROPERTY.NAME, false,      ComparatorType.EQUALITY, "roleCategoryCartoon",      BaseSearchQuery.MATCHER.EXACT);

     List<RoleCategoryEntry> allRoleCategories = rcm.getRoleCategories(rcsq);
  }
}

The following code snippet illustrates a complex query involving resource catalog elements:

//ApplicationPolicy ap as in the preceeding example
ResourceTypeManager rtm = ap.getEntityManager(ResourceTypeManager.class);
ResourceTypeSearchQuery query = new ResourceTypeSearchQuery();
query.setANDMatch();
query.addQuery(ResourceTypeSearchQuery.SEARCH_PROPERTY.NAME, false, ComparatorType.EQUALITY, "resourceType", BaseSearchQuery.MATCHER.EXACT);
List<ResourceTypeEntry> enties = rtm.getResourceTypes(query);
 
ResourceManager rm = ap.getEntityManager(ResourceManager.class);
ResourceSearchQuery ResourceQuery = new ResourceSearchQuery();
ResourceQuery.setANDMatch();
ResourceQuery.addQuery(ResourceSearchQuery.SEARCH_PROPERTY.NAME, false, ComparatorType.EQUALITY, "R2", BaseSearchQuery.MATCHER.EXACT);
ArrayList<BaseSearchQuery> querries = ResourceQuery.getQueries();
List<ResourceEntry> resources = rm.getResources("RT2", ResourceQuery);
 
PermissionSetManager psm = ap.getEntityManager(PermissionSetManager.class);
PermissionSetSearchQuery pssq = new PermissionSetSearchQuery();
pssq.setANDMatch();
pssq.addQuery(PermissionSetSearchQuery.SEARCH_PROPERTY.NAME, false, ComparatorType.EQUALITY, "PS1", BaseSearchQuery.MATCHER.EXACT);
List<PermissionSetEntry> psets = psm.getPermissionSets(pssq);
 
RoleCategoryManager rcm = ap.getEntityManager(RoleCategoryManager.class);
RoleCategorySearchQuery rcsq = new RoleCategorySearchQuery();
rcsq.setANDMatch();
rcsq.addQuery(RoleCategorySearchQuery.SEARCH_PROPERTY.NAME, false, ComparatorType.EQUALITY, "roleCategoryCartoon", BaseSearchQuery.MATCHER.EXACT);
ArrayList<BaseSearchQuery> queries = rcsq.getQueries();
List<RoleCategoryEntry> rcs = rcm.getRoleCategories(rcsq);

The following code sample illustrates how to create a grant:

GrantManager gm = ap.getEntityManager(GrantManager.class);
Set<PrincipalEntry> pe = new HashSet<PrincipalEntry>();
List<AppRoleEntry> are = ap.searchAppRoles(appRoleName);
pe.addAll(are);
gm.grant(pe, null, permissionSetName);

20.3.3 Checking Policies

This section illustrates several ways to check policies programmatically, in the following sections:


Important Note 1:

Authorization failures are not visible, by default, in the console. To have authorization failures sent to the console you must set the system variable jps.auth.debug as follows: -Djps.auth.debug=true

In particular, to have JpsAuth.checkPermission failures sent to the console, you must set the variable as above.



Important Note 2:

The OPSS policy provider must be explicitly set in Java SE applications, as illustrated in the following snippet:

java.security.Policy.setPolicy(new oracle.security.jps.internal.policystore.JavaPolicyProvider()) 

Not setting the policy provider explicitly in a Java SE application may cause runtime methods (such as JpsAuth.checkPermission) to return incorrect values.


20.3.3.1 Using the Method checkPermission

Oracle Fusion Middleware supports the use of the method checkPermission in the classes java.security.AccessController and oracle.security.jps.util.JpsAuth.

Oracle recommends the use of checkPermission in the class JpsAuth because it provides better debugging support, better performance, and audit support.

The static method AccessController.checkPermission uses the default access control context (the context inherited when the thread was created). To check permissions on some other context, call the instance method checkPermission on a particular AccessControlContext instance.

The method checkPermission behaves according to the value of the JAAS mode (see JAAS mode in Chapter 21, "Configuring the Servlet Filter and the EJB Interceptor"), as listed in the following table:

Table 20-2 Behavior of checkPermission According to JAAS Mode

JAAS Mode SettingcheckPermission

off or undefined

Enforces codebase security based on the security policy in effect, and there is no provision for subject-based security.

doAs

Enforces a combination of codebase and subject-based security using the access control context created through the doAs block.

doAsPrivileged

Enforces subject-based security using a null access control context.

subjectOnly

Takes into consideration grants involving principals only (and it disregards those involving codebase) when evaluating a permission.



Note:

If checkPermission is called inside a doAs block and the check permission call fails, to display the failed protection domain you must set the system property java.security.debug=access,failure.


The following example illustrates a servlet checking a permission. It is assumed that the EAR file packing the servlet includes the configuration files jazn-data.xml and web.xml.

jazn-data.xml

The application file-based policy store is as follows:

<?xml version="1.0" ?>
<jazn-data>
  <policy-store>
    <applications>
      <application>
        <name>MyApp</name>
                
        <app-roles>
        <app-role>
          <name>AppRole</name>
          <display-name>AppRole display name</display-name>
          <description>AppRole description</description>
          <guid>F5494E409CFB11DEBFEBC11296284F58</guid>
          <class>oracle.security.jps.service.policystore.ApplicationRole</class>
        </app-role>
      </app-roles>
                
      <role-categories>
        <role-category>
          <name>MyAppRoleCategory</name>
          <display-name>MyAppRoleCategory display name</display-name>
          <description>MyAppRoleCategory description</description>
        </role-category>
      </role-categories>
                
      <resource-types>
        <resource-type>
          <name>MyResourceType</name>
          <display-name>MyResourceType display name</display-name>
          <description>MyResourceType description</description>
          <provider-name>MyResourceType provider</provider-name>
          <matcher-class>oracle.security.jps.ResourcePermission</matcher-class>
          <actions-delimiter>,</actions-delimiter>
          <actions>write,read</actions>
        </resource-type>
      </resource-types>
                
      <resources>
        <resource>
          <name>MyResource</name>
          <display-name>MyResource display name</display-name>
          <description>MyResource description</description>
          <type-name-ref>MyResourceType</type-name-ref>
        </resource>
      </resources>
                
      <permission-sets>
        <permission-set>
          <name>MyEntitlement</name>
          <display-name>MyEntitlement display name</display-name>
          <description>MyEntitlement description</description>
          <member-resources>
            <member-resource>
              <type-name-ref>MyResourceType</type-name-ref>
              <resource-name>MyResource</resource-name>
              <actions>write</actions>
            </member-resource>
          </member-resources>
        </permission-set>
      </permission-sets>
                
      <jazn-policy>
        <grant>
          <grantee>
            <principals>
              <principal>
                <class>
              oracle.security.jps.service.policystore.ApplicationRole</class>
                <name>AppRole</name>
                <guid>F5494E409CFB11DEBFEBC11296284F58</guid>
              </principal>
            </principals>
          </grantee>
                        
          <!-- entitlement-based permissions -->
          <permission-set-refs>
            <permission-set-ref>
              <name>MyEntitlement</name>
            </permission-set-ref>
          </permission-set-refs>
        </grant>
      </jazn-policy>
    </application>      
  </applications>
 </policy-store>
 <jazn-policy></jazn-policy>
</jazn-data>

web.xml

The filter JpsFilter is configured as follows:

<web-app>
 <display-name>PolicyTest: PolicyServlet</display-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>PolicyServlet</param-value>
   </init-param>
  </filter>
  <filter-mapping>
   <filter-name>JpsFilter</filter-name>
   <servlet-name>PolicyServlet</servlet-name>
   <dispatcher>REQUEST</dispatcher>
  </filter-mapping>...

Code Example

In the following example, Subject.doAsPrivileged may be replaced by JpsSubject.doAsPrivileged:

import javax.security.auth.Subject;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletOutputStream;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.io.PrintWriter;
import java.io.StringWriter;
import java.security.*;
import java.util.Date;
import java.util.PropertyPermission;
import java.io.FilePermission;

public class PolicyServlet extends HttpServlet {
 
 public PolicyServlet() {
        super();
    }

 public void init(ServletConfig config)
            throws ServletException {
        super.init(config);
    }

 public void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        final ServletOutputStream out = response.getOutputStream();
 
        response.setContentType("text/html");
        out.println("<HTML><BODY bgcolor=\"#FFFFFF\">");
        out.println("Time stamp: " + new Date().toString());
        out.println( "<b7r>request.getRemoteUser = " + request.getRemoteUser() + "<br>");
        out.println("request.isUserInRole('sr_developer') = " + request.isUserInRole("sr_developer") + "<br>");
        out.println("request.getUserPrincipal = " + request.getUserPrincipal() + "<br>");

 Subject s = null;
        s = Subject.getSubject(AccessController.getContext());
 
        out.println("Subject in servlet " + s);
        out.println("<br>");
        final RuntimePermission rtPerm = new RuntimePermission("getClassLoader");
 try {
 Subject.doAsPrivileged(s, new PrivilegedAction() {
                public Object run() {
                    try {
                        AccessController.checkPermission(rtPerm);
                        out.println("<br>");
                        out.println("CheckPermission passed for permission: " + rtPerm+ " seeded in application policy");
                        out.println("<br>");
                    } catch (IOException e) {
                        e.printStackTrace();
                        printException ("IOException", e, out);
                    } catch (AccessControlException ace) {
                        ace.printStackTrace();
                        printException ("Accesscontrol Exception", ace, out);
                    }
                    return null;
                }
            }, null);

} catch (Throwable e) {
            e.printStackTrace();
            printException("application policy check failed", e, out);
        }
        out.println("</BODY>");
        out.println("</HTML>");
    }

 void printException(String msg, Throwable e, ServletOutputStream out) {
        Throwable t;
        try {
            StringWriter sw = new StringWriter();
            PrintWriter pw = new PrintWriter(sw, true);
            e.printStackTrace(pw);
 
            out.println("<p>" + msg + "<p>");
            out.println("<code>");
            out.println(sw.getBuffer().toString());
            t = e;
            /* Print the root cause */
            while ((t = t.getCause()) != null) {
                sw = new StringWriter();
                pw = new PrintWriter(sw, true);
                t.printStackTrace(pw);
 
                out.println("<hr>");
                out.println("<p>  Caused By ... </p>");
                out.println(sw.getBuffer().toString());
            }
            out.println("</code><p>");
        } catch (IOException ioe) {
            ioe.printStackTrace();
        }
    }
}

20.3.3.2 Using the Methods doAs and doAsPrivileged

Oracle Fusion Middleware supports the methods doAs and doAsPrivileged in the standard class javax.security.auth.Subject.

Oracle recommends, however, the use of these methods in the class oracle.security.jps.util.JpsSubject because they render better performance and provide auditing.


Note:

If checkPermission is called inside a doAs block and the check permission call fails, to display the failed protection domain you must set the system property java.security.debug=access,failure.


20.3.3.3 Using the Method checkBulkAuthorization

The method checkBulkAuthorization determines whether a Subject has access to one or more resource actions. Specifically, the method returns the set of resource actions the passed Subject is authorized to access in the passed resources.

When invoking this method (in a Java SE application), make sure that:

  1. The system property java.security.policy has been set to the location of the OPSS/Oracle WebLogic Server policy file.

  2. Your application must call first the method setPolicy to explicitly set the policy provider, as illustrated in the following lines:

    java.security.Policy.setPolicy(new oracle.security.jps.internal.policystore.JavaPolicyProvider())
    
  3. Your application calls checkBulkAuthorization() after the call to setPolicy.

In any application, checkBulkAuthorization assumes that the caller can provide:

  • A Subject with User and Enterprise Role Principals.

  • A list of resources including the stripe each resource belongs to.

Grants using resource permissions must include the required resource type.

checkBulkAuthorization also assumes that the application has visibility into the policy store stripes configured in the domain where the application is running.

checkBulkAuthorization does not require resources to be present in the policy store.

20.3.3.4 Using the Method getGrantedResources

The method getGrantedResources provides a runtime authorization query to fetch all granted resources on a given Subject by returning the resource actions that have been granted to the Subject; only permissions associated with resource types (directly or indirectly through permission sets) are returned by this method, and it is available only when the policy store is LDAP-based.

20.3.4 The Class ResourcePermission

A permission class provides the means to control the actions that a grantee is allowed on a resource. Even though a custom permission class provides the application designer complete control over the actions, target matching, and the "implies" logic, to work as expected at runtime, a custom permission class must be specified in the system classpath of the server so that it is available and can be loaded when required. But modifying the system class path in environments is difficult and, in some environments, such modification might not be even possible.

OPSS includes the class oracle.security.jps.ResourcePermission that can be used as the permission class within any application grant to protect application or system resources. Therefore, the application developer no longer needs to write custom permission classes, since the class ResourcePermission is available out-of-the-box and can be readily used in permissions within application grants stored in any supported policy provider. This class is not designed to be used in system policies, but only in application policies.

Configuring Resource Permissions

A permission that uses the class ResourcePermission is called a resource permission, and it specifies the resource type, the resource name, and an optional list of actions according to the format illustrated in the following XML sample:

<permission>
  <class>oracle.security.jps.ResourcePermission</class>
  <name>resourceType=type,resourceName=name</name>
  <actions>character-separated-list-of-actions</actions>
</permission>

The above specification requires that the resource type encoded in the type name be defined. Even though the resource type information is not used at runtime, its definition must be present for a resource permission to be migrated successfully; moreover, resource types help administrators model resources and manage their use.

The following fragments illustrate the specifications of resource permissions and the corresponding required resource types:

<permission>
  <class>oracle.security.jps.ResourcePermission</class>
  <name>resourceType=epm.calcmgr.permission,resourceName=EPM_Calc_Manager</name>
</permission>

<resource-types>
  <resource-type>
    <name>epm.calcmgr.permission</name>
    <display-name>CalcManager ResourceType</display-name>
    <description>Resourcetype for managing CalcManager grants</description>
    <provider-name></provider-name>
    <matcher-class>oracle.security.jps.ResourcePermission</matcher-class>
    <actions-delimiter>,</actions-delimiter>
    <actions></actions>
  </resource-type>
</resource-types>

<permission>
  <class>oracle.security.jps.ResourcePermission</class>
  <name>resourceType=oracle.bi.publisher.Reports,resourceName=GLReports</name>
  <actions>develop;schedule</actions>
</permission>

<resource-types>
  <resource-type>
    <name>oracle.bi.publisher.Reports</name>
    <display-name>BI Publisher Reports</display-name>
    <provider-name></provider-name>
    <matcher-class>oracle.security.jps.ResourcePermission</matcher-class>
    <actions-delimiter>;</actions-delimiter>
    <actions>view;develop;schedule</actions>
  </resource-type>
</resource-types>

Note that a resource type associated with a resource permission can have an empty list of actions. The following important points apply to a resource permission:

  • The name must conform to the following format:

    resourceType=aType,resourceName=aName
    

    The resource type of a resource permission must be defined and it is returned by the method ResourcePermission.getType().

  • The character-separated list of actions is optional; if specified, it must be a subset of the actions specified in the associated resource type. This list is returned by the method ResourcePermission.getActions().

    The character used to separate the items of the list must equal to the character specified in the <actions-delimiter> of the associated resource type.

  • The display name of a resource used in a permission is returned by the method ResourcePermission.getResourceName().

  • No wildcard use is supported in a resource permission.

Managing and Checking Resource Permissions

The code snippet below illustrates the instantiation of a resource permission and how to check it programmatically; the following code snippet is based on one of the configuration examples described in Configuring Resource Permissions:

ResourcePermission rp = 
   new ResourcePermission("oracle.bi.publisher.Reports","GLReports","develop");
JpsAuth.checkPermission(rp);
 

At runtime the permission check will succeed if the resource permission satisfies all the following four conditions:

  • The permission is an instance of the class ResourcePermision.

  • The resource type name (first argument) matches (ignoring case) the name of a resource type.

  • The resource (second argument) name matches exactly the name of a resource instance.

  • The list of actions (third argument) is a comma-separated subset of the set of actions specified in the resource type.

About the Matcher Class for a Resource Type

When creating a resource type, a matcher class can be optionally supplied. If unspecified, it defaults to oracle.security.jps.ResourcePermission.

If, however, two or more resource types are to share the same resource matcher class, then that class must be one of the following:

  • The class oracle.security.jps.ResourcePermission.

  • A concrete class extending the abstract class oracle.security.jps.AbstractTypedPermission, as illustrated by the class MyAbstractTypedPermission in the following sample:

    public class MyAbstractTypedPermission extends AbstractTypedPermission {
       private static final long serialVersionUID = 8665318227676708586L;
       public MyAbstractTypedPermission(String resourceType, 
                                        String resourceName,                                     String actions) {super(resourceType, resourceName, actions);
        }
    }
    
  • A class implementing the class oracle.security.jps.TypePermission and extending the class java.security.Permission.

PKڥPK AOEBPS/part_osso.htm Single Sign-On Configuration

Part IV

Single Sign-On Configuration

This part describes how to configure single sign-on in Oracle Fusion Middleware in the following chapters:

PKaPK AOEBPS/osso_a_intro.htm Introduction to Single Sign-On in Oracle Fusion Middleware

15 Introduction to Single Sign-On in Oracle Fusion Middleware

The chapter outlines a set of recommended single sign-on solutions for Oracle Fusion Middleware. This chapter includes the following major sections:

15.1 Choosing the Right SSO Solution for Your Deployment

Oracle Platform Security Services comprise Oracle WebLogic Server's internal security framework. A WebLogic domain uses a separate software component called an Authentication Provider to store, transport, and provide access to security data. Authentication Providers can use different types of systems to store security data. The Authentication Provider that WebLogic Server installs uses an embedded LDAP server.

Oracle Fusion Middleware 11g supports new single sign-on solutions that applications can use to establish and enforce perimeter authentication:

  • Oracle Access Manager solutions

  • Oracle Single Sign-On (OSSO) solution

Customers must carefully choose the solution appropriate to their needs. Selecting the right SSO solution requires careful consideration and depends upon your requirements. This section outlines some general information and guidelines to help you choose the best solution for your needs.


Note:

Oracle recommends that you consider upgrading to Oracle Access Manager 11g Single Sign on solution to take advantage of additional functionality and architecture.


15.2 Introduction: OAM Authentication Provider for WebLogic Server

Unless explicitly stated, information here applies equally to both Oracle Access Manager 11g and 10g deployments.

The Oracle Access Manager Authentication Provider is one of several Providers that operate with Oracle WebLogic Server. The Oracle Access Manager Authentication Provider does not require the entire Oracle WebLogic Suite nor Oracle Java Required Files (JRF) to operate with Oracle Access Manager 11g or 10g.

In a WebLogic Server domain where JRF is installed, the JRF template is present as part of the domain in an Oracle Fusion Middleware product. In this case, the OAM Identity Asserter and OAM Authentication Provider are automatically available for configuration. If JRF is not installed in your WebLogic domain, you must add the OAMAuthnProvider.jar to a specific location in your domain as described later.


Note:

The JRF template is present as part of the domain in an Oracle Fusion Middleware product.


You can use the OAM Authentication Provider for WebLogic Server when you have:

  • Applications that are (or will be) deployed in a WebLogic container outside the Identity Management domain

  • WebGate is (or will be) deployed in front of the Authentication Provider

The Authentication Provider can be configured to provide either (or both) of the following functions for WebLogic users:

  • Identity Asserter for Single Sign-on function

  • Authenticator function

Identity Asserter for Single Sign-on Function

When the application is protected using a perimeter Webgate, the identity of the authenticated user that is communicated to the WebLogic Server is made available to container security layers using the Oracle Access Manager identity asserter. The Identity Asserter only asserts the incoming identity and then passes control to the configured Authentication Providers to continue with the rest of the authentication process (populating the subject with the right principals).


Note:

A Web-only applications implementation handles nearly all SSO use cases. The exception is when you have Oracle Web Services Manager protected Web services. In this case, there is no trusted WebGate. Instead the AccessGate provided with the Identity Asserter is contacted and interacts with your OAM 10g Access Server or 11g OAM Server; all other processing is essentially the same.


Oracle provides the following mechanisms, each with slightly different characteristics and requirements:

  • Trusted Header Assertion: This newest mechanism, for use with Oracle Access Manager 11.1.1.5.2 or later (and either a 10g or 11g Webgate), is triggered for the OAM_IDENTITY_ASSERTION token present for applications protected by 11g or 10g WebGate. This provides maximum security and is easy to configure.

  • Clear Text Header: This default mechanism is triggered for the OAM_REMOTE_USER token present for applications protected by 10g or 11g WebGate.

  • Session Token: This mechanism is available for use with only perimeter 10g Webgates and either the 10g Access Server or 11g OAM Server.

Table 15-1 lists the benefits and requirements for each.

Table 15-1 Summary: Identity Assertion Mechanisms for Oracle Access Manager

MechanismBenefitsRequirements

Trusted Header Assertion

OAM_IDENTITY_ASSERTION

Maximum security

Easy configuration

Oracle Access Manager 11.1.1.5.2 or later

10g or 11g Webgate

Clear Text Header

OAM_REMOTE_USER

Maximum performance

Default Mechanism

Oracle Access Manager 11.1.1.5.0

10g or 11g Webgate

Session Token (ObSSOCookie)

To be deprecated

10g Webgate with either OAM 10g or 11g Server

Oracle Access Manager 11.1.1.3.0

Oracle Access Manager 10.1.4.3

10g Webgate


Authenticator Function

The Authenticator function does not provide single sign-on. The Authenticator requests credentials from the user based on the authentication method specified in the application configuration file, web.xml, not according to the Oracle Access Manager authentication scheme. However, an Oracle Access Manager authentication scheme is required for the application domain.


Note:

You can skip this topic if you are using the Identity Asserter function.


For more information, see the following topics:

15.2.1 About Using the Identity Asserter Function with Oracle Access Manager

This topic describes and illustrates the use of the Identity Asserter function with Oracle Access Manager 11g and 10g WebGates. Processing is similar, with few exceptions, whether you have OAM 11g with 11g (or 10g) WebGates or OAM 10g with 10g WebGates). For instance, with Oracle Access Manager 11g, the Access Server is known as the OAM Server.

All requests are first routed to a reverse proxy Web server and requests are intercepted by WebGate. The user is challenged for credentials based on the authentication scheme that is configured within Oracle Access Manager. Oracle recommends Form (form-based login) as the authentication scheme.

The Identity Asserter function relies on perimeter authentication performed by WebGate on the Web Tier. Triggering the Identity Asserter function requires the appropriate chosen Active Type for your WebGate release.

After triggering the Identity Asserter function, configured Authentication Providers (Login Modules) for constructing the Subject and populating it with the appropriate Principals are invoked.


Note:

The only difference between using the Identity Asserter function with 11g WebGates versus 10g WebGates is the provider's chosen Active Type.


Chosen Active Types

The Identity Asserter function's Active Type configuration parameter lists supported values under the Available UI section. One of the following must be selected as the "Chosen" type to trigger the Identity Asserter function:

  • Identity Assertion: Triggers Identity Assertion based on the trusted header OAM_IDENTITY_ASSERTION.

  • OAM_REMOTE_USER: Triggers Identity Assertion based on OAM_REMOTE_USER header.

  • ObSSOCookie: Triggers Identity Assertion based on the obSSOCookie.

OAM_REMOTE_USER header includes the uid of the logged in user. Configuring OAM_REMOTE_USER as the chosen Active Type for the Identity Asserter requires Oracle Access Manager policies that set OAM_REMOTE_USER as part of the authorization success response headers.

Authentication Processing and the Identity Assertion Function

Unless explicitly stated, information here applies equally to Oracle Access Manager 11g and Oracle Access Manager 10g.

WebGate, using the configured authentication scheme, authenticates the user, and then:

  • WebGate:

    11g WebGate sets the OAMAuthnCookie and triggers the token (either OAM_IDENTITY_ASSERTION or OAM_REMOTE_USER).

    10g WebGate triggers assertion based on the obSSOCookie or OAM_REMOTE_USER or OAM_IDENTITY_ASSERTION are possible

  • The OHS Web server mod_weblogic module forwards the request to Oracle WebLogic Server


    Note:

    mod_weblogic is the generic name of the WebLogic Server plug-in for Apache. For Oracle HTTP Server 11g, the name of this plug-in is mod_wl_ohs; the actual binary name is mod_wl_ohs.so.


  • The Identity Asserter is invoked when the configured Active token type is present in the request coming into the container: OAM_REMOTE_USER (default), obSSOCookie, OAM_IDENTITY_ASSERTION.

  • After Assertion Processing: Authentication Providers configured in the security realm are invoked to populate the 'Subject' with Principals (Users and Groups)

Figure 15-1, and the overview that follows, describe processing between components when the Identity Asserter function is used with Web-only applications. This implementation handles nearly all SSO use cases. Exception: Oracle Web Services Manager protected Web services. In this case, there is no trusted WebGate. Instead the AccessGate provided with the Identity Asserter (dotted line in Figure 15-1) is contacted and interacts with the 11g OAM Server (or 10g OAM Access Server); all other processing is essentially the same.

For more information, see "Oracle Access Manager Authentication Provider Parameter List".

Figure 15-1 illustrates the processing overview using the Identity Asserter configuration with Oracle Access Manager 11g and

Figure 15-1 Identity Asserter Configuration with Oracle Access Manager and WebGates

Surrounding text describes Figure 15-1 .

Assertion takes place based on which token type is configured in the authorization policy. Alone, the presence of token in the request is not sufficient to invoke the asserter. Simply configuring a particular active token type in WebLogic is not sufficient OAM_IDENTITY_ASSERTION will be set in the request if it is configured in the authorization policy.

Process overview: Identity Assertion with OAM 11g, 11g WebGate, and Web-only applications

  1. A user attempts to access an Oracle Access Manager protected Web application that is deployed on the Oracle WebLogic Server.

  2. WebGate on a reverse proxy Web server intercepts the request and queries the OAM Server to determine whether the requested resource is protected.

  3. If the requested resource is protected, WebGate challenges the user for credentials based on the type of Oracle Access Manager authentication scheme configured for the resource (Oracle recommends Form Login). The user presents credentials such as user name and password.

  4. WebGate forwards the authentication request to the OAM Server.

  5. OAM 11g Server validates user credentials against the primary user identity store and returns the response to WebGate (OAM 10g Access Server validates user credentials against configured user directories). Upon:

    • Successful Authentication: Processing continues with Step 6.

    • Authentication Not Successful: The login form appears asking the user for credentials again; no error is reported.

  6. OAM Server generates the session token and sends it to the WebGate:

    11g WebGate: Sets and returns the OAMAuthn cookie and triggers the OAM_REMOTE_USER (or OAM_IDENTITY_ASSERTER) token when policies are configured for this.

    10g WebGate: Sets and returns OAM_REMOTE_USER or OAM_IDENTITY_ASSERTION headers in the request when policies are configured for this.

    The Web server forwards this request to the proxy, which in turn forwards the request to the Oracle WebLogic Server using the mod_weblogic plug-in.

    mod_weblogic forwards requests as directed by its configuration.


    Note:

    mod_weblogic is the generic name of the WebLogic Server plug-in for Apache For Oracle HTTP Server 11g, the name of this plug-in is mod_wl_ohs.


  7. WebLogic Server security service invokes the Oracle Access Manager Identity Asserter which is configured to accept tokens of type "OAM_REMOTE_USER" (or "OAM_\SIDENTITY_ASSERTER"). The Identity Asserter initializes a CallbackHandler with the header. In addition, the Identity Asserter sets up NameCallback with the username for downstream LoginModules.

  8. Oracle WebLogic Security service authorizes the user and allows access to the requested resource.

  9. A response is sent back to the reverse proxy Web server.

  10. A response is sent back to the browser.

15.2.2 About Using the Authenticator Function with Oracle Access Manager

This topic describes and illustrates use of the Authenticator configured to protect access to Web and non-Web resources with Oracle Access Manager.


Note:

Unless explicitly stated, information applies equally to Oracle Access Manager 11g and Oracle Access Manager 10g.


The Authenticator function relies on Oracle Access Manager services to authenticate users who access applications deployed in WebLogic Server. Users are authenticated based on their credentials, such as a user name and password.

When a user attempts to access a protected resource, the Oracle WebLogic Server challenges the user for credentials according to the authentication method specified in the application's web.xml file. Oracle WebLogic Server then invokes the Authentication Provider, which passes the credentials to Oracle Access Manager Access Server for validation through the enterprise directory server.

Figure 15-2 illustrates the distribution of components and flow of information for Oracle Access Manager authentication for Web and non-Web resources. Details follow the figure. In this case, the Authenticator communicates with the 11g OAM Server (or the OAM 10g Access Server) through a custom AccessGate.

Figure 15-2 Authenticator for Web and non-Web Resources

OAM Authentication for Web and non-Web Resources
Description of "Figure 15-2 Authenticator for Web and non-Web Resources"

Process overview: Authenticator Function for Web and non-Web Resources

  1. A user attempts to access a Java EE application (secured with the authentication mechanism in the application's web.xml file) that is deployed on the Oracle WebLogic Server.

  2. Oracle WebLogic Server intercepts the request.

  3. Oracle Access Manager Authentication Provider LoginModule is invoked by the Oracle WebLogic security service. The LoginModule uses the OAP library to communicate with the 11g OAM Server (or 10g Access Server) and validate the user credentials.

    • If the user identity is authenticated successfully, WLSUserImpl and WLSGroupImpl principals are populated in the Subject.

    • If Oracle Access Manager LoginModule fails to authenticate the identity of the user, it returns a LoginException (authentication failure) and the user is not allowed to access the Oracle WebLogic resource.

  4. Oracle Access Manager Authenticator supports Oracle WebLogic Server UserNameAssertion.

  5. Oracle Access Manager Authenticator can be used with any Identity Asserter. In this case, the Oracle Access Manager Authenticator performs user name resolution and gets the roles and groups associated with the user name.

15.2.3 Choosing Applications for Oracle Access Manager SSO Scenarios and Solutions

This section introduces choosing applications to use Oracle Access Manager and the Authentication Provider according to current application setup. Details are similar whether you plan to use Oracle Access Manager 11g or 10g with the Authentication Provider:

15.2.3.1 Applications Using Oracle Access Manager for the First TIme

If your application is to use Oracle Access Manager Authentication Provider for the first time, proceed based on the functionality that you want to use:

15.2.3.2 Applications Migrating from Oracle Application Server to Oracle WebLogic Server

If your application has been deployed on the old Oracle Application Server (OC4J), you can perform a few steps to make the application use the Authentication provider with Oracle WebLogic Server, proceed as follows:

15.2.3.3 Applications Using OAM Security Provider for WebLogic SSPI

The Oracle Access Manager Security Provider for WebLogic SSPI provides authentication, authorization, and single sign-on across Java EE applications that are deployed in the WebLogic platform. The Security Provider for WebLogic SSPI enables WebLogic administrators to use Oracle Access Manager to control user access to business applications.


Note:

Security Provider for WebLogic SSPI is also known as "Security Provider" in the 10g (10.1.4.3) Oracle Access Manager Integration Guide.


The Oracle Access Manager Security Provider for WebLogic SSPI provides authentication to Oracle WebLogic Portal resources and supports single sign-on between Oracle Access Manager and Oracle WebLogic Portal Web applications. Apart from this, the Security Provider for WebLogic SSPI also offers user and group management functions.

The Oracle Access Manager Authentication Provider is more easily installed and configured than the Security Provider for WebLogic SSPI. The Authentication Provider offers authentication and single sign-on (SSO) services, and also works with all platforms supported by Oracle WebLogic Server.

If your application has been using the Oracle Access Manager Security Provider for WebLogic SSPI for only authentication and SSO, the deployment is a good candidate for the latest Authentication Provider. However, if your application relies on features other than those offered by the latest Oracle Access Manager Authentication Provider, you can continue to use the Oracle Access Manager 10g Security Provider for WebLogic SSPI.


Note:

WebLogic SSPI connector can be used with Oracle Access Manager 10g but is not supported with Oracle Access Manager 11g


15.2.4 Implementation: Using the Provider with OAM 11g versus OAM 10g

With a very few differences, implementing solutions is similar whether you are using OAM 11g or OAM 10g to protect for applications in a WebLogic container.

Table 15-2 outlines the differences when deploying the Authentication Provider with OAM 11g versus OAM 10g. Topic headings are highlighted.

Table 15-2 Differences in Authentication Provider Implementation Tasks for OAM 11g versus OAM 10g

OAM 11g Implementation DetailsOAM 10g Implementation Details

Included in the OAM 11g implementation are the following tasks, which are described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service:

Tasks for implementing SSO solutions with OAM 10g are described in this chapter:


15.2.5 Requirements for the Provider with Oracle Access Manager

The required components and files for implementing the Authentication Provider are nearly identical whether you have OAM 11g or OAM 10g as the SSO solution. The few exceptions are noted in the following list:

  • An enterprise directory server (Oracle Internet Directory or Oracle Sun One directory server) for Oracle Access Manager and Oracle WebLogic Server.

  • Oracle WebLogic Server 10.3.1+ to be configured to use the Oracle Access Manager Authentication Provider as described later in this chapter.

  • Optional: A Fusion Middleware product (Oracle Identity Manager, Oracle SOA Suite, or Oracle Web Center for example).

  • Authentication Provider: For applications deployed in a WebLogic container, Oracle Access Manager JAR are WAR files are available when you install an Oracle Fusion Middleware product (Oracle Identity Management, Oracle SOA Suite, or Oracle WebCenter).


    Note:

    With a stand-alone Oracle WebLogic Server (no Fusion Middleware), you must obtain the Authentication Provider JAR and WAR files from Oracle Technology Network as described in Step 1 of procedures later in this chapter.


    • oamAuthnProvider.jar: Includes files for both the Oracle Access Manager Identity Asserter for single sign-on and the Authenticator for Oracle WebLogic Server 10.3.1+. A custom Oracle Access Manager AccessGate is also provided to process requests for Web and non-Web resources (non-HTTP) from users or applications.

    • oamauthenticationprovider.war: Restricts the list of providers that you see in the Oracle WebLogic Server Console to only those needed for use with Oracle Access Manager.

      When you deploy the extension, the WebLogic Administration Console creates an in-memory union of the files and directories in its WAR file with the files and directories in the extension WAR file. Once the extension is deployed, it is a full member of the WebLogic Administration Console: it is secured by the WebLogic Server security realm, it can navigate to other sections of the Administration Console, and when the extension modifies WebLogic Server resources, it participates in the change control process For more information, see the Oracle Fusion Middleware Extending the Administration Console for Oracle WebLogic Server.

    • Oracle Access Manager 11g: A remote registration command-line utility streamlines WebGate provisioning and creates a fresh application domain with security policies. Administrators can specify WebGate parameters and values using a template.

    • Oracle Access Manager 10g: The platform-agnostic OAMCfgTool and scripts (oamcfgtool.jar) automate creation of the Oracle Access Manager form-based authentication scheme, policy domain, access policies, and WebGate profile for the Identity Asserter for single sign-on. OAMCfgTool requires JRE 1.5 or 1.6. Internationalized login forms for Fusion Middleware applications are supported with the policies protecting those applications.

  • OHS 11g must be configured as a reverse proxy for the WebGate (required by the Oracle Access Manager Identity Asserter)

  • Oracle Access Manager:

    OAM 11g: Deployed with initial configuration using the Oracle Fusion Middleware Configuration Wizard, as described in Oracle Fusion Middleware Installation Guide for Oracle Identity Management. See "Deploying the Oracle Access Manager 11g SSO Solution".

    OAM 10g: Installed with initial setup as described in Oracle Access Manager Installation Guide. See "Deploying SSO Solutions with Oracle Access Manager 10g".

  • WebGate/AccessGate: Whether you need to provision a WebGate or an AccessGate with Oracle Access Manager depends on your use of the OAM Authentication Provider:

    Identity Asserter for Single Sign-On: Requires a separate WebGate for each application to define perimeter authentication.

    Authenticator (or Oracle Web Services Manager): Requires the custom 10g AccessGate that is available with the Authentication Provider.

15.3 Setting Up Debugging in the WebLogic Administration Console

The Authentication Providers use messages with verbose descriptions of low-level activity within the application when Debug mode issued. Ordinarily, you do not need this much information. However, if you must call Oracle Support, you might be advised to set up debugging. When set, Authentication Providers messages appear in the Oracle WebLogic Server default log location.

To set up debugging

  1. Log into WebLogic Administration Console.

  2. Go to Domain, Environment, Servers, yourserver.

  3. Click the Debug tab.

  4. Under Debug Settings for this Server, click to expand the following: weblogic, security, atn.

  5. Click the option beside DebugSecurityAtn to enable it.

  6. Save Changes.

  7. Restart the Oracle WebLogic Server.

  8. In the Oracle WebLogic Server default log location, search for SSOAssertionProvider. For example:

    ####<Apr 10, 2009 2:32:16 AM PDT> <Debug> <SecurityAtn> <sta00483> <AdminServer> <[ACTIVE] 
    ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> 
    <<WLS Kernel>> <> <> <1239355936490> <BEA-000000> 
    <SSOAssertionProvider:Type          = Proxy-Remote-User>
    
PKGPK AOEBPS/devmancfg.htm Manually Configuring Java EE Applications to Use OPSS

21 Manually Configuring Java EE Applications to Use OPSS

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:

21.1 Configuring the Servlet Filter and the EJB Interceptor

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.

Application Name (Stripe)

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.

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

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

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

21.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 21-1 Summary of JpsFilter and JpsInterceptor Parameters

Parameter NameValuesDefaultFunctionNotes

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.



21.1.3 Configuring the Application Stripe for Application MBeans

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>

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

21.3 Packaging a Java EE Application Manually

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.


21.3.1 Packaging Policies with Application

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.

21.3.2 Packaging Credentials with Application

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.

21.4 Configuring Applications to Use OPSS

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.


21.4.1 Parameters Controlling Policy Migration

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:

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.


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.

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.

jps.policystore.applicationid

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>

jps.policystore.removal

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.

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

21.4.2.1 To Skip Migrating All Policies

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.

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

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

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

21.4.2.5 To Migrate Policies in a Static Deployment

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.

Table 21-8 Settings Not to Migrate Policies with Static Deployments

JpsApplicationLifecycleListener

Set

jps.policystore.migration

OFF


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

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

21.4.4 Parameters Controlling Credential Migration

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.

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.

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>

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


21.4.5.1 To Skip Migrating Credentials

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

Table 21-9 Settings to Skip Credential Migration


Valid at deploy or redeploy

jps.credstore.migration

OFF


21.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 21-10 Settings to Migrate Credentials with Merging


Valid at deploy or redeploy

JpsApplicationLifecycleListener

Set

jps.credstore.migration

MERGE


21.4.5.3 To Migrate Credentials with Overwriting

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

Table 21-11 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


21.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:${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.


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

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

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

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

21.4.8 Migrating Identities with migrateSecurityStore

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.


21.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 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 StJore 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>
PKL^JPK AOEBPS/apreferences.htmL References

H References

This appendix contains references documentation useful to developes.

H.1 OPSS API References

The following Javadoc documents describe the various APIs that OPSS exposes:

OPSS APIs

Oracle Fusion Middleware Java API Reference for Oracle Platform Security Services

OPSS MBean APIs

Oracle Fusion Middleware MBeans Java API Reference for Oracle Platform Security Services

OPSS User and Role APIs

Oracle Fusion Middleware User and Role Java API Reference for Oracle Platform Security Services

Oracle Security Developer Tools APIs

Oracle Fusion Middleware PKI SDK CMP Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware CMS Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware Crypto Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware PKI SDK LDAP Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware Liberty 1.1 Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware Liberty 1.2 Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware S/MIME Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware PKI SDK OCSP Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware Security Engine Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware SAML 1.0/1.1 Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware SAML 2.0 Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware PKI SDK TSP Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware Web Services Security Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware XKMS Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware XML Security Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware Crypto FIPS Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware JCE Java API Reference for Oracle Security Developer Tools

PKPK AOEBPS/csfadmin.htmz~ Managing the Credential Store

10 Managing the Credential Store

A credential can hold user names, passwords, and tickets; credentials can be encrypted. Credentials are used during authentication, when principals are populated in subjects, and, further, during authorization, when determining what actions the subject can perform.

Oracle Platform Security Services includes the Credential Store Framework (CSF), a set of APIs that applications can use to create, read, update, and manage credentials securely. A typical use of the credential store is to store user names and passwords to access some external system, such as a database or an LDAP-based repository.

This chapter is divided into the following sections:

10.1 Credential Types

OPSS supports the following types of credentials according to the data they contain:

  • A password credential encapsulates a user name and a password.

  • A generic credential encapsulates any customized data or arbitrary token, such as a symmetric key.

In CSF, a credential is uniquely identified by a map name and a key name. Typically, the map name corresponds with the name of an application and all credentials with the same map name define a logical group of credentials, such as the credentials used by the application. The pair of map and key names must be unique for all entries in a credential store.

Oracle Wallet is the default file-based credential store, and it can store X.509 certificates; production environments typically use either an Oracle Internet Directory LDAP-based or an RDBMS DB-based credential store.

10.2 Encrypting Credentials

OPSS supports storing encrypted data in file- and LDAP-based credential stores. (In case of DB-based credential stores, data is always encrypted.) OPSS uses an encryption key to encrypt and decrypt data when it is read from or written to the credential store. To enable the encryption of credentials in a file- or LDAP-based store, set the following property in the credential store service instance of the file jps-config.xml:

<property name="encrypt" value="true" />

By default, credentials are kept in clear-text.

The Encryption Key

Assuming the above property set, OPSS automatically generates a random 256-bit AES key when the domain is restarted. Since the keys generated are practically distinct, a domain uses a unique encryption key. In addition to the first generated encryption key, there may be other keys (roll-over keys) automatically generated over time and used to encrypt and decrypt data. The only way to get a roll-over key is by restarting the domain.

When a new roll-over key is produced, data in the credential store is not immediately re-encrypted with the new key. Instead, data is re-encrypted (with the new key) only when it is written. This implies that to get all data to use the same encryption key, all credentials must be read and written.

Domains Sharing a Credential Store

If two or more domains share a credential store and encryption is enabled in that store, then each of those domains must use the same encryption key; this applies regardless of the type, LDAP or DB, of the credential store. To ensure this, OPSS provides offline scripts to export, import, and restore keys in the domain bootstrap wallet, so that an encryption key generated in one domain can be carried over to all other domains sharing the credential store. For details about these commands, see Managing Credentials with OPSS Scripts.

The following scenarios illustrate how to set credential encryption in a cluster of two domains, Domain1 and Domain2. (In case of more than two domains, treat each additional domain as Domain2 in the illustration below.)


Note:

The following scenarios assume that the credential store is LDAP-based, but the use of exportEncryptionKey and exportEncryptionKey to import and export keys across domains applies also to DB-based credential stores (in which data is always encrypted).


First Scenario

Assume that Domain1 has reassociated to an LDAP-based credential store, and Domain2 has not yet joined to that store. Then, to enable credential encryption on that store, proceed as follows:

  1. Set the property encrypt to true in Domain1's jps-config.xml file and restart the domain.

  2. Use the OPSS script exportEncryptionKey to extract the key from Domain1's bootstrap wallet into the file ewallet.p12; note that the value of the argument keyFilePassword passed to the script must be used later when importing that key into another domain.

  3. Set the property encrypt to true in Domain2's jps-config.xml file.

At this point you can complete the procedure in one of two ways; both of them use the OPSS script reassociateSecurityStore, but with different syntaxes. For details about this script, see Section 9.3.29, "reassociateSecurityStore."

The first approach is as follows:

  1. Use the OPSS script reassociateSecurityStore to reassociate Domain2's credential store to that used by Domain1; use the argument join and do not use the arguments keyFilePassword and keyFilePath.

  2. Use the OPSS script importEncryptionKey to write the extracted ewallet.p12 into Domain2's bootstrap wallet; note that the value of the argument keyFilePassword must be identical to the one used when the file ewallet.p12 was generated.

  3. Restart Domain2's server.

The second approach is as follows:

  1. Use the OPSS script reassociateSecurityStore to reassociate Domain2's credential store to that used by Domain1; use the arguments join, keyFilePassword, and keyFilePath.

  2. Restart Domain2's server.

Second Scenario

Assume that Domain1 has reassociated to an LDAP-based credential store and Domain2 has already joined to that store. Then, to enable credential encryption on that store, proceed as follows:

  1. Set the property encrypt to true in Domain1's jps-config.xml file and restart the domain.

  2. Use the OPSS script exportEncryptionKey to extract the key from Domain1's bootstrap wallet into the file ewallet.p12; note that the value of the argument keyFilePassword passed to the script must be used later when importing that key into another domain.

  3. Set the property encrypt to true in Domain2's jps-config.xml file.

  4. Use the OPSS script importEncryptionKey to write the extracted ewallet.p12 into Domain2's bootstrap wallet; note that the value of the argument keyFilePassword must be identical to the one used when the file ewallet.p12 was generated.

  5. Restart Domain2's server.


Important Note:

In case of multiple domains sharing a credential store in which encryption has been enabled, every time a roll-over key is generated in one of those domains, the administrator must import that key to each of the other domains in the cluster using the OPSS scripts exportEncryptionKey and importEncryptionKey.


10.3 Managing the Credential Store

Credentials can be provisioned, retrieved, modified, or deleted, but only by a user in the appropriate administration role. The following sections explain how an administrator can manage credentials using Fusion Middleware Control pages or OPSS scripts, and how code can access data in the CSF.

10.4 Managing Credentials with Fusion Middleware Control

The following procedure explains how to use Fusion Middleware Control to manage credentials.

  1. Log in to Fusion Middleware Control and navigate to Domain > Security > Credentials (if the application is deployed on Oracle WebLogic Server), or to Cell > Security > Application Policies (if it is deployed on WebSphere Application Server), to display the Credentials page partially illustrated in the following graphic:

    credential store page

    The area Credential Store Provider is read-only; when expanded, it displays the credential store provider currently in use in the domain or cell.

  2. To display credentials matching a given key name, enter the string to match in the Credential Key Name box, and then click the blue button. The result of the search is displayed in the table at the bottom of the page.

  3. At any point, you can remove an item by selecting it and clicking the Delete button; similarly, you can modify an item from the table by selecting it and clicking Edit button. Note that deleting a credential map, deletes all keys in it.

To create a credential map:

  1. Click Create Map to display the Create Map dialog.

  2. In this dialog, enter the name of the map for the credential being created.

  3. Click OK to return to the Credentials page. The new credential map name is displayed with a map icon in the table.

To add a key to a credential map:

  1. Click Create Key to display the Create Key dialog.

  2. In this dialog, select a map from the menu Select Map for the key being created, enter a key in the text Key box, and select a type (Password or Generic) from the pull-down menu Type. The dialog display changes according the type selected.

    If Password was selected, enter the required fields (Key, User Name, Password, Confirm Passwords).

    If Generic was selected, enter the required field Key and the credential information either as text (select Enter as Text radio button), or as a list of key-value pairs (select Enter Map of Property Name and Value Pairs radio button); to add a key-value pair, click Add Row, and then enter the Property Name, Value, and Confirm Value in the added arrow.

    Figure 10-1 illustrates th dialog used to create a password key.

  3. Click OK to return to the Credentials page. The new key is displayed under the map icon corresponding to the map you selected.

    Figure 10-1 The Create Key Dialog

    Surrounding text describes Figure 10-1 .

To edit a key:

  1. Select a key from the table.

  2. Click Edit to bring up the Edit Key dialog.

  3. In that dialog, modify the key data as appropriate. In case of editing a generic key, use the red X next to a row to delete the corresponding property-value pair.

    Figure 10-2 illustrates the dialog used to edit a generic key.

  4. Click OK to save your changes and return to the Credentials page.

For specific considerations that apply to ADF applications only, see section How to Edit Credentials Deployed with the Application in Oracle Fusion Middleware Administrator's Guide for Oracle Application Development Framework.

Figure 10-2 The Crteate Key Dialog

Surrounding text describes Figure 10-2 .

10.5 Managing Credentials with OPSS Scripts

An OPSS script is either a WLST script, in the context of the Oracle WebLogic Server, or a WASAdmin script, in the context of the WebSphere Application Server. The scripts listed in this section apply to both platforms: WebLogic Application Server and WebSphere Application Server.

An online script is a script that requires a connection to a running server. Unless otherwise stated, scripts listed in this section are online scripts and operate on a policy store, regardless of whether it is file-, LDAP-, or DB-based. There are a few scripts that are offline, that is, they do not require a server to be running to operate.

Read-only scripts can be performed only by users in the following WebLogic groups: Monitor, Operator, Configurator, or Admin. Read-write scripts can be performed only by users in the following WebLogic groups: Admin or Configurator. All WLST scripts are available out-of-the-box with the installation of the Oracle WebLogic Server.

WLST scripts can be run in interactive mode or in script mode. 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.

WASAdmin scripts can be run in interactive mode only. For details, see Oracle Fusion Middleware Third-Party Application Server Guide.

For platform-specific requirements to run an OPSS script, see Important Note.

OPSS provides the following scripts on all supported platforms to administer credentials (all scripts are online, unless otherwise stated):

10.5.1 listCred

The script listCred returns the list of attribute values of a credential in the credential store with given map name and key name. This script lists the data encapsulated in credentials of type password only.

Script Mode Syntax

listCred.py -map mapName -key keyName

Interactive Mode Syntax

listCred(map="mapName", key="keyName")

The meanings of the arguments (all required) are as follows:

  • map specifies a map name (folder).

  • key specifies a key name.

Example of Use

The following invocation returns all the information (such as user name, password, and description) in the credential with map name myMap and key name myKey:

listCred.py -map myMap -key myKey

10.5.2 updateCred

The script updateCred modifies the type, user name, and password of a credential in the credential store with given map name and key name. This script updates the data encapsulated in credentials of type password only. Only the interactive mode is supported.

Interactive Mode Syntax

updateCred(map="mapName", key="keyName", user="userName", password="passW", [desc="description"])   

The meanings of the arguments (optional arguments are enclosed by square brackets) are as follows:

  • map specifies a map name (folder) in the credential store.

  • key specifies a key name.

  • user specifies the credential user name.

  • password specifies the credential password.

  • desc specifies a string describing the credential.

Example of Use

The following invocation updates the user name, password, and description of the password credential with map name myMap and key name myKey:

updateCred(map="myMap", key="myKey", user="myUsr", password="myPassw")

10.5.3 createCred

The script createCred creates a credential in the credential store with a given map name, key name, user name and password. This script can create a credential of type password only. Only the interactive mode is supported.

Interactive Mode Syntax

createCred(map="mapName", key="keyName", user="userName", password="passW", [desc="description"])  

The meanings of the arguments (optional arguments are enclosed by square brackets) are as follows:

  • map specifies the map name (folder) of the credential.

  • key specifies the key name of the credential.

  • user specifies the credential user name.

  • password specifies the credential password.

  • desc specifies a string describing the credential.

Example of Use

The following invocation creates a password credential with the specified data:

createCred(map="myMap", key="myKey", user="myUsr", password="myPassw") 

10.5.4 deleteCred

The script deleteCred removes a credential with given map name and key name from the credential store.

Script Mode Syntax

deleteCred.py -map mapName -key keyName

Interactive Mode Syntax

deleteCred(map="mapName",key="keyName")

The meanings of the arguments (all required) are as follows:

  • map specifies a map name (folder).

  • key specifies a key name.

Example of Use

The following invocation removes the credential with map name myMap and key name myKey:

deleteCred.py -map myMap -key myKey

10.5.5 modifyBootStrapCredential

The offline script modifyBootStrapCredential modifies the bootstrap credentials configured in the default jps context, and it is typically used in the following scenario: suppose that the policy and credential stores are LDAP-based, and the credentials to access the LDAP store (stored in the LDAP server) are changed. Then this script can be used to seed those changes into the bootstrap credential store.

This script is available in interactive mode only.

Interactive Mode Syntax

modifyBootStrapCredential(jpsConfigFile="pathName", username="usrName", password="usrPass")

The meanings of the arguments (all required) are as follows:

  • jpsConfigFile specifies the location of the file jps-config.xml relative to the location where the script is run.

  • username specifies the distinguished name of the user in the LDAP store.

  • password specifies the password of the user.

Example of Use

Suppose that in the LDAP store, the password of the user with distinguished name cn=orcladmin has been changed to welcome1, and that the configuration file jps-config.xml is located in the current directory.Then the following invocation changes the password in the bootstrap credential store to welcome1:

modifyBootStrapCredential(jpsConfigFile='./jps-config.xml', username='cn=orcladmin', password='welcome1')

Any output regarding the audit service can be disregarded.

10.5.6 addBootStrapCredential

The offline script addBootStrapCredential adds a password credential with given map, key, user name, and user password to the bootstrap credentials configured in the default jps context of a jps configuration file.

This script is available in interactive mode only.

Interactive Mode Syntax

addBootStrapCredential(jpsConfigFile="pathName", map="mapName", key="keyName", username="usrName", password="usrPass")

The meanings of the arguments (all required) are as follows:

  • jpsConfigFile specifies the location of the file jps-config.xml relative to the location where the script is run.

  • map specifies the map of the credential to add.

  • key specifies the key of the credential to add.

  • username specifies the name of the user in the credential to add.

  • password specifies the password of the user in the credential to add.

Example of Use

The following invocation adds a credential to the bootstrap credential store:

addBootStrapCredential(jpsConfigFile='./jps-config.xml', map='myMapName', key='myKeyName', username='myUser', password='myPassword')

10.5.7 exportEncryptionKey

The offline script exportEncryptionKey extracts the encryption key from a domain's bootstrap wallet to the file ewallet.p12.

Interactive Mode Syntax

exportEncryptionKey(jpsConfigFile="pathName", keyFilePath="dirloc" ,keyFilePassword="password")

The meanings of the arguments (all required) are as follows:

  • jpsConfigFile specifies the location of the file jps-config.xml relative to the location where the script is run.

  • keyFilePath specifies the directory where the file ewallet.p12 is created; note that the content of this file is encrypted and secured by the value passed to keyFilePassword.

  • keyFilePassword specifies the password to secure the file ewallet.p12; note that this same password must be used when importing that file.

10.5.8 importEncryptionKey

The offline script importEncryptionKey writes an encryption key from the file ewallet.p12 to a domain's bootstrap wallet.

Interactive Mode Syntax

importEncryptionKey(jpsConfigFile="pathName", keyFilePath="dirloc" ,keyFilePassword="password")

The meanings of the arguments (all required) are as follows:

  • jpsConfigFile specifies the location of the file jps-config.xml relative to the location where the script is run.

  • keyFilePath specifies the directory where the ewallet.p12 is located.

  • keyFilePassword specifies the password used when the file ewallet.p12 was generated.

10.5.9 restoreEncryptionKey

The offline script restoreEncryptionKey restores the last key to a bootstrap wallet.

Interactive Mode Syntax

restoreEncryptionKey(jpsConfigFile="pathName")

The meaning of the argument (required) is as follows:

  • jpsConfigFile specifies the location of the file jps-config.xml relative to the location where the script is run.

PK[ٽyzzPK AOEBPS/apaudit.htm Oracle Fusion Middleware Audit Framework Reference

C Oracle Fusion Middleware Audit Framework Reference

This appendix provides reference information for the Oracle Fusion Middleware Audit Framework. It contains these topics:

C.1 Audit Events

This section describes the components that are audited and the types of events that can be audited.

C.1.1 What Components Can be Audited?

In 11g Release 1 (11.1.1), specific Java components and system components can generate audit records; they are known as audit-aware components.

Java Components that can be Audited

The following components can be audited with Fusion Middleware Audit Framework:

  • Directory Integration Platform Server

  • Oracle Platform Security Services

  • Oracle Web Services Manager

    • Agent

    • Policy Manager

    • Policy Attachment

  • Oracle Web Services

  • Oracle Identity Federation

  • Reports Server

System Components that can be Audited

The following components can be audited with Fusion Middleware Audit Framework:

  • Oracle HTTP Server

  • Oracle Web Cache

  • Oracle Internet Directory

  • Oracle Virtual Directory

C.1.2 What Events can be Audited?

The set of tables in this section shows, for each audit-aware system components and subcomponent, what event types can be audited:

C.1.2.1 Oracle Directory Integration Platform Events and their Attributes

Table C-1 Oracle Directory Integration Platform Events

Event CategoryEvent TypeAttributes used by Event

ServiceUtilize




InvokeService

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles


TerminateService

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles

SynchronizationEvents




Add

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, AssociateProfileName, ProfileName, EntryDN


Modify

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, AssociateProfileName, ProfileName, EntryDN


Delete

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, AssociateProfileName, ProfileName, EntryDN

ProvisioningEvents

UserAdd

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, ProfileName, ProvEvent


UserModify

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, ProfileName, ProvEvent


UserDelete

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, ProfileName, ProvEvent


GroupAdd

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, ProfileName, ProvEvent


GroupModify

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, ProfileName, ProvEvent


GroupDelete

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, ProfileName, ProvEven


IdentityAdd

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, ProfileName, ProvEvent


IdentityModify

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, ProfileName, ProvEvent


IdentityDelete

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, ProfileName, ProvEvent


SubscriptionAdd

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, ProfileName, ProvEvent


SubscriptionModify

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, ProfileName, ProvEvent


SubscriptionDelete

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, ProfileName, ProvEvent

ProfileManagementEvents

DeleteProvProfile

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode


UpdateProvProfile

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode


ActivateProvProfile

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode


DeactivateProvProfile

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode


CreateSyncProfile

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode


DeleteSyncProfile

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode


UpdateSyncProfile

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode


ActivateSyncProfile

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode


DeactivateSyncProfile

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode


SyncProfileUpdateChgNum

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode


ExpressSyncSetup

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode


SyncProfileBootstrap

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode


SyncProfileExtAuthPlugins

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode


ProvProfileBulkProv

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode

SchedulerEvents




AddJob

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, JobName, JobType


RemoveJob

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, JobName, JobType


C.1.2.2 Oracle Platform Security Services Events and their Attributes

Table C-2 Oracle Platform Security Services Events

Event CategoryEvent TypeAttributes used by Event

Authorization




CheckPermission

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, CodeSource, Principals, InitiatorGUID, Subject, PermissionAction, PermissionTarget, PermissionClass


CheckSubject

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, CodeSource, Principals, InitiatorGUID, Subject




CredentialManagement

CreateCredential

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, mapName, key, CodeSource, Principals, InitiatorGUID


DeleteCredential

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, mapName, key, CodeSource, Principals, InitiatorGUID


AccessCredential

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, mapName, key, CodeSource, Principals, InitiatorGUID


ModifyCredential

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, mapName, key, CodeSource, Principals, InitiatorGUID




PolicyManagement

PolicyGrant

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, CodeSource, Principals, InitiatorGUID, PermissionAction, PermissionTarget, PermissionClass, PermissionScope


PolicyRevoke

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, CodeSource, Principals, InitiatorGUID, PermissionAction, PermissionTarget, PermissionClass, PermissionScope




RoleManagement

RoleMembershipAdd

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, CodeSource, Principals, InitiatorGUID, ApplicationRole, EnterpriseRoles, PermissionScope


RoleMembershipRemove

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, CodeSource, Principals, InitiatorGUID, ApplicationRole, EnterpriseRoles, PermissionScope


C.1.2.3 Oracle HTTP Server Events and their Attributes

Table C-3 Oracle HTTP Server Events

Event CategoryEvent TypeAttributes used by Event

UserSession

UserLogin

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Resource, AuthenticationMethod, Reason


UserLogout

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Resource, AuthenticationMethod, Reason


Authentication

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Resource, AuthenticationMethod, Reason, SSLConnection




Authorization

CheckAuthorization

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Resource, Reason, AuthorizationType


C.1.2.4 Oracle Internet Directory Events and their Attributes

Table C-4 Oracle Directory Integration Platform Events

Event CategoryEvent TypeAttributes used by Event

UserSession

UserLogin

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Roles, custEventStatusDetail, custEventOp, AuthenticationMethod


UserLogout

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Roles, custEventStatusDetail, custEventOp




Authorization

CheckAuthorization

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, custEventStatusDetail, custEventOp




DataAccess

ModifyDataItemAttributes

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Resource, custEventStatusDetail, custEventOp


CompareDataItemAttributes

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Resource, custEventStatusDetail, custEventOp




AccountManagement

ChangePassword

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, custEventStatusDetail, custEventOp


CreateAccount

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, custEventStatusDetail, custEventOp


DeleteAccount

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, custEventStatusDetail, custEventOp


DisableAccount

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, custEventStatusDetail, custEventOp


EnableAccount

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, custEventStatusDetail, custEventOp


ModifyAccount

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, custEventStatusDetail, custEventOp


LockAccount

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, custEventStatusDetail, custEventOp




LDAPEntryAccess

custInternalOperation

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, custEventStatusDetail, custEventOp


C.1.2.5 Oracle Identity Federation Events and their Attributes

Table C-5 Oracle Identity Federation Events

Event CategoryEvent TypeAttributes used by Event

UserSession

LocalAuthentication

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, SessionID, AuthenticationMethod, UserID, AuthenticationMechanism, AuthenticationEngineID


LocalLogout

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, SessionID, AuthenticationMethod, UserID


CreateUserSession

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, SessionID, AuthenticationMethod, UserID, AuthenticationMechanism


DeleteUserSession

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, SessionID, AuthenticationMethod, UserID


CreateUserFederation

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, ProtocolVersion, NameIDQualifier, NameIDValue, NameIDFormat, FederationID, UserID, FederationType


DeleteUserFederation

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, ProtocolVersion, NameIDQualifier, NameIDValue, NameIDFormat, FederationID, UserID, FederationType


CreateActiveUserFederation

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, ProtocolVersion, SessionID, FederationID, AuthenticationMethod, UserID, FederationType


DeleteActiveUserFederation

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, ProtocolVersion, SessionID, FederationID, AuthenticationMethod, UserID, FederationType


UpdateUserFederation

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, ProtocolVersion, NameIDQualifier, NameIDValue, NameIDFormat, FederationID, UserID, FederationType, OldNameIDQualifier, OldNameIDValue




ProtocolFlow

IncomingMessage

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, ProtocolVersion, Binding, Role, UserID, MessageType, IncomingMessageString, IncomingMessageStringCLOB


OutgoingMessage

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, ProtocolVersion, Binding, Role, UserID, MessageType, OutgoingMessageString, OutgoingMessageStringCLOB


AssertionCreation

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, ProtocolVersion, NameIDQualifier, NameIDValue, NameIDFormat, SessionID, FederationID, UserID, AssertionVersion, IssueInstant, Issuer, AssertionID


AssertionConsumption

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, ProtocolVersion, NameIDQualifier, NameIDValue, NameIDFormat, SessionID, FederationID, UserID, AssertionVersion, IssueInstant, Issuer, AssertionID




Security

CreateSignature

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, ProtocolVersion, NameIDQualifier, NameIDValue, NameIDFormat, SessionID, FederationID, Type


VerifySignature

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, ProtocolVersion, NameIDQualifier, NameIDValue, NameIDFormat, SessionID, FederationID, Type


EncryptData

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, ProtocolVersion, NameIDQualifier, NameIDValue, NameIDFormat, SessionID, FederationID, Type


DecryptData

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, ProtocolVersion, NameIDQualifier, NameIDValue, NameIDFormat, SessionID, FederationID, Type




ServerConfiguration

ChangeCOT

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, NameIDQualifier, NameIDValue, NameIDFormat, SessionID, FederationID, COTBefore, COTAfter


ChangeServerProperty

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, NameIDQualifier, NameIDValue, NameIDFormat, SessionID, FederationID, ServerConfigBefore, ServerConfigAfter


ChangeDataStore

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, NameIDQualifier, NameIDValue, NameIDFormat, SessionID, FederationID, DataStoreBefore, DataStoreAfter


CreateConfigProperty

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, NameIDQualifier, NameIDValue, NameIDFormat, SessionID, FederationID, PropertyName, PropertyType, PeerProviderID, PropertyContext, NewValue


ChangeConfigProperty

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, NameIDQualifier, NameIDValue, NameIDFormat, SessionID, FederationID, PropertyName, PropertyType, PeerProviderID, PropertyContext, OldValue, NewValue


DeleteConfigProperty

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, ProtocolVersion, NameIDQualifier, NameIDValue, NameIDFormat, SessionID, FederationID, PropertyName, PropertyType, PeerProviderID, PropertyContext, Description, OldValue


CreatePeerProvider

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, ProtocolVersion, NameIDQualifier, NameIDValue, NameIDFormat, SessionID, FederationID, PeerProviderID, Description, ProviderType


UpdatePeerProvider

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, ProtocolVersion, NameIDQualifier, NameIDValue, NameIDFormat, SessionID, FederationID, PeerProviderID, Description, ProviderType


DeletePeerProvider

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, ProtocolVersion, NameIDQualifier, NameIDValue, NameIDFormat, SessionID, FederationID, PeerProviderID, Description, ProviderType


LoadMetadata

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, NameIDQualifier, NameIDValue, NameIDFormat, SessionID, FederationID, Description, Metadata


SetDataStoreType

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, RemoteProviderID, NameIDQualifier, NameIDValue, NameIDFormat, SessionID, FederationID, OldValue, NewDataStoreType, DataStoreName


C.1.2.6 Oracle Virtual Directory Events and their Attributes

Table C-6 Oracle Virtual Directory Events

Event CategoryEvent TypeAttributes used by Event

UserSession

UserLogin

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, AuthenticationMethod


UserLogout

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles




Authorization

CheckAuthorization

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles




DataAccess

QueryDataItemAttributes

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles


ModifyDataItemAttributes

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles


CompareDataItemAttributes

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles




ServiceManagement

RemoveService

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, ServiceOperation


ModifyServiceConfig

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, ServiceOperation


AddService

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, ServiceOperation




LDAPEntryAccess

Add

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles


Delete

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles


Modify

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles


Rename

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles


Compare

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles


C.1.2.7 OWSM-Agent Events and their Attributes

Table C-7 OWSM-Agent Events

Event CategoryEvent TypeAttributes used by Event

UserSession

Authentication

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Resource, AssertionName, CompositeName, Endpoint, AgentMode, ModelObjectName, Operation, ProcessingStage, Version, Protocol




Authorization

CheckAuthorization

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Resource, AssertionName, CompositeName, Endpoint, AgentMode, ModelObjectName, Operation, ProcessingStage, Version, Protocol




PolicyEnforcement

EnforceConfidentiality

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Resource, AssertionName, CompositeName, Endpoint, AgentMode, ModelObjectName, Operation, ProcessingStage, Version, Protocol


EnforceIntegrity

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Resource, AssertionName, CompositeName, Endpoint, AgentMode, ModelObjectName, Operation, ProcessingStage, Version, Protocol


EnforcePolicy

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Resource, AssertionName, CompositeName, Endpoint, AgentMode, ModelObjectName, Operation, ProcessingStage, Version, Protocol


C.1.2.8 OWSM-PM-EJB Events and their Attributes

Table C-8 OWSM-PM-EJB Events

Event CategoryEvent TypeAttributes used by Event

AssertionTemplateAuthoring

CreateAssertionTemplate

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, Resource, Version


DeleteAssertionTemplate

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, Resource, Version, ToVersion


ModifyAssertionTemplate

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, Resource, Version




PolicyAuthoring

CreatePolicy

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, Resource, Version


DeletePolicy

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, Resource, Version, ToVersion,


ModifyPolicy

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, Resource, Version


C.1.2.9 Reports Server Events and their Attributes

Table C-9 Reports Server Events

Event CategoryEvent TypeAttributes used by Event

UserSession

UserLogin

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles




Authorization

CheckAuthorization

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles


C.1.2.10 WS-Policy Attachment Events and their Attributes

Table C-10 WS-Policy Attachment Events

Event CategoryEvent TypeAttributes used by Event

PolicyAttachment

PolicyAttachmentEvent

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, PolicyChangeType, PolicyURI, PolicyCategory, PolicyStatus, ServiceEndPoint, PolicySubjRescPattern


</div>

C.1.2.11 Oracle Web Cache Events and their Attributes

Table C-11 Oracle Web Cache Events

Event CategoryEvent TypeAttributes used by Event

UserSession

UserLogin

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, AuthenticationMethod


UserLogout

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles, AuthenticationMethod




Authorization

CheckAuthorization

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles




DataAccess

FilterRequest

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles




ServiceManagement

ModifyServiceConfig

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles


ConfigServicePermissions

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles




ServiceUtilize

InvokeService

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles


TerminateService

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles




PeerAssocManagement

CreatePeerAssoc

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles


TerminatePeerAssoc

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles


ChallengePeerAssoc

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles




Authentication

ClientAuthentication

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles


ServerAuthentication

ComponentType, InstanceId, HostId, HostNwaddr, ModuleId, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Roles


C.1.2.12 Oracle Web Services Manager Events and their Attributes

Table C-12 Oracle Web Services Manager Events

Event CategoryEvent TypeAttributes used by Event

WS-Processing

RequestReceived

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Protocol, Endpoint, Operation, FaultUrl


ResponseSent

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, Protocol, Endpoint, Operation, FaultUri




WS-Fault

SoapFaultEvent

ComponentType, InstanceId, HostId, HostNwaddr, ProcessId, OracleHome, HomeInstance, ECID, RID, ContextFields, SessionId, TargetComponentType, ApplicationName, EventType, EventCategory, EventStatus, TstzOriginating, ThreadId, ComponentName, Initiator, MessageText, FailureCode, RemoteIP, Target, Resource, URI, Source, Protocol, Endpoint, Operation


C.1.3 Event Attribute Descriptions

lists all attributes for all audited events. Use this table to learn about the attributes used in the event of interest.

Table C-13 Attributes of Audited Events

Attribute NameDescription

AgentMode

Mode in which agent performed policy enforcement.

ApplicationName

The Java EE application name

ApplicationRole

This attribute used for application roles audit for role membership management

AssertionID

The value of the "AssertionID" attribute of the assertion

AssertionName

Name of the assertion that failed enforcement.

AssertionVersion

The version number of the assertion corresponding to this event (ex. 2.0)

AssociateProfileName

This attribute is used to audit the Associate Profile Name

AuthenticationEngineID

The identifier of the authentication engine used during local authentication

AuthenticationMechanism

The authentication mechanism used during local authentication

AuthenticationMethod

The Authentication method - password / SSL / Kerberos and so on.

AuthorizationType

Access/authorization configuration directive: Regular = 'Require' directive, SSL = 'SSLRequire' directive

Binding

The binding used to send the message (SOAP, POST, GET, Aritifact,...)

COTAfter

The contents of the federations configuration file after the change

COTBefore

The contents of the federations configuration file before the change

CodeSource

This attribute used for code source audit for rolemembershipmanagement

ComponentName

ComponentName

ComponentType

Type of the component.

CompositeName

Name of the composite (apply to SOA application only) against which the policy is being enforced.

ContextFields

This attribute contains the context fields extracted from dms context.

custEventOp

This attribute specifies the LDAP operation name associated with this event, e.g. ldapbind, ldapadd, ldapsearch and so on.

custEventStatusDetail

This attribute conveys event status detail info, e.g. error code and other details in case of failure of the associated LDAP operation.

DataStoreAfter

The data stores configuration after the change

DataStoreBefore

The data stores configuration before the change

DataStoreName

The name of the data store being modified (examples: user data store, federation datastore)

Description

Description of the trusted provider

ECID

Identifies the thread of execution that the originating component participates in.

Endpoint

The URI which identifies the endpoint for which the event was triggered. For example, an HTTP require will record the URL.

EnterpriseRoles

This attribute used for enterprise roles audit for rolemembershipmanagement

EntryDN

This attribute is used to audit the entry Distinguished Name

EventCategory

The category of the audit event.

EventStatus

The outcome of the audit event - success or failure

EventType

The type of the audit event. Use wlst listAuditEvents to list out all the events.

FailureCode

The error code in case EventStatus = failure

FaultUri

If processing yielded a fault, the URI of the fault that will be sent.

FederationID

The ID of the federation

FederationType

The type of the federation that is being created or deleted (SP/IdP)

HomeInstance

The ORACLE_INSTANCE directory of the component

HostId

DNS hostname of originating host

HostNwaddr

IP or other network address of originating host

IncomingMessageString

null

IncomingMessageStringCLOB

null

Initiator

Identifies the UID of the user who is doing the operation

InitiatorGUID

This attribute used for initiator guid audit for authorization

InstanceId

Name of the Oracle Instance to which this component belongs.

IssueInstant

The value of the "IssueInstant" attribute of the assertion

Issuer

The value of the "Issuer" attribute of the assertion

JobName

This attribute is used to audit the Scheduler Job Name

JobType

This attribute is used to audit the Scheduler Job Name

key

This is the credential key for the Credential Store

mapName

This is the map name (alias name) for the Credential Store

MessageText

Description of the audit event

MessageType

The type of the message (ex. SSOLoginRequest/SSOLoginResponse/SSOLogoutRequest/...)

Metadata

The provider metadata loaded

ModelObjectName

Name of the Web service or client name against which the policy is being enforced.

ModuleId

ID of the module that originated the message. Interpretation is specific to the Component ID.

NameIDFormat

The format of the NameID of the subject

NameIDQualifier

The qualifier of the nameID of the subject

NameIDValue

The value of the nameID of the subject

NewDataStoreType

The new type of the data store

NewValue

The value of the property after the configuration change

OldNameIDQualifier

The nameID qualifier before the update took place

OldNameIDValue

The nameID value before the update took place



OldValue

The value of the property before the configuration change

Operation

For SOAP requests, the operation for which the event was triggered.

OracleHome

The ORACLE_HOME directory of the component

OutgoingMessageString

null

OutgoingMessageStringCLOB

null

PeerProviderID

The ID of the trusted provider associated with the modified property (If the modified property does not correspond to a trusted provider, this attribute is empty.)

PermissionAction

This attribute used for permission action audit for authorization

PermissionClass

This attribute used for permission class audit for policy store

PermissionScope

This attribute used for permission scope audit for role membership management

PermissionTarget

This attribute used for permission target audit for policy store

PolicyCategory

The category of the policy for which the event was triggered.(comma-separated list)

PolicyChangeType

The type of change that occurred.

PolicyStatus

The status of the policy for which the event was triggered.(comma-separated list)

PolicySubjRescPattern

The policy subject resource pattern which identifies the policy subject for which the event was triggered.

PolicyURI

The URI which identifies the policy for which the event was triggered.(comma-separated list)

Principals

This attribute used for principals audit for role membership management

ProcessId

ID of the process that originated the message

ProcessingStage

Processing stage during which the policy enforcement occurred.

ProfileName

This attribute is used to audit the Sync Profile Name

PropertyContext

The location of the property in the configuration

PropertyName

The name of the configuration property

PropertyType

The type of the property (examples: PropertiesList, PropertiesMap, String, Boolean)

Protocol

The protocol of the request.

ProtocolVersion

The version of the protocol being used (examples: SAML2.0, Libv11)

ProvEvent

This attribute is used to audit the Prov Event

ProviderType

The type of the provider (examples: sp, idp, sp idp)

RID

This is the relationship identifier, it is used to provide the full and correct calling relationships between threads and processes.

Reason

The reason this event occurred

RemoteIP

IP address of the client initiating this event

RemoteProviderID

The provider ID of the remote server

Resource

Identifies a resource that is being accessed. A resource can be many things - web page, file, directory share, web service, XML document, a portlet. The resource can be named as a combination of a host name, and an URI.

Role

The role of Oracle Identity Federation during the protocol step performed (for example Service Provider/ Identity Provider/Attribute Authority/..)

Roles

The roles that the user was granted at the time of login.

SSLConnection

Was SSL connection used by client to transmit request?

ServerConfigAfter

The server configuration after the change

ServerConfigBefore

The server configuration before the change

ServiceEndPoint

The URI which identifies the service for which the event was triggered.

ServiceOperation

Name of the operation performed that changes the service configuration

SessionID

The ID of the current session

SessionId

ID of the login session.

Source

The source of the fault.

Subject

This attribute used for subject audit for authorization

Target

Identifies the UID of the user on whom the operation is being done. E.g. is Alice changes Bob's password, then Alice is the initiator and Bob is the target

TargetComponentType

This is the target component type.

ThreadId

ID of the thread that generated this event

ToVersion

Upper end when deleting a range of policy versions.

TstzOriginating

Date and time when the audit event was generated

Type

The type of cryptographic data being processed (XML, String)

URI

The URI of the fault.

UserID

The identifier of the user in this protocol step

Version

Version of policy that was modified.


C.2 Pre-built Audit Reports

Oracle Fusion Middleware Audit Framework provides a range of out-of-the-box reports that are accessible through Oracle Business Intelligence Publisher. The reports are grouped according to the type of audit data they contain:

C.2.1 Common Audit Reports

A list of common reports appears in Section 14.5, "Audit Report Details".

C.2.2 Component-Specific Audit Reports

Component-Specific reports are organized as follows:

  • Oracle Fusion Middleware Audit Framework

    • Configuration Changes

  • Oracle HTTP Server

    • Errors and Exceptions

    • User Activities

    • All Events

  • Oracle Internet Directory

    • Account Management

      • Account Profile History

      • Accounts Deleted

      • Accounts Enabled

      • Password Changes

      • Accounts Created

      • Accounts Disabled

      • Accounts Locked Out

    • User Activities

      • Authentication History

      • Authorization History

    • Errors and Exceptions

      • All Errors and Exceptions

      • Authentication Failures

      • Authorization Failures

    • All Events

  • Oracle Virtual Directory

    • User Activities

      • Authentication History

      • Authorization History

    • Errors and Exceptions

      • All Errors and Exceptions

      • Authentication Failures

      • Authorization Failures

    • All Events

  • Reports Server

    • User Activities

      • Authentication History

      • Authorization History

    • Errors and Exceptions

      • All Errors and Exceptions

      • Authentication Failures

      • Authorization Failures

    • All Events

  • Oracle Directory Integration Platform

    • All Errors and Exceptions

    • Profile Management Events

    • All Events

  • Oracle Identity Federation

    • Errors and Exceptions

      • All Errors and Exceptions

      • Authentication Failures

    • All Events

    • Federation user Activity

    • Authentication History

    • Assertion Activity

  • Oracle Platform Security Services

    • Errors and Exceptions

      • All Errors and Exceptions

      • Authentication Failures

    • All Events

    • Application Role Management

    • Credential Management

    • Authorization History

    • Application Policy Management

    • Credential Access

    • System Policy Management

  • Oracle Web Services Manager

    • User Activities

      • Authentication History

      • Authorization History

    • Errors and Exceptions

      • All Errors and Exceptions

      • Authentication Failures

      • Authorization Failures

    • All Events

    • Policy Management

      • Assertion Template Management

      • Web Services Policy Management

    • Policy Enforcements

      • Confidentiality Enforcements

      • Policy Enforcements

      • Message Integrity Enforcements

      • Violations

    • Request Response

    • Policy Attachments

  • Oracle Web Cache

    • User Activities

      • Authentication History

      • Authorization History

    • Errors and Exceptions

      • All Errors and Exceptions

      • Authentication Failures

      • Authorization Failures

    • All Events

C.3 The Audit Schema

If you have additional audit reporting requirements beyond the pre-built reports described in Section C.2, "Pre-built Audit Reports", you can create custom reports using your choice of reporting tools. For example, while the pre-built reports use a subset of the event attributes, you can make use of the entire audit attribute set for an event in creating custom reports.

Table C-14 and Table C-15 describe the audit schema, which is useful when building custom reports.

Table C-14 The Audit Schema

Table NameColumn NameData TypeNullableColumn ID

BASE TABLE

IAU_ID

NUMBER

Yes

1


IAU_ORGID

VARCHAR2(255 Bytes)

Yes

2


IAU_COMPONENTID

VARCHAR2(255 Bytes)

Yes

3


IAU_COMPONENTTYPE

VARCHAR2(255 Bytes)

Yes

4


IAU_INSTANCEID

VARCHAR2(255 Bytes)

Yes

5


IAU_HOSTINGCLIENTID

VARCHAR2(255 Bytes)

Yes

6


IAU_HOSTID

VARCHAR2(255 Bytes)

Yes

7


IAU_HOSTNWADDR

VARCHAR2(255 Bytes)

Yes

8


IAU_MODULEID

VARCHAR2(255 Bytes)

Yes

9


IAU_PROCESSID

VARCHAR2(255 Bytes)

Yes

10


IAU_ORACLEHOME

VARCHAR2(255 Bytes)

Yes

11


IAU_HOMEINSTANCE

VARCHAR2(255 Bytes)

Yes

12


IAU_UPSTREAMCOMPONENTID

VARCHAR2(255 Bytes)

Yes

13


IAU_DOWNSTREAMCOMPONENTID

VARCHAR2(255 Bytes)

Yes

14


IAU_ECID

VARCHAR2(255 Bytes)

Yes

15


IAU_RID

VARCHAR2(255 Bytes)

Yes

16


IAU_CONTEXTFIELDS

VARCHAR2(2000 Bytes)

Yes

17


IAU_SESSIONID

VARCHAR2(255 Bytes)

Yes

18


IAU_SECONDARYSESSIONID

VARCHAR2(255 Bytes)

Yes

19


IAU_APPLICATIONNAME

VARCHAR2(255 Bytes)

Yes

20


IAU_TARGETCOMPONENTTYPE

VARCHAR2(255 Bytes)

Yes

21


IAU_EVENTTYPE

VARCHAR2(255 Bytes)

Yes

22


IAU_EVENTCATEGORY

VARCHAR2(255 Bytes)

Yes

23


IAU_EVENTSTATUS



NUMBER

Yes

24


IAU_TSTZORIGINATING

TIMESTAMP(6)

Yes

25


IAU_THREADID

VARCHAR2(255 Bytes)

Yes

26


IAU_COMPONENTNAME

VARCHAR2(255 Bytes)

Yes

27


IAU_INITIATOR

VARCHAR2(255 Bytes)

Yes

28


IAU_MESSAGETEXT

VARCHAR2(255 Bytes)

Yes

29


IAU_FAILURECODE

VARCHAR2(255 Bytes)

Yes

30


IAU_REMOTEIP

VARCHAR2(255 Bytes)

Yes

31


IAU_TARGET

VARCHAR2(255 Bytes)

Yes

32


IAU_RESOURCE

VARCHAR2(255 Bytes)

Yes

33


IAU_ROLES

VARCHAR2(255 Bytes)

Yes

34


IAU_AUTHENTICATIONMETHOD

VARCHAR2(255 Bytes)

Yes

35


IAU_TRANSACTIONID

VARCHAR2(255 Bytes)

Yes

36


IAU_DOMAINNAME

VARCHAR2(255 Bytes)

Yes

37


IAU_COMPONENTDATA

clob

yes

38






DIP

IAU_ID

NUMBER

Yes

1


IAU_TSTZORIGINATING

TIMESTAMP(6)

Yes

2


IAU_EVENTTYPE

VARCHAR2(255 Bytes)

Yes

3


IAU_EVENTCATEGORY

VARCHAR2(255 Bytes)

Yes

4


IAU_ASSOCIATEPROFILENAME

VARCHAR2(512 Bytes)

Yes

5


IAU_PROFILENAME

VARCHAR2(512 Bytes)

Yes

6


IAU_ENTRYDN

VARCHAR2(1024 Bytes)

Yes

7


IAU_PROVEVENT

VARCHAR2(2048 Bytes)

Yes

8


IAU_JOBNAME

VARCHAR2(128 Bytes)

Yes

9


IAU_JOBTYPE

VARCHAR2(128 Bytes)

Yes

10






IAU_DISP_NAME_TL

IAU_LOCALE_STR

VARCHAR2(7 Bytes)


1


IAU_DISP_NAME_KEY

VARCHAR2(255 Bytes)


2


IAU_COMPONENT_TYPE

VARCHAR2(255 Bytes)


3


IAU_DISP_NAME_KEY_TYPE

VARCHAR2(255 Bytes)


4


IAU_DISP_NAME_TRANS

VARCHAR2(4000 Bytes)

Yes

5






IAU_LOCALE_MAP_TL

IAU_LOC_LANG

VARCHAR2(2 Bytes)

Yes

1


IAU_LOC_CNTRY

VARCHAR2(3 Bytes)

Yes

2


IAU_LOC_STR

VARCHAR2(7 Bytes)

Yes

3






OPSS

IAU_ID

NUMBER

Yes

1


IAU_TSTZORIGINATING

TIMESTAMP(6)

Yes

2


IAU_EVENTTYPE

VARCHAR2(255 Bytes)

Yes

3


IAU_EVENTCATEGORY

VARCHAR2(255 Bytes)

Yes

4


IAU_CODESOURCE

VARCHAR2(1024 Bytes)

Yes

5


IAU_PRINCIPALS

VARCHAR2(1024 Bytes)

Yes

6


IAU_INITIATORGUID

VARCHAR2(1024 Bytes)

Yes

7


IAU_SUBJECT

VARCHAR2(1024 Bytes)

Yes

8


IAU_PERMISSIONACTION

VARCHAR2(1024 Bytes)

Yes

9


IAU_PERMISSIONTARGET

VARCHAR2(1024 Bytes)

Yes

10


IAU_PERMISSIONCLASS

VARCHAR2(1024 Bytes)

Yes

11


IAU_MAPNAME

VARCHAR2(1024 Bytes)

Yes

12


IAU_KEY

VARCHAR2(1024 Bytes)

Yes

13


IAU_PERMISSIONSCOPE

VARCHAR2(1024 Bytes)

Yes

14


IAU_APPLICATIONROLE

VARCHAR2(1024 Bytes)

Yes

15


IAU_ENTERPRISEROLES

VARCHAR2(1024 Bytes)

Yes

16


IAU_INITIATORDN

VARCHAR2(1024 Bytes)

Yes

17


IAU_GUID

VARCHAR2(1024 Bytes)

Yes

18


IAU_PERMISSION

VARCHAR2(1024 Bytes)

Yes

19


IAU_MODIFIEDATTRIBUTENAME

VARCHAR2(1024 Bytes)

Yes

20


IAU_MODIFIEDATTRIBUTEVALUE

VARCHAR2(2048 Bytes)

Yes

21


IAU_PERMISSIONSETNAME

VARCHAR2(1024 Bytes)

Yes

22


IAU_RESOURCEACTIONS

VARCHAR2(1024 Bytes)

Yes

23


IAU_RESOURCETYPE

VARCHAR2(1024 Bytes)

Yes

24






OHS/OHS Component

IAU_ID

NUMBER

Yes

1


IAU_TSTZORIGINATING

TIMESTAMP(6)

Yes

2


IAU_EVENTTYPE

VARCHAR2(255 Bytes)

Yes

3


IAU_EVENTCATEGORY

VARCHAR2(255 Bytes)

Yes

4


IAU_REASON

CLOB

Yes

5


IAU_SSLCONNECTION

VARCHAR2(255 Bytes)

Yes

6


IAU_AUTHORIZATIONTYPE

VARCHAR2(255 Bytes)

Yes

7






OID/OID Component

IAU_ID

NUMBER

Yes

1


IAU_TSTZORIGINATING

TIMESTAMP(6)

Yes

2


IAU_EVENTTYPE

VARCHAR2(255 Bytes)

Yes

3


IAU_EVENTCATEGORY

VARCHAR2(255 Bytes)

Yes

4


IAU_CUSTEVENTSTATUSDETAIL

VARCHAR2(255 Bytes)

Yes

5


IAU_CUSTEVENTOP

VARCHAR2(255 Bytes)

Yes

6






OIF

IAU_ID

NUMBER

Yes

1


IAU_TSTZORIGINATING

TIMESTAMP(6)

Yes

2


IAU_EVENTTYPE

VARCHAR2(255 Bytes)

Yes

3


IAU_EVENTCATEGORY

VARCHAR2(255 Bytes)

Yes

4


IAU_REMOTEPROVIDERID

VARCHAR2(255 Bytes)

Yes

5


IAU_PROTOCOLVERSION

VARCHAR2(255 Bytes)

Yes

6


IAU_NAMEIDQUALIFIER

VARCHAR2(255 Bytes)

Yes

7


IAU_NAMEIDVALUE

VARCHAR2(255 Bytes)

Yes

8


IAU_NAMEIDFORMAT

VARCHAR2(255 Bytes)

Yes

9


IAU_SESSIONID

VARCHAR2(255 Bytes)

Yes

10


IAU_FEDERATIONID

VARCHAR2(255 Bytes)

Yes

11


IAU_USERID

VARCHAR2(255 Bytes)

Yes

12


IAU_FEDERATIONTYPE

VARCHAR2(255 Bytes)

Yes

13


IAU_AUTHENTICATIONMECHANISM

VARCHAR2(255 Bytes)

Yes

14


IAU_AUTHENTICATIONENGINEID

VARCHAR2(255 Bytes)

Yes

15


IAU_OLDNAMEIDQUALIFIER

VARCHAR2(255 Bytes)

Yes

16


IAU_OLDNAMEIDVALUE

VARCHAR2(255 Bytes)

Yes

17


IAU_BINDING

VARCHAR2(255 Bytes)

Yes

18


IAU_ROLE

VARCHAR2(255 Bytes)

Yes

19


IAU_MESSAGETYPE

VARCHAR2(255 Bytes)

Yes

20


IAU_ASSERTIONVERSION

VARCHAR2(255 Bytes)

Yes

21


IAU_ISSUEINSTANT

VARCHAR2(255 Bytes)

Yes

22


IAU_ISSUER

VARCHAR2(255 Bytes)

Yes

23


IAU_ASSERTIONID

VARCHAR2(255 Bytes)

Yes

24


IAU_INCOMINGMESSAGESTRING

VARCHAR2(3999 Bytes)

Yes

25


IAU_INCOMINGMESSAGESTRINGCLOB

CLOB

Yes

26


IAU_OUTGOINGMESSAGESTRING

VARCHAR2(3999 Bytes)

Yes

27


IAU_OUTGOINGMESSAGESTRINGCLOB

CLOB

Yes

28


IAU_TYPE

VARCHAR2(255 Bytes)

Yes

29


IAU_PROPERTYNAME

VARCHAR2(255 Bytes)

Yes

30


IAU_PROPERTYTYPE

VARCHAR2(255 Bytes)

Yes

31


IAU_PEERPROVIDERID

VARCHAR2(255 Bytes)

Yes

32


IAU_PROPERTYCONTEXT

VARCHAR2(255 Bytes)

Yes

33


IAU_DESCRIPTION

VARCHAR2(255 Bytes)

Yes

34


IAU_OLDVALUE

VARCHAR2(255 Bytes)

Yes

35


IAU_NEWVALUE

VARCHAR2(255 Bytes)

Yes

36


IAU_PROVIDERTYPE

VARCHAR2(255 Bytes)

Yes

37


IAU_COTBEFORE

CLOB

Yes

38


IAU_COTAFTER

CLOB

Yes

39


IAU_SERVERCONFIGBEFORE

CLOB

Yes

40


IAU_SERVERCONFIGAFTER

CLOB

Yes

41


IAU_DATASTOREBEFORE

CLOB

Yes

42


IAU_DATASTOREAFTER

CLOB

Yes

43


IAU_METADATA

VARCHAR2(255 Bytes)

Yes

44


IAU_NEWDATASTORETYPE

VARCHAR2(255 Bytes)

Yes

45


IAU_DATASTORENAME

VARCHAR2(255 Bytes)

Yes

46






OVD/OVD Component

IAU_ID

NUMBER

Yes

1


IAU_TSTZORIGINATING

TIMESTAMP(6)

Yes

2


IAU_EVENTTYPE

VARCHAR2(255 Bytes)

Yes

3


IAU_EVENTCATEGORY

VARCHAR2(255 Bytes)

Yes

4


IAU_SERVICEOPERATION

VARCHAR2(255 Bytes)

Yes

5






OWSM Agent

IAU_ID

NUMBER

Yes

1


IAU_TSTZORIGINATING

TIMESTAMP(6)

Yes

2


IAU_EVENTTYPE

VARCHAR2(255 Bytes)

Yes

3


IAU_EVENTCATEGORY

VARCHAR2(255 Bytes)



Yes

4


IAU_APPNAME

VARCHAR2(255 Bytes)

Yes

5


IAU_ASSERTIONNAME

VARCHAR2(255 Bytes)

Yes

6


IAU_COMPOSITENAME

VARCHAR2(255 Bytes)

Yes

7


IAU_ENDPOINT

VARCHAR2(4000 Bytes)

Yes

8


IAU_AGENTMODE

VARCHAR2(255 Bytes)

Yes

9


IAU_MODELOBJECTNAME

VARCHAR2(255 Bytes)

Yes

10


IAU_OPERATION

VARCHAR2(255 Bytes)

Yes

11


IAU_PROCESSINGSTAGE

VARCHAR2(255 Bytes)

Yes

12


IAU_VERSION

NUMBER

Yes

13


IAU_PROTOCOL

VARCHAR2(255 Bytes)

Yes

14






OWSM_PM_EJB

IAU_ID

NUMBER

Yes

1


IAU_TSTZORIGINATING

TIMESTAMP(6)

Yes

2


IAU_EVENTTYPE

VARCHAR2(255 Bytes)

Yes

3


IAU_EVENTCATEGORY

VARCHAR2(255 Bytes)

Yes

4


IAU_VERSION

NUMBER

Yes

5


IAU_TOVERSION

NUMBER

Yes

6






ReportsServer/ReportsServer
Components

IAU_ID

NUMBER

Yes

1


IAU_TSTZORIGINATING

TIMESTAMP(6)

Yes

2


IAU_EVENTTYPE

VARCHAR2(255 Bytes)

Yes

3


IAU_EVENTCATEGORY

VARCHAR2(255 Bytes)

Yes

4











WebCache/ WebCache
Component

IAU_ID

NUMBER

Yes

1


IAU_TSTZORIGINATING

TIMESTAMP(6)

Yes

2


IAU_EVENTTYPE

VARCHAR2(255 Bytes)

Yes

3


IAU_EVENTCATEGORY

VARCHAR2(255 Bytes)

Yes

4











WebServices

IAU_ID

NUMBER

Yes

1


IAU_TSTZORIGINATING

TIMESTAMP(6)

Yes

2


IAU_EVENTTYPE

VARCHAR2(255 Bytes)

Yes

3


IAU_EVENTCATEGORY

VARCHAR2(255 Bytes)

Yes

4


IAU_PROTOCOL

VARCHAR2(255 Bytes)

Yes

5


IAU_ENDPOINT

VARCHAR2(4000 Bytes)

Yes

6


IAU_OPERATION

VARCHAR2(255 Bytes)

Yes

7


IAU_FAULTURI

VARCHAR2(4000 Bytes)

Yes

8


IAU_URI

VARCHAR2(4000 Bytes)

Yes

9


IAU_SOURCE

VARCHAR2(255 Bytes)

Yes

10






WS_Policy
Attachment

IAU_ID

NUMBER

Yes

1


IAU_TSTZORIGINATING

TIMESTAMP(6)

Yes

2


IAU_EVENTTYPE

VARCHAR2(255 Bytes)

Yes

3


IAU_EVENTCATEGORY

VARCHAR2(255 Bytes)

Yes

4


IAU_PROTOCOL

VARCHAR2(255 Bytes)

Yes

5


IAU_ENDPOINT

VARCHAR2(4000 Bytes)

Yes

6


IAU_OPERATION

VARCHAR2(255 Bytes)

Yes

7


IAU_FAULTURI

VARCHAR2(4000 Bytes)

Yes

8


IAU_URI

VARCHAR2(4000 Bytes)

Yes

9


IAU_SOURCE

VARCHAR2(255 Bytes)

Yes

10






OAM (Oracle Access Manager)

IAU_ID

NUMBER

Yes

1


IAU_TSTZORIGINATING

TIMESTAMP(6)

Yes

2


IAU_EVENTTYPE

VARCHAR2(255)

Yes

3


IAU_EVENTCATEGORY

VARCHAR2(255)

Yes

4


IAU_APPLICATIONDOMAINNAME

VARCHAR2(40)

Yes

5


IAU_AUTHENTICATIONSCHEMEID

VARCHAR2(40)

Yes

6


IAU_AGENTID

VARCHAR2(40)

Yes

7


IAU_SSOSESSIONID

VARCHAR2(100)

Yes

8


IAU_ADDITIONALINFO

VARCHAR2(1000)

Yes

9


IAU_AUTHORIZATIONSCHEME

VARCHAR2(40)

Yes

10


IAU_USERDN

VARCHAR2(255)

Yes

11


IAU_RESOURCEID

VARCHAR2(40)

Yes

12


IAU_AUTHORIZATIONPOLICYID

VARCHAR2(40)

Yes

13


IAU_AUTHENTICATIONPOLICYID

VARCHAR2(255)

Yes

14


IAU_USERID

VARCHAR2(40)

Yes

15


IAU_RESOURCEHOST

VARCHAR2(255)

Yes

16


IAU_REQUESTID

VARCHAR2(255)

Yes

17


IAU_POLICYNAME

VARCHAR2(40)

Yes

18


IAU_SCHEMENAME

VARCHAR2(40)

Yes

19


IAU_RESOURCEHOSTNAME

VARCHAR2(100)

Yes

20


IAU_OLDATTRIBUTES

VARCHAR2(1000)

Yes

21


IAU_NEWATTRIBUTES

VARCHAR2(1000)

Yes

22


IAU_SCHMETYPE

VARCHAR2(40)

Yes

23


IAU_RESPONSETYPE

VARCHAR2(40)

Yes

24


IAU_AGENTTYPE

VARCHAR2(40)

Yes

25


IAU_CONSTRAINTTYPE

VARCHAR2(40)

Yes

26


IAU_INSTANCENAME

VARCHAR2(40)

Yes

27


IAU_DATASOURCENAME

VARCHAR2(100)

Yes

28


IAU_DATASOURCETYPE

VARCHAR2(100)

Yes

29


IAU_HOSTIDENTIFIERNAME

VARCHAR2(100)

Yes

30


IAU_RESOURCEURI

VARCHAR2(255)

Yes

31


IAU_RESOURCETEMPLATENAME

VARCHAR2(100)

Yes

32






OAAM (Oracle Adaptive Access Manager)

IAU_ID

NUMBER

Yes

1


IAU_TSTZORIGINATING

TIMESTAMP(6)

Yes

2


IAU_EVENTTYPE

VARCHAR2(255)

Yes

3


IAU_EVENTCATEGORY

VARCHAR2(255)

Yes

4


IAU_ACTIONNOTES

VARCHAR2(4000)

Yes

5


IAU_CASEACTIONENUM

NUMBER(38)

Yes

6


IAU_CASEACTIONRESULT

NUMBER

Yes

7


IAU_CASECHALLENGEQUESTION

VARCHAR2(4000)

Yes

8


IAU_CASECHALLENGERESULT

NUMBER(38)

Yes

9


IAU_CASEDISPOSITION

NUMBER(38)

Yes

10


IAU_CASEEXPRDURATIONINHRS

NUMBER(38)

Yes

11


IAU_CASEID

NUMBER

Yes

12


IAU_CASEIDS

VARCHAR2(4000)

Yes

13


IAU_CASESEVERITY

NUMBER(38)

Yes

14


IAU_CASESTATUS

NUMBER(38)

Yes

15


IAU_CASESUBACTIONENUM

NUMBER(38)

Yes

16


IAU_DESCRIPTION

VARCHAR2(4000)

Yes

17


IAU_GROUPID

NUMBER

Yes

18


IAU_GROUPIDS

VARCHAR2(4000)

Yes

19


IAU_GROUPNAME

VARCHAR2(4000)

Yes

20


IAU_GROUPDETAILS

VARCHAR2(4000)

Yes

21


IAU_GROUPELEMENTID

NUMBER

Yes

22


IAU_GROUPELEMENTIDS

NUMBER

Yes

23


IAU_GROUPELEMENTVALUE

VARCHAR2(4000)

Yes

24


IAU_GROUPELEMENTSDETAILS

VARCHAR2(4000)

Yes

25


IAU_KBACATEGORYID

NUMBER

Yes

26


IAU_KBACATEGORYIDS

VARCHAR2(4000)

Yes

27


IAU_KBACATEGORYNAME

VARCHAR2(4000)

Yes

28


IAU_KBACATEGORYDETAILS

VARCHAR2(4000)

Yes

29


IAU_KBAQUESTIONID

NUMBER

Yes

30


IAU_KBAQUESTIONIDS

VARCHAR2(4000)

Yes

31


IAU_KBAQUESTION

VARCHAR2(4000)

Yes

32


IAU_KBAQUESTIONTYPE

NUMBER(38)

Yes

33


IAU_KBAQUESTIONDETAILS

VARCHAR2(4000)

Yes

34


IAU_KBAVALIDATIONID

NUMBER

Yes

35


IAU_KBAVALIDATIONIDS

VARCHAR2(4000)

Yes

36


IAU_KBAVALIDATIONNAME

VARCHAR2(4000)

Yes

37


IAU_KBAVALIDATIONDETAILS

VARCHAR2(4000)

Yes

38


IAU_KBAREGLOGICDETAILS

VARCHAR2(4000)

Yes

39


IAU_KBAANSWERLOGICDETAILS

VARCHAR2(4000)

Yes

40


IAU_LOGINID

VARCHAR2(255)

Yes

41


IAU_POLICYDETAILS

VARCHAR2(4000)

Yes

42


IAU_POLICYID

NUMBER

Yes

43


IAU_POLICYIDS

VARCHAR2(4000)

Yes

44


IAU_POLICYNAME

NUMBER

Yes

45


IAU_POLICYOVERRIDEDETAILS

VARCHAR2(4000)

Yes

46


IAU_POLICYOVERRIDEID

NUMBER

Yes

47


IAU_POLICYOVERRIDEIDS



VARCHAR2(4000)

Yes

48


IAU_POLICYOVERRIDEROWID

NUMBER

Yes

49


IAU_POLICYRULEMAPID

NUMBER

Yes

50


IAU_POLICYRULEMAPIDS

VARCHAR2(4000)

Yes

51


IAU_POLICYRULEMAPDETAILS

VARCHAR2(4000)

Yes

52


IAU_RULEID

NUMBER

Yes

53


IAU_RULECONDITIONID

NUMBER

Yes

54


IAU_RULECONDITIONIDS

VARCHAR2(4000)

Yes

55


IAU_RULENAME

VARCHAR2(4000)

Yes

56


IAU_RULEDETAILS

VARCHAR2(4000)

Yes

57


IAU_RULECONDITIONMAPID

NUMBER

Yes

58


IAU_RULECONDITIONMAPIDS

VARCHAR2(4000)

Yes

59


IAU_RULEPARAMVALUEDETAILS

VARCHAR2(4000)

Yes

60


IAU_SOURCEPOLICYID

NUMBER

Yes

61


IAU_USERGROUPNAME

VARCHAR2(255)

Yes

62


IAU_USERID

NUMBER

Yes

63


IAU_USERIDS

VARCHAR2(4000)

Yes

64


Table C-15 shows additional tables in the audit schema; these tables support the dynamic metadata model.

Table C-15 Additional Audit Schema Tables

Table NameColumn NameData Type






IAU_COMMON

IAU_ID

NUMBER


IAU_OrgId

VARCHAR(255)


IAU_ComponentId

VARCHAR(255)


IAU_ComponentType

VARCHAR(255)


IAU_MajorVersion

VARCHAR(255)


IAU_MinorVersion

VARCHAR(255)


IAU_InstanceId

VARCHAR(255)


IAU_HostingClientId

VARCHAR(255)


IAU_HostId

VARCHAR(255)


IAU_HostNwaddr

VARCHAR(255)


IAU_ModuleId

VARCHAR(255)


IAU_ProcessId

VARCHAR(255)


IAU_OracleHome

VARCHAR(255)


IAU_HomeInstance

VARCHAR(255)


IAU_UpstreamComponentId

VARCHAR(255)


IAU_DownstreamComponentId

VARCHAR(255)


IAU_ECID

VARCHAR(255)


IAU_RID

VARCHAR(255


IAU_ContextFields

VARCHAR(2000)


IAU_SessionId

VARCHAR(255)


IAU_SecondarySessionId

VARCHAR(255)


IAU_ApplicationName

VARCHAR(255)


IAU_TargetComponentType

VARCHAR(255)


IAU_EventType

VARCHAR(255)


IAU_EventCategory

VARCHAR(255)


IAU_EventStatus

NUMBER


IAU_TstzOriginating

TIMESTAMP


IAU_ThreadId

VARCHAR(255)


IAU_ComponentName

VARCHAR(255)


IAU_Initiator

VARCHAR(255)


IAU_MessageText

VARCHAR(2000)


IAU_FailureCode

VARCHAR(255)


IAU_RemoteIP

VARCHAR(255)


IAU_Target

VARCHAR(255)


IAU_Resource

VARCHAR(255)


IAU_Roles

VARCHAR(255)


IAU_AuthenticationMethod

VARCHAR(255)


IAU_TransactionId

VARCHAR(255)


IAU_DomainName

VARCHAR(255)


IAU_ComponentVersion

VARCHAR(255)


IAU_ComponentData

CLOB




IAU_CUSTOM

IAU_ID

NUMBER


IAU_BOOLEAN_001
through
IAU_BOOLEAN_050

NUMBER


IAU_INT_001
through
IAU_INT_050

NUMBER


IAU_LONG_001
through
IAU_LONG_050

NUMBER


IAU_FLOAT_001
through
IAU_FLOAT_050

NUMBER


IAU_DOUBLE_001
through
IAU_DOUBLE_050

NUMBER


IAU_STRING_001
through
IAU_STRING_100

VARCHAR(2048)


IAU_DATETIME_001
through
IAU_DATETIME_050

TIMESTAMP


IAU_LONGSTRING_001
through
IAU_LONGSTRING_050

CLOB


IAU_BINARY_001
through
IAU_BINARY_050

BLOB




IAU_AuditService

IAU_ID

NUMBER


IAU_TransactionId

VARCHAR(255)




IAU_USERSESSION

IAU_ID

NUMBER


IAU_AuthenticationMethod

VARCHAR(255)


C.4 WLST Commands for Auditing

WLST is the command-line utility for administration of Oracle Fusion Middleware components and applications. It provides another option for administration in addition to Oracle Enterprise Manager Fusion Middleware Control.

Use the WLST commands listed in Table C-16 to view and manage audit policies and the audit store configuration.


Note:

When running audit WLST commands, you must invoke the WLST script from the Oracle Common home. See "Using Custom WLST Commands" in the Oracle Fusion Middleware Administrator's Guide for more information.



See Also:

Oracle Fusion Middleware Third-Party Application Server Guide for details about executing audit commands on third-party application servers.


Table C-16 WLST Audit Commands

Use this command...To...Use with WLST...

getNonJava EEAuditMBeanName


Display the mBean name for a system component.

Online

getAuditPolicy


Display audit policy settings.

Online

setAuditPolicy


Update audit policy settings.

Online

getAuditRepository


Display audit store settings.

Online

setAuditRepository


Update audit store settings.

Online

listAuditEvents


List audit events for one or all components.

Online

exportAuditConfig


Export a component's audit configuration.

Online

importAuditConfig


Import a component's audit configuration.

Online


C.4.1 getNonJava EEAuditMBeanName

Online command that displays the mbean name for system components.

The MBean name must be provided when using WLST commands for system components; since the MBean name can have a complex composition, use this command to get the name.

C.4.1.1 Description

This command displays the mbean name for system components given the instance name, component name, component type, and the name of the Oracle WebLogic Server on which the component's audit mbean is running. The mbean name is a required parameter to other audit WLST commands when managing a system component.

C.4.1.2 Syntax

getNonJava EEAuditMBeanName('instance-name', 'component-name', 'component-type')
ArgumentDefinition

instName

Specifies the name of the application server instance.

compName

Specifies the name of the component instance.

compType

Specifies the type of component. Valid values are ohs, oid, ovd, and WebCache.


C.4.1.3 Example

The following interactive command displays the mBean name for an Oracle Internet Directory component:

wls:/mydomain/serverConfig> getNonJava EEAuditMBeanName(instName='inst1', compName='oid1', compType='oid')

C.4.2 getAuditPolicy

Online command that displays the audit policy settings.

C.4.2.1 Description

Online command that displays audit policy settings including the audit level, special users, custom events, maximum log file size, and maximum log directory size. The component mbean name is an optional parameter. If no parameter is provided, the domain audit policy is displayed.

C.4.2.2 Syntax

getAuditPolicy(['mbeanName', componentType])
ArgumentDefinition

mbeanName

Specifies the name of the component audit MBean for system components.

componentType

Requests the audit policy for a specific component type registered in the audit store. If not specified, the audit policy in jps-config.xml is returned.


C.4.2.3 Example

The following command displays the audit settings for all Java EE components configured in the WebLogic Server domain:

wls:/mydomain/serverConfig> getAuditPolicy()

The following command displays the audit settings for MBean CSAuditProxyMBean:

wls:/mydomain/serverConfig> getAuditPolicy(on='oracle.security.audit.test:type=CSAuditMBean,
name=CSAuditProxyMBean')

C.4.3 setAuditPolicy

Online command that updates an audit policy.

C.4.3.1 Description

Online command that configures the audit policy settings. You can set the audit level, add or remove special users, and add or remove custom events. The component mbean name is required for system components like Oracle Internet Directory and Oracle Virtual Directory.

Remember to call save after issuing setAuditPolicy for system components. Otherwise, the new settings will not take effect.

C.4.3.2 Syntax

setAuditPolicy(['mbeanName'],['filterPreset'],['addSpecialUsers'],
['removeSpecialUsers'],['addCustomEvents'],['removeCustomEvents'], [componentType], [maxDirSize], [maxFileSize], [andCriteria],  [orCriteria], [componentEventsFile])
ArgumentDefinition

mbeanName

Specifies the name of the component audit MBean for system components.

filterPreset

Specifies the audit level to be changed.

addSpecialUsers

Specifies the special users to be added.

removeSpecialUsers

Specifies the special users to be removed.

addCustomEvents

Specifies the custom events to be added.

removeCustomEvents

Specifies the custom events to be removed.

componentType

Specifies the component definition type to be updated. If not specified, the audit configuration defined in jps-config.xml is modified.

maxDirSize

Specifies the maximum size of the log directory.

maxFileSize

Specifies the maximum size of the log file.

andCriteria

Specifies the and criteria in a custom filter preset definition.

orCriteria

Specifies the or criteria in a custom filter preset definition.

componentEventsFile

Specifies a component definition file under the 11g Release 1 (11.1.1) PS5 metadata model. This parameter is required if you wish to create/update an audit policy in the audit store for an 11g Release 1 (11.1.1) PS5 metadata model component, and the filter preset level is set to “Custom”.


C.4.3.3 Example

The following interactive command a) sets the audit level to Low, and b) adds users user2 and user3 while removing user user1 from the policy:

wls:/mydomain/serverConfig> setAuditPolicy (filterPreset='Low',addSpecialUsers='user2,user3',removeSpecialUsers='user1')

The following interactive command adds login events while removing logout events from the policy:

wls:/mydomain/serverConfig> setAuditPolicy(filterPreset='Custom',addCustomEvents='UserLogin',removeCustomEvents='UserLogout') 

C.4.4 getAuditRepository

Online command that displays audit store settings.

C.4.4.1 Description

Online command that displays audit store settings for Java components and applications (for system components like Oracle Internet Directory, the configuration resides in opmn.xml). Also displays database configuration if the data is stored in a database.

C.4.4.2 Syntax

getAuditRepository 

C.4.4.3 Example

The following command displays audit store configuration:

wls:/mydomain/serverConfig> getAuditRepository()

C.4.5 setAuditRepository

Online command that updates audit store settings.

C.4.5.1 Description

Online command that sets the audit store settings for Java components and applications (for system components like Oracle Internet Directory, the store is configured by editing opmn.xml).

C.4.5.2 Syntax

setAuditRepository(['switchToDB'],['dataSourceName'],['interval'])
ArgumentDefinition

switchToDB

If true, switches the store from file to database.

dataSourceName

Specifies the name of the data source.

interval

Specifies intervals at which the audit loader moves file records to the database.


C.4.5.3 Example

The following interactive command changes audit store to a database defined by the data source jdbcAuditDB and sets the audit loader interval to 14 seconds:

wls:/mydomain/serverConfig> setAuditRepository(switchToDB='true',dataSourceName='jdbcAuditDB',interval='14')

Note:

The data source is created using the Oracle WebLogic Server administration console.


C.4.6 listAuditEvents

Online command that displays the definition of a component's audit events, including its attributes.

C.4.6.1 Description

This command displays a component's audit events and attributes. For system components, pass the component mbean name as a parameter. Java applications and services like Oracle Platform Security Services (OPSS) do not need the mbean parameter. Without a component type, all generic attributes applicable to all components are displayed.

C.4.6.2 Syntax

listAuditEvents(['mbeanName'],['componentType'])
ArgumentDefinition

mbeanName

Specifies the name of the component MBean.

componentType

Specifies the component type to limit the list to all events of the component type.


C.4.6.3 Example

The following command displays audit events for an Oracle Internet Directory instance:

wls:/mydomain/serverConfig> listAuditEvents(on='oracle.as.management.mbeans.register:
type=component.auditconfig,name=auditconfig1,instance=oid1,component=oid')

The following command displays audit events for Oracle Identity Federation:

wls:/mydomain/serverConfig> listAuditEvents(componentType='oif')

C.4.7 exportAuditConfig

Online command that exports a component's audit configuration.


See Also:

This command is useful in migrating to production environments. For details, see Section 6.5.3, "Migrating Audit Policies".


C.4.7.1 Description

This command exports the audit configuration to a file. For system components, pass the component mbean name as a parameter. Java applications and services like Oracle Platform Security Services (OPSS) do not need the mbean parameter.

C.4.7.2 Syntax

exportAuditConfig(['mbeanName'],'fileName', [componentType])
ArgumentDefinition

mbeanName

Specifies the name of the system component MBean.

fileName

Specifies the path and file name to which the audit configuration should be exported.

componentType

Specifies that only events of the given component be exported to the file. If not specified, the audit configuration in jps-config.xml is exported.


C.4.7.3 Example

The following interactive command exports the audit configuration for a component:

wls:/mydomain/serverConfig> exportAuditConfig(on='oracle.security.audit.test:type=CSAuditMBean,name=CSAuditProxyMBean',fileName='/tmp/auditconfig')

The following interactive command exports the audit configuration for a component; no mBean is specified:

wls:/mydomain/serverConfig> exportAuditConfig(fileName='/tmp/auditconfig')

C.4.8 importAuditConfig

Online command that imports a component's audit configuration.


See Also:

This command is useful in migrating to production environments. For details, see Section 6.5.3, "Migrating Audit Policies".


C.4.8.1 Description

This command imports the audit configuration from an external file. For system components, pass the component mbean name as a parameter. Java applications and services like Oracle Platform Security Services (OPSS) do not need the mbean parameter.

Remember to call save after issuing importAuditConfig for system components. Otherwise, the new settings will not take effect.

C.4.8.2 Syntax

importAuditConfig(['mbeanName'],'fileName', [componentType])
ArgumentDefinition

mbeanName

Specifies the name of the system component MBean.

fileName

Specifies the path and file name from which the audit configuration should be imported.

componentType

Specifies that only events of the given component be imported from the file. If not specified, the audit configuration in jps-config.xml is imported.


C.4.8.3 Example

The following interactive command imports the audit configuration for a component:

wls:/mydomain/serverConfig> importAuditConfig(on='oracle.security.audit.test:type=CSAuditMBean,name=CSAuditProxyMBean',fileName='/tmp/auditconfig')

The following interactive command imports the audit configuration for a Java EE application (no mBean is specified):

wls:/mydomain/serverConfig> importAuditConfig(fileName='/tmp/auditconfig')

C.5 Audit Filter Expression Syntax

When you select a custom audit policy, you have the option of specifying a filter expression along with an event.

For example, you can use the following expression:

Host Id -eq "myhost123"

to enable the audit event for a particular host only.


You enter this expression either through the Fusion Middleware Control Edit Filter Dialog or through the setAuditPolicy WLST command.

There are some syntax rules you should follow when creating a filter expression.

The expression can either be a Boolean expression or a literal.

<Expr> ::= <BooleanExpression> | <BooleanLiteral>

A boolean expression can use combinations of RelationalExpression with –and, -or , -not and parenthesis. For example, (Host Id -eq "stadl17" -or ").

<BooleanExpression> ::=  <RelationalExpression>
   | “(” <BooleanExpression> “)”
   | <BooleanExpression> “-and” <BooleanExpression>
   | <BooleanExpression> “-or” <BooleanExpression>
   | “-not” <BooleanExpression>

A relational expression compares an attribute name (on the left hand side) with a literal (on the right-hand side). The literal and the operator must be of the correct data type for the attribute.

<RelationalExpression> ::= <AttributeName> <RelationalOperator> <Literal>

Relational operators are particular to data types:

  • -eq, -ne can be used with all data types

  • -contains, -startswith, -endswith can be only used with strings

  • -contains_case, -startswith_case and -endswith_case are case sensitive versions of the above three functions

  • -lt, -le, -gt, -ge can be used with numeric and datetime

<RelationalOperator> : = "-eq" | "-ne" | "-lt" | "-le" | "-gt" | "-ge"
   | "-contains" | "-contains_case"
   | "-startswith" | "-startswith_case"
   | "-endswith" | "-endswith_case"

Rules for literals are as follows:

  • Boolean literals are true or false, without quotes

  • Date time literals have to be in double quotes and can be in many different formats; "June 25, 2006", "06/26/2006 2:00 pm" are all valid

  • String literals have to be quotes, back-slash can be used to escape an embedded double quote

  • Numeric literals are in their usual format

<Literal> ::=  <NumericLiteral> | <BooleanLiteral> | <DateTimeLiteral> | <StringLiteral><BooleanLiteral> ::= "true” | "false”

C.6 Naming and Logging Format of Audit Files

This section explains the rules that are used to maintain audit files.

For Java components (both Java EE and Java SE), the file containing audit records is named "audit.log".

When that file is full (it reaches the configured maximum audit file size which is 100MB), it is renamed to "audit1.log" and a new "audit.log" is created. If this file too gets full, the audit.log file is renamed to "audit2.log" and a new audit.log is created.

This continues until the configured maximum audit directory size is reached (default is 0, which means unlimited size). When the max directory size is reached, the oldest auditn.log file is deleted.

If you have configured a database audit store, then the audit loader reads these files and transfers the records to the database in batches. After reading a complete audit<n>.log file, it deletes the file.


Note:

The audit loader never deletes the "current" file, that is, audit.log; it only deletes archive files audit<n>.log.


OPMN-managed components follow the same model, except the file name is slightly different. It has the process ID embedded in the file name; thus, if the process id is 11925 the current file is called "audit-pid11925.log", and after rotation it will be called audit-pid11925-1.log.

For applications with audit definitions in the dynamic model, the file name format is audit_major version number_minor version number.log; for example, audit_1_2.log.

Here is a sample audit.log file:

#Fields:Date Time Initiator EventType EventStatus MessageText HomeInstance ECID RID ContextFields SessionId TargetComponentType ApplicationName EventCategory ThreadId InitiatorDN TargetDN FailureCode RemoteIP Target Resource Roles CodeSource InitiatorGUID Principals PermissionAction PermissionClass mapName key
#Remark Values:ComponentType="JPS"
2008-12-08 10:46:05.492 - "CheckAuthorization" true "Oracle Platform Security Authorization Check Permission SUCCEEDED." - - - - - - - "Authorization" "48" - - "true" - - "(oracle.security.jps.service.policystore.PolicyStoreAccessPermission context=APPLICATION,name=SimpleServlet getApplicationPolicy)" - "file:/oracle/work/middleware/oracle_common/modules/oracle.jps_11.1.1/jps-internal.jar" - "[]" - - - - 

This file follows the W3C extended logging format, which is a very common log format that is used by many Web Servers e.g. Apache and IIS:

  • The first line is a "#Fields" line; it specifies all the fields in the rest of the file.

  • The second line is a comment like "#Remark" which has a comment indicating some common attributes like the ComponentType.

  • All subsequent lines are data lines; they follow the exact format defined in the "#Fields" line. All attributes are separated by spaces, mussing attributes are indicated by a dash.

PKmPK AOEBPS/devauthoriz.htmb? Authorization for Java SE Applications

23 Authorization for Java SE Applications

This chapter explains how to develop and configure authorization in Java SE applications and lists some unsupported methods in the following sections:

For details about the policy model, see Section 20.3, "The JAAS/OPSS Authorization Model."

23.1 Configuring Policy and Credential Stores in Java SE Applications

The configuration of policy and credential stores in Java SE applications is explained in the following sections:

For details about configuring authentication for Java SE applications, see Section 22.2, "Authentication for Java SE Applications."

System properties should be set, as appropriate, for authorization to work in Java SE applications. For a complete list of properties, see Section F.1, "OPSS System Properties."

A Java SE application can use file-, LDAP-, or DB-based store providers; these services are configured in the application file jps-config-jse.xml.

23.1.1 Configuring File-Based Policy and Credential Stores

A file-based policy store is specified in the file system-jazn-data.xml; a file-based credential store is specified in the file cwallet.sso (this wallet file should not be confused with the bootstrap file, also named cwallet.sso, which contains the credentials to access LDAP stores, when the application security is LDAP-based).

For details about wallets, see Section 21.4.3, "Using a Wallet-Based Credential Store." For details about modifying or adding bootstrap credentials, see Section 10.5.5, "modifyBootStrapCredential," and Section 10.5.6, "addBootStrapCredential."

The following fragments illustrate the configuration of file-based policy and credential stores, and the jpsContext that reference them:

<serviceProviders>
  <serviceProvider type="CREDENTIAL_STORE" name="credstoressp"
        class="oracle.security.jps.internal.credstore.ssp.SspCredentialStoreProvider">
    <description>SecretStore-based CSF Provider</description>
  </serviceProvider>
  <serviceProvider type="POLICY_STORE" name="policystore.xml.provider"
        class="oracle.security.jps.internal.policystore.xml.XmlPolicyStoreProvider">
  <description>XML-based PolicyStore Provider</description>
  </serviceProvider>
</serviceProviders>

<serviceInstances>
  <serviceInstance name="credstore" provider="credstoressp" location="./">
    <description>File-based Credential Store Service Instance</description>
  </serviceInstance>
 
  <serviceInstance name="policystore.xml" provider="policystore.xml.provider" location="./system-jazn-data.xml">
   <description>File-based Policy Store Service Instance</description>
   <property name="oracle.security.jps.policy.principal.cache.key" value="false"/>
  </serviceInstance>
</serviceInstances>

<jpsContexts default="TestJSE">
  <jpsContext name="TestJSE">
            <serviceInstanceRef ref="credstore"/>
            <serviceInstanceRef ref="policystore.xml"/>
    ...
  </jpsContext>
  ...
</jpsContexts>

Note the required setting of the property oracle.security.jps.policy.principal.cache.key to false in the policy store instance.

23.1.2 Configuring LDAP-Based Policy and Credential Stores

This section assumes that an LDAP-based store has been set to be used as the policy and credential stores; for details about setting up nodes in an Oracle Internet Directory, see section Section 8.2.2, "Prerequisites to Using an LDAP-Based Security Store."

The following fragments illustrate the configurations of providers and instances for LDAP-based policy and credential stores for a Java SE application:

<serviceProviders
  <serviceProvider type="POLICY_STORE" mame="ldap.policystore.provider"
 class=oracle.security.jps.internal.policystore.ldap.LdapPolicyStoreProvider"/>
   
  <serviceProvider type="CREDENTIAL_STORE" mame="ldap.credential.provider"
 class=oracle.security.jps.internal.credstore.ldap.LdapCredentialStoreProvider"/>
</serviceProviders>

<serviceInstances>
 <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=PS1domainRC3" name="oracle.security.jps.farm.name"/>
  <property value="cn=myTestNode" name="oracle.security.jps.ldap.root.name"/>
  <property value="ldap://myComp.com:1234" name="ldap.url"/>
 </serviceInstance>

 <serviceInstance provider="ldap.credential.provider" name="credstore.ldap">
  <property value="bootstrap" name="bootstrap.security.principal.key"/>
  <property value="cn=PS1domainRC3" name="oracle.security.jps.farm.name"/>
  <property value="cn=myTestNode" name="oracle.security.jps.ldap.root.name"/>
  <property value="ldap://myComp.com:1234" name="ldap.url"/>
 </serviceInstance>
</serviceInstances>

The following fragment illustrates the configuration of the bootstrap credentials file (cwallet.sso), which allows the program access to the LDAP server:

<serviceInstance location="./bootstrap" provider="credstoressp" name="bootstrap.cred">
  <property value="./bootstrap" name="location"/>
</serviceInstance>

The following fragment illustrates the configuration of the necessary jpsContexts that reference the instances above:

<jpsContexts default="TestJSE">
  <jpsContext name="TestJSE">
    <serviceInstanceRef ref="policystore.ldap"/>
    <serviceInstanceRef ref="credstore.ldap"/>
  </jpsContext>
  <jpsContext name="bootstrap_credstore_context">
    <serviceInstanceRef ref="bootstrap.cred"/>  
  </jpsContext>
</jpsContexts>

The following code fragment illustrates how to obtain programmatically a reference to the LDAP-based policy store configured above, and it assumes that the system property oracle.security.jps.config has been set to the location of the file jps-config-jse.xml:

String contextName="TestJSE"; ...
public static PolicyStore getPolicyStore(String contextName) {
      try-block    
            JpsContextFactory ctxFact;  
            ctxFact = JpsContextFactory.getContextFactory();   
            JpsContext ctx = ctxFact.getContext(contextName);  
            return ctx.getServiceInstance(PolicyStore.class);      
      catch-block
...

23.1.3 Configuring DB-Based OPSS Security Stores

This section assumes that a DB-based store has been set to be used as the OPSS security store. For details about setting up nodes in a DB, see section Section 8.3.1, "Prerequisites to Using a DB-Based Security Store."

Note the following important points regarding the sample configuration below:

  • The value of the configuration property jdbc.url should be identical to the name of the JDBC data source entered when the data source was created.

  • The values of the bootstrap credentials (map and key) must match those passed to the WLST script addBootStrapCredential when the bootstrap credential was created.

The following fragment illustrates configuration of DB-based policy, credential, and key stores in the file jps-config-jse.xml:

<jpsConfig  …>
  <propertySets>
   <propertySet name="props.db.1">
    <property value="cn=myDomain" name="oracle.security.jps.farm.name"/>
    <property value="DB_ORACLE" name="server.type"/>
    <property value="cn=myRoot" name="oracle.security.jps.ldap.root.name"/>
    <property name="jdbc.url" value="jdbc:oracle:thin:@myhost.com:1521/srv_name"/>
    <property name="jdbc.driver" value="oracle.jdbc.driver.OracleDriver"/>
    <property name="bootstrap.security.principal.key" value="myKeyName" />
    <property name="bootstrap.security.principal.map" value="myMapName" />
   </propertySet> 
  </propertySets>
  <serviceProviders>
    <serviceProvider class="oracle.security.jps.internal.policystore.OPSSPolicyStoreProvider"
           type="POLICY_STORE" name="policy.rdbms">
      <description>DBMS based PolicyStore</description>
    </serviceProvider>

    <serviceProvider class="oracle.security.jps.internal.credstore.rdbms.DbmsCredentialStoreProvider"
               type="CREDENTIAL_STORE" name="db.credentialstore.provider" >

  <serviceProvider class="oracle.security.jps.internal.keystore.KeyStoreProvider" 
               type="KEY_STORE" name="keystore.provider" >
    <property name="provider.property.name" value="owsm"/>
  </serviceProvider>
 </serviceProviders>
 
 <serviceInstances>
   <serviceInstance name="policystore.rdbms" provider="db.policystore.provider">  
    <propertySetRef ref = "props.db.1"/>
    <property name="policystore.type"  value="DB_ORACLE"/>
   </serviceInstance>

   <serviceInstance name="credstore.rdbms" provider="db.credstore.provider">
    <propertySetRef ref = "props.db.1"/>  
   </serviceInstance>
 
   <serviceInstance name="keystore.rdbms" provider="db.keystore.provider">  
    <propertySetRef ref = "props.db.1"/> 
    <property name="keystore.provider.type"  value="db"/>
   </serviceInstance>
  </serviceInstances>
 
  <jpsContexts default="default">
    <jpsContext name="default">
      <serviceInstanceRef ref="policystore.rdbms"/>      
      <serviceInstanceRef ref="credstore.rdbms"/>
      <serviceInstanceRef ref="keystore.rdbms"/>
    </jpsContext>
  </jpsContexts>
</jpsConfig>

23.2 Unsupported Methods for File-Based Policy Stores

This release does not support, for file-based policy stores, methods involving the following features:

  • Bulk authorization

  • Complex queries

  • Cascading deletions

Bulk authorization is encapsulated in the following method of the interface oracle.security.jps.service.policystore:

java.util.Set<ResourceActionsEntry>
checkBulkAuthorization(javax.security.auth.Subject subject,
                       java.util.Set<ResourceActionsEntry> requestedResources)
                       throws PolicyStoreException

Complex queries relates to any method that takes a query. When the policy store is file-based, the query must be simple; if such a method is passed a complex query and the policy store is file-based, the method will throw an exception.

A simple query is a query with just one search criterion; a complex query is a query with two or more search criteria; each call to addQuery adds a criterion to the query.

The following code fragment that illustrates the building of a simple query that returns of all permissions with a display name matching the string MyDisplayName:

PermissionSetSearchQuery query = new PermissionSetSearchQuery();
query.addQuery(PermissionSetSearchQuery.SEARCH_PROPERTY.DISPLAY_NAME,
               false,
               ComparatorType.EQUALITY,
               "MyDisplayName",
               BaseSearchQuery.MATCHER.EXACT);
getPermissionSets(query);

The following example illustrates the building of a complex query that returns all permission sets with a given resource type and a given resource instance name:

PermissionSetSearchQuery query = new PermissionSetSearchQuery();
query.addQuery(PermissionSetSearchQuery.SEARCH_PROPERTY.RESOURCE_TYPE,
               false,
               ComparatorType.EQUALITY, 
               "MyResourceType",
               BaseSearchQuery.MATCHER.EXACT);
  
query.addQuery(PermissionSetSearchQuery.SEARCH_PROPERTY.RESOURCE_NAME,
               false, 
               ComparatorType.EQUALITY, 
               "MyResourceInstanceName", 
               BaseSearchQuery.MATCHER.EXACT);
 
query.setANDMatch();
getPermissionSets(query);

Cascading deletions relates to any method that includes the Boolean argument cascadeDelete. The only value allowed for this argument in case the policy store is file-based is FALSE. Here is an example of such a method in the interface ResourceTypeManager:

void deleteResourceType(EntryReference rtRef, boolean cascadeDelete)
                 throws PolicyObjectNotFoundException,
                        PolicyStoreOperationNotAllowedException,
                        PolicyStoreException
PKu[Dg?b?PK AOEBPS/devauthn.htm Authentication for Java SE Applicaitons

22 Authentication for Java SE Applicaitons

The information in this chapter applies only to Java SE applications, and the audience are developers of Java SE applications. For details about authentication for Java EE applications, see any of the documents listed in Links to Authentication Topics for Java EE Applications.

This chapter includes in the following topics:

22.1 Links to Authentication Topics for Java EE Applications

The following documents are a good source of information for developing authentication in Java EE applications: