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:
Section 8.2, "Configuring the Trust Association Interceptor"
Section 8.5, "Reassociating Policies with reassociateSecurityStore"
Section 8.7, "Configuring the JpsFilter and the JpsInterceptor"
Section 8.11, "Executing Common Audit Framework wsadmin Commands"
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 file that contains the property settings for the identity LDAP identity store. This command modifies the configuration file jps-config.xml to include the specifications in the property file.
After running Opss.configurIdentityStore, the server must be restarted.
The following properties are required and must be specified in property settings 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 a 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.us.oracle.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
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.
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()
For details about the audit commands, see the Oracle Fusion Middleware Application Security Guide.