This chapter contains information about managing Oracle Fusion Middleware security on IBM WebSphere, and it explains the particularities of some Oracle Platform Security Services (OPSS) features on that platform.
OPSS is a security platform that can be used to secure applications deployed in any of the supported platforms or in standalone applications.
Only topics that apply specifically to IBM WebSphere are included in this chapter; those that apply uniformly to all platforms are not described here, but can be found in Oracle Fusion Middleware Application Security Guide.
This chapter contains the following sections:
On IBM WebSphere, OPSS supports LDAP-based registries only; in particular, it does not support WebSphere's built-in file-based user registry.
For information about the list of LDAP authenticators supported for Oracle Fusion Middleware, visit http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
For the special configuration required for the Open LDAP 2.2, see Oracle Fusion Middleware Application Security Guide.
The configuration and seeding of a repository is explained in the following sections:
The configuration of an LDAP registry on IBM WebSphere is accomplished with the command configureIdentityStore, an online administration command with the following syntax:
wsadmin> Opss.configureIdentityStore(propsFileLoc="fileLocation")
propsFileLoc specifies the location of the properties file, which contains the property settings for the LDAP identity store. This command modifies the configuration file jps-config.xml to include the specifications in the properties file.
After running Opss.configurIdentityStore, restart the server.
The following properties are required and must be specified in the properties file:
ldap.host
ldap.port
admin.id
admin.pass
idstore.type
user.search.bases
user.id.map
group.id.map
group.member.id.map
group.search.bases
primary.admin.id
The following list includes optional properties specific to an IBM WebSphere registry:
group.filter
user.filter
The following sample illustrates the property settings for an Oracle Directory Server Enterprise Edition identity store:
user.search.bases=cn=Users,dc=us,dc=oracle,dc=com group.search.bases=cn=Groups,dc=us,dc=oracle,dc=com subscriber.name=dc=us,dc=oracle,dc=com ldap.host=stamw10.examplehost.exampledomain.com ldap.port=3060 # admin.id must be the full DN of the user in the LDAP admin.id=cn=orcladmin admin.pass=welcome1 user.filter=(&(uid=%v)(objectclass=person)) group.filter=(&(cn=%v)(objectclass=groupofuniquenames)) user.id.map=:uid group.id.map=:cn group.member.id.map=groupofuniquenames:uniquemember ssl=false # primary.admin.id indicates the user you want to be the primary # administrative user on WebSphere. It should be a user under user.search.bases. # later you need to use this user's user name and password to manage or # start/stop the server. primary.admin.id=orcladmin # optional, default to "OID" idstore.type=IPLANET # other, optional identity store properties can be configured in this file. username.attr=cn
The list of valid identity store types is the following:
OID
IPLANET
OVD
ACTIVE_DIRECTORY
OPEN_LDAP
Note:
When configuring Oracle Unified Directory (OUD) as an LDAP registry on IBM WebSphere, setidstore.type to "IPLANET".Some Oracle Fusion Middleware components require that certain users and groups be present in the IBM WebSphere identity store. To ensure that this requirement is met, use any tools to seed the required data; in particular, you can use an LDIF file and the LDAP utility bulkload to load users and groups into the identity store. Here is a sample LDIF file:
dn: cn=OracleSystemUser,dc=com userPassword: welcome1 sn: OracleSystemUser cn: OracleSystemUser objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top dn: cn=OracleSystemGroup,dc=com cn: OracleSystemGroup objectclass: groupOfUniqueNames dn: cn=Administrators,dc=com cn: Administrators objectclass: groupOfUniqueNames dn: cn=SystemMDBRole,dc=com cn: SystemMDBRole objectclass: groupOfUniqueNames uniquemember: cn=OracleSystemUser,dc=com
HTTP clients can pass identity information to WebSphere Application Server using the Trust Association Interceptor (TAI). OPSS uses TAI as the asserter that intercepts calls coming into WebSphere cells to support identity propagation across containers and cells.
To configure TAI, proceed as follows:
Login to the IBM WebSphere Administrative Console.
Select Security > Click Global Security.
In the opened page, navigate to Authentication.
Expand Web and SIP security, and click Trust Association.
Check the box Enable Trust Association and save your changes.
Return to the Trust Association page and click Additional Properties > Interceptors.
Click New.
In the Interceptor Class Name box, enter the following string:
oracle.security.jps.was.providers.trust.TrustServiceAsserterTAI
This class is packaged in the JAR file jps-was.jar.
Save your changes.
The migration of application policies at deployment is controlled by several parameters configured in the file META-INF/opss-application.xml. For an example of this file, see Sample opss-application File. To reassociate the policy store after deployment, see Reassociating Policies with reassociateSecurityStore.
The supported parameters, including configuration examples, are explained in the following sections:
Note that the following parameters are not supported on IBM WebSphere:
JpsApplicationLifecycleListener Jps.apppolicy.idstoreartifact.migration Jps.policystore.migration.validate.principal
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 IBM WebSphere, it is configured as illustrated in the following fragment:
<service type="POLICY_STORE"> <property name="jps.policystore.applicationid" value="stripeid" /> <property name="jps.policystore.migration" value="overwrite" /> <property name="jps.policystore.removal" value="off" /> </service>
For more details about this parameter, see Oracle Fusion Middleware Application Security Guide.
This parameter specifies the target stripe into which policies are migrated.
On IBM WebSphere, it is configured as illustrated in the following fragment:
<service type="POLICY_STORE"> <property name="jps.policystore.applicationid" value="stripeid" /> <property name="jps.policystore.migration" value="overwrite" /> <property name="jps.policystore.removal" value="off" /> </service>
For more details about this parameter, see Oracle Fusion Middleware Application Security Guide.
This parameter specifies whether the removal of policies at undeployment should not take place.
On IBM WebSphere, it is configured as illustrated in the following fragment:
<service type="POLICY_STORE"> <property name="jps.policystore.applicationid" value="stripeid" /> <property name="jps.policystore.migration" value="overwrite" /> <property name="jps.policystore.removal" value="off" /> </service>
For more details about this parameter, see Oracle Fusion Middleware Application Security Guide.
The migration of application credentials at deployment is controlled by a parameter configured in the file META-INF/opss-application.xml. For an example of this file, see Sample opss-application File.
The supported parameter, including a configuration example, are explained in the following section:
Note that the following parameter is not supported on IBM WebSphere:
jps.ApplicationLifecycleListener
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 IBM WebSphere, it is configured as illustrated in the following fragment:
<service type="CREDENTIAL_STORE"> <property name="jps.credstore.migration" value="overwrite" /> </service>
Setting jps.credstore.migration to overwrite requires that the system property jps.app.credential.overwrite.allowed be set to true.
For more details about this parameter, see Oracle Fusion Middleware Application Security Guide.
For complete details about the scrip reassociateSecurityStore to reassociate the policy store, see Oracle Fusion Middleware Application Security Guide. Since this script is likely to run for some time, to avoid exceptions, one may need to reset the default connection to the server timeout to an appropriate larger value.
To reassociate a security store for Oracle Entitlements Server, use the command configureSecurityStoreWas as explained in Section 10.3.4.
On IBM WebSphere, deployment is supported only in online mode; no offline deployment is supported.
On IBM WebSphere, both the JpsFilter and the JpsInterceptor must be manually configured.
For the properties supported and configuration examples, see Oracle Fusion Middleware Application Security Guide.
The system variables oracle.deployed.app.dir and oracle.deployed.app.ext can be used to specify a URL independent of the platform. For a configuration example using these variables, see Oracle Fusion Middleware Application Security Guide.
The following sample illustrates the contents of the opss-application.xml file.
<?xml version="1.0" encoding="UTF-8" standalone='yes'?>
<opss-application xmlns="http://xmlns.oracle.com/oracleas/schema/11/opss-application-11_1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/11/opss-application-11_1.xsd" schema-major-version="11" schema-minor-version="1">
<services>
<service type="POLICY_STORE">
<property name="jps.policystore.applicationid" value="stripeid" />
<property name="jps.policystore.migration" value="MERGE" />
</service>
<service type="CREDENTIAL_STORE">
<property name="jps.credstore.migration" value="MERGE" />
</service>
</services>
</opss-application>
The element <auth-method> in a web.xml file is WebLogic-specific and not supported on IBM WebSphere; if found, it must be replaced with the equivalent functionality supported for IBM WebSphere's web.xml files.
To run audit commands provided by Oracle Fusion Middleware's Common Audit Framework, you need to do the following:
Start the Oracle Fusion Middleware wsadmin command-line shell.
Prefix the audit commands with the keyword Audit. For example:
wsadmin> Audit.getAuditPolicy() wsadmin> Audit.setAuditPolicy() wsadmin> Audit.setAuditRepository (['switchToDB'],['dataSourceName'],['interval']) (see Section 9.13, "Creating a Data Source" for a related topic)
For details about the audit commands, see the Oracle Fusion Middleware Application Security Guide.
This section contains these topics:
To enable auditing of identity federation events, ensure that the filter preset is set to "High". At the default level ("Low"), federation events do not generate audit records.
When you configure the audit service to move audit records to the database, the Oracle Identity Federation busstop file at: %DOMAIN_HOME%/servers/%INSTANCE_NAME%/logs/auditlogs/OIF is updated. However these audit records are not populated in the database.
To resolve this, enter the wsadmin scripting environment and run the following command:
wsadmin>sts_commands.putStringProperty("/notifierconfig/CommonAuditListenerConfig/auditbusstop","%DOMAIN_HOME%/logs/%INSTANCE_NAME%/auditlogs")
This action should result in a "Command was successful." message.
To create a JDBC data source in a WebSphere cell, proceed as follows:
Log in to the WebSphere Console and navigate to Resources, JDBC, DataSources.
Select the appropriate Scope from the pull-down list.
Click the button New to display the Create a data source page, and go through the steps listed on the left panel.
In step 1, enter a Data Source Name and a JNDI Name; note that the Scope box is read-only and contains the scope selected earlier on. Click Next to go to the next step.
In step 2.1, set the Database Type to Oracle, Implementation Type to Connection Pool Data Source, and enter a Name for the provider. Click Next to go to the next step.
In step 2.2, ensure that the path designated by the variable ORACLE_JDBC_DRIVER_PATH is correctly set. Click Next to go to the next step.
In step 3, set JDBC URL to the appropriate value; a sample value is jdbc:oracle:thin:@xyz12345.example.com:4321:orcl. Click Next to go to the next step.
In step 4, click the link Global J2C Authentication Alias to display the page Data Sources > JAAS - J2C Authentication Data.
In that page, click New to display the New page.
In the New page, enter an Alias, and set User ID and Password to the user name and password of the data base user. Click OK to go back to the JAAS-J2C Authorization page.
In that page, if necessary, expand the Message box and click Save.
Use the Previous button on your browser to go back to the page in step 4 above. To be able to see the authentication alias you entered, refresh the page by clicking the Previous and Next buttons on your browser.
Set Component-Managed Authentication Alias and Container-Managed Authentication Alias to the authentication alias you entered (which should now show on the pull-down lists), and Mapping-Configuration Alias to DefaultPrincipalMapping. Click Next.
Click Finish and then Save, to save the specified data source.
To validate the newly created data source, navigate to the DataSource page and click Test Connection.
Note:
Some of the steps in the preceding procedure can be accomplished in pages not referenced in the procedure; examples of these pages are the Creating a JDBC Provider and Creating J2C Authentication Data pages.