Using the OPSS Common Audit Framework

<Do not delete this text because it is a placeholder for the generated list of "main" topics when run in a browser>

Purpose

This tutorial covers using the Oracle Platform Security Services (OPSS) common audit framework.

After completing this exercise, you should be able to:

Please note that this OBE does not cover configuring and using an audit database store, and the features associated with it.

Time to Complete

Approximately 1 hour

Overview

OPSS is Oracle's security framework for developing and managing security services in Java SE and EE environments. This tutorial is Using the OPSS Common Audit Framework.

Using the OPSS Common Audit Framework for Java Components

This is the architecture that depicts the OPSS Common Audit Framework for Java component environments. This OBE covers how to use the OPSS auditing features in a WebLogic domain. The environment consists of the following:

Using the OPSS Common Audit Framework for System Components

This is the architecture that depicts the OPSS Common Audit Framework for system component environments. This OBE covers how to use the OPSS auditing features in an IdM domain. The environment consists of the following:

Software and Hardware Requirements

The following is a list of requirements:

Prerequisites

Before starting this tutorial, complete the following prerequisites:

.

This OBE requires that you have completed the OPSS Environment Set Up OBE.

.

This OBE requires that you have completed the OPSS Configuring an OID Authentication Provider in WebLogic OBE.

Using the OPSS Common Audit Framework  for Java Components

Follow the steps below to configure and use the OPSS auditing features for Java components:

.

Start myxmldomain:

Click the icon to open a terminal window. Enter the following commands to start the myxmldomain AdminServer:

cd $DOMAINS/myxmldomain
./startWebLogic.sh

Make sure the WebLogic Server is running before continuing on to the next step.

 

.

Deploy OpssADFDemoApp:

Execute the following commands to deploy the practice application to the domain:

cd $LAB_HOME/bin
./deployapp.sh

Your output should resemble the following:

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

Connecting to t3://localhost:7001 with userid weblogic ...
Successfully connected to Admin Server 'AdminServer' that belongs to domain 'myxmldomain'.

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.

***Connected successfully***
Deploying OpssADFDemoApp application: /home/oracle/labs/apps/OpssADFDemoApp.ear
Deploying application from /home/oracle/labs/apps/OpssADFDemoApp.ear to targets (upload=false) ...
<Mar 26, 2012 12:50:03 AM PDT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating deploy operation for application, OpssADFDemoApp [archive: /home/oracle/labs/apps/OpssADFDemoApp.ear], to AdminServer .>
........Completed the deployment of Application with status completed
Current Status of your Deployment:
Deployment command type: deploy
Deployment State : completed
Deployment Message : [Deployer:149194]Operation 'deploy' on application 'OpssADFDemoApp [Version=V2.0]' has succeeded on 'AdminServer'

 

.

Examine OPSS audit-related files:

When using the OPSS auditing feature with Java components, it uses the following files. Locate and open each file to examine its contents so you can become familiar with them.

File Purpose and Location
jps-config.xml This is the main OPSS configuration file. When changes are made using FMW Control or WLST, this file stores the configuration. It is located in the $DOMAIN_HOME/config/fmwconfig folder. Find the serviceInstance element that contains the configuration for auditing.
audit-store.xml This is the file-based audit metadata store file. This file contains the format of audit event records that get written to audit logs. It is located in the $DOMAIN_HOME/config/fmwconfig folder.
audit_1_0.log This is the bus-stop file of the domain where all audit event records are written. This file will not exist yet if no audit records have been written. It will be located in the $DOMAIN_HOME/servers/${SERVER_NAME}/logs/auditlogs/JPS folder.

 

.

Configure audit policies:

Execute the following commands to configure a custom audit policy that triggers audit events for authorization requests, namely the CheckPermission, CheckSubject, and IsAccessAllowed calls made by the application.

$ $MW_HOME/Oracle_IDM1/common/bin/wlst.sh
$ connect('weblogic','welcome1')
$ setAuditPolicy(filterPreset='Custom',addCustomEvents='JPS: CheckPermission, CheckSubject, IsAccessAllowed', componentType='JPS')
$ exit()

The server does not need to be restarted. Your audit policy is now configured and stored in the OPSS audit metadata store.

 

.

Run application:

Now that an audit policy is configured for the domain, you must run an application that performs OPSS authorization requests to trigger audit events so that records are written to the audit log.

Using Firefox, browse to http://localhost:7001/OpssADFDemoApp/faces/view1 to use the OpssADFDemoApp application. Click the Start Here button as shown below.

You are then presented with a log in page. Use one of the credentials below to log in to trigger auditing events.

Credential 1:
User name: joeuser
Password: welcome1

Credential 2:
User name: weblogic
Password: welcome1

Within the application, an authorization request is made to determine if the currently logged in user can access the task flow that shows the calendar for the development workspace. Users that can see the calendar are granted access while users that cannot see the calendar are denied access. These events should have triggered audit records to get written to the domain's audit log file. The joeuser account should be able to see the calendar, and the weblogic user should not be able to see the calendar.

 

.

Examine bus-stop file:

Within a terminal window open the $DOMAIN_HOME/servers/AdminServer/logs/auditlogs/JPS/audit_1_0.log file for viewing. Search the file for audit records associated with the logins you just performed.

Your output should look similar to the following entries:

2012-04-27 01:24:50.779 - "CheckSubject" true "Executing privileged action in doAsPrivileged mode as subject null." "OpssADFDemoApp(V2.0)" - - "11d1def534ea1be0:-7ee78cc2:136f07dd47b:-8000-000000000000018c,0" "Authorization" "success" - - - - - - - - - "file:/u01/app/oracle/Middleware/oracle_common/modules/oracle.jps_11.1.1/jps-ee.jar" - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - "[]" - - - - - - - - - - - - - - - - - - - - - - "(principals([(Name:joeuser) (Class name:weblogic.security.principal.WLSUserImpl)] [(Name:employees) (Class name:weblogic.security.principal.WLSGroupImpl)] [(Name:authenticated-role) (Class name:oracle.security.jps.internal.core.principals.JpsAuthenticatedRoleImpl)] [(Name:Developer) (Class name:oracle.security.jps.service.policystore.ApplicationRole)] [(Name:anonymous-role) (Class name:oracle.security.jps.internal.core.principals.JpsAnonymousRoleImpl)] ))" - - - - - - - - "1" "0" - - - - - - - "96" -

2012-04-27 01:24:52.779 "joeuser" "CheckPermission" true "Authorization check permission succeeded." "OpssADFDemoApp(V2.0)" - - "11d1def534ea1be0:-7ee78cc2:136f07dd47b:-8000-0000000000000190,0" "Authorization" "success" - - - - - - - - - "file:/u01/app/oracle/Middleware/oracle_common/modules/oracle.adf.share_11.1.1/adf-share-support.jar" - - - - - - - - - - - - - - - - - - - - - - - - - - "view" "true" "TaskFlowPermission" - - "/WEB-INF/taskFlowCall1.xml#taskFlowCall1" - - - - - - - - - - - - - - - - - - - - - - - "" - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - "1" "0" - - "oracle.adf.controller.security.TaskFlowPermission//WEB-INF/taskFlowCall1.xml#taskFlowCall1/view" - - - - "103" -

 

.

Undeploy application and shut down myxmldomain:

There is another OBE exercise that guides you through deploying the OpssADFDemoApp using FMW Control. You must undeploy the application now so this practice will work properly. Execute the following commands to undeploy the practice application to the domain:

cd $LAB_HOME/bin
./undeployapp.sh

Your output should resemble the following:

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

Connecting to t3://localhost:7001 with userid weblogic ...
Successfully connected to Admin Server 'AdminServer' that belongs to domain 'myxmldomain'.

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.

***Connected successfully***
Undeploying OpssADFDemoApp application...
Undeploying application OpssADFDemoApp ...
<Mar 26, 2012 8:22:59 AM PDT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating undeploy operation for application, OpssADFDemoApp#V2.0 [archive: null], to AdminServer .>
.Completed the undeployment of Application with status completed
Current Status of your Deployment:
Deployment command type: undeploy
Deployment State : completed
Deployment Message : [Deployer:149194]Operation 'remove' on application 'OpssADFDemoApp [Version=V2.0]' has succeeded on 'AdminServer'

Shutdown myxmldomain by pressing Ctrl-C in the terminal window where you started it.

 

Using the OPSS Common Audit Framework for System Components

Follow the steps below to configure and use the OPSS auditing features for System components:

.

Start IDMDomain:

Click the icon to open a terminal window. Enter the following commands to start the IDMDomain AdminServer:

cd $DOMAINS/IDMDomain
./startWebLogic.sh

Enter weblogic and welcome1 as the boot credentials for starting up the server.

Make sure the WebLogic Server is running before continuing on to the next step.

 

.

Examine OPSS audit-related files:

When using the OPSS auditing feature with System components, it uses the following files.

File Purpose and Location
audit-config.xml

This file is used to configure auditing for system components such as, Oracle HTTP Server and Oracle Web Cache. These components do not have a jps-config.xml file.

jps-config-jse.xml This file is used to configure auditing for system components such as, Oracle Reports and Oracle Virtual Directory. Note that the audit configuration for OID is stored in the database.
audit-store.xml This is the file-based audit metadata store file. This file contains the format of audit event records that get written to audit logs. It is located in the $DOMAIN_HOME/config/fmwconfig folder.
audit_$PID.log This is the bus-stop file of the component instance where all audit event records are written. This file will not exist yet if no audit records have been written. It will be located in the INSTANCE_HOME/auditlogs/Component_Type/Component_Name folder. So in the case of your OID instance it can be found at $MW_HOME/asinst1/auditlogs/OID/oid1.

 

.

Configure audit policies:

Open Firefox and browse to http://localhost:7001/em to open Enterprise Manager (EM) and gain access to FMW Control. Login using the following credentials:

User name: weblogic
Password: welcome1

Open the Audit Policy page by expanding the Identity and Access node on the left-hand pane, then right-clicking oid1 and selecting Security>Audit Policy.

Expand the Oracle Identity Management node if it is not already expanded. Feel free to explore the interface for a few moments. When you are ready, select the Custom Audit Level, and select the main Enable Audit check box. This will automatically select all check boxes for OID. This configures auditing for all authentication requests that are made against OID, inlcuding log in and log out events. Click Apply to save your changes and put them into effect.

 

.

Generate audit event records:

Now that an audit policy is configured for the OID component, you must perform some operations that trigger audit events so audit records get written to the log file.

Within an available terminal window, execute the following commands to watch for audit events for OID:

cd $MW_HOME/asinst_1/auditlogs/OID/oid1

Perform a directory lookup to see the correct file to view:

ls -l

Find the file with today's date on it and take note of the process identifier (PID).

Run the following command to keep an open tail of the audit file. Replace the PID portion of the file name with the PID you noted in the previous instruction.

tail -f audit-pidPID.log

You should see output that shows either fields or audit records. Press the enter key a few times to create some blank lines to make it easier to see when there are new records.

Open JXplorer just as you did in the OPSS 11g Environment Set Up OBE. Use JXplorer to connect and disconnect from OID. Each of these events is a log in and log out event to OID and as you log in and log out, you should see audit records displayed in the terminal window that correspond to your log in and log out events. Also try logging in with invalid credentials so you can see some failure audit events.

Here are the OID log in credentials for reference:

User name: joeuser
Password: welcome1

2012-03-26 22:39:31.677037 "OID" - - - "10" - - "UserLogout" TRUE - "cn=emd admin,cn=oracle internet directory" "Operation name: unbind" - "::ffff:127.0.0.1" - - - - "unbind" -


2012-03-26 23:00:48.642235 "OID" "004j2pOMJ6EFw000jzwkno0000rL00002I,0" - - "13" - - "UserLogin" TRUE - "cn=orcladmin" "Operation name: bind" - "::ffff:127.0.0.1" - - - - "bind" "Simple:SSL NoAuth:DN/Password Based"


2012-03-26 23:07:49.255195 "OID" - - - "13" - - "UserLogout" TRUE - "cn=orcladmin" "Operation name: unbind" - "::ffff:127.0.0.1" - - - - "unbind" -

 

.

Shut down IDMDomain:

Shutdown IDMDomain by pressing Ctrl-C in the terminal window where you started it.

 

Summary

You have now completed the Using the OPSS Common Audit Framework OBE . You are ready to continue with the other OBE tutorials included in this series.

In this tutorial, you have learned how to:

Resources

Credits

Hardware and Software Engineered to Work Together Copyright © 2012, Oracle and/or its affiliates. All rights reserved