| Oracle® Fusion Middleware Third-Party Application Server Guide 11g Release 1 (11.1.1.7) Part Number E17852-03 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware Third-Party Application Server Guide 11g Release 1 (11.1.1.7) Part Number E17852-03 |
|
|
PDF · Mobi · ePub |
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.
In regards to OPSS scripts:
On IBM WebSphere, OPSS scripts have a slightly different syntax (than that used on the WebLogic platform): script names are prefixed with the string "Opss." Unless explicitly stated, arguments remain identical to the WebLogic case.
This chapter contains the following sections:
Section 9.2, "Recommendation for Multiple-Node Environments"
Section 9.3, "Configuring the Trust Association Interceptor"
Section 9.6, "Reassociating Policies with reassociateSecurityStore"
Section 9.8, "Configuring the JpsFilter and the JpsInterceptor"
Section 9.12, "Executing Common Audit Framework wsadmin Commands"
Section 9.16, "Setting Parameters for Custom Audit Service Registration"
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 user.selected.create.base=cn=Users,dc=us,dc=oracle,dc=com group.selected.create.base=cn=Users,dc=us,dc=oracle,dc=com ldap.host=myhost.example.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 # In case of type=ACTIVE_DIRECTORY, the primary.admin.id indicates a user # who has admin permissions in the LDAP,and it must be the name of the user # for example, for user "cn=tom", the primary.admin.id is "tom" # for any other type, the primary.admin.id is wasadmin or orcladmin 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 # if ssl is set to true, SSL has to be set as explained in the procedure below # before executing the command ssl=false
The list of valid identity store types is the following:
OID
IPLANET
OVD
ACTIVE_DIRECTORY
OPEN_LDAP
If ssl was set to true, before invoking the command, proceed as follows:
In the WAS console, navigate to Security > Global security.
In User account repository, select Available realm definitions, and then Standalone LDAP registry; then click Configure.
In SSL setting, click SSL configurations, select CellDefaultSSLSettings > Key stores and certificates > CellDefaultTrustStore.
Set Path: ${CONFIG_ROOT}/cells/dmgrCell/DummyClientTrustFile.jkd
Set Password: myWebAS
Set Type: JKS
Click OK then Save.
Import the Client_keystore.jks to DummyClientTrustFile.jks by invoking a command like the following:
$keytool -importkeystore -srckeystore client_keystore.jks -destkeystore <WAS_Profile>/dmgr/etc/DummyClientTrustFile.jks -srcstoretype JKS -deststoretype JKS -srcstorepass welcome1 -deststorepass myWebAS
Copy the file DummyClientTrustFile.jks to path specified in step 4 above:
cp <WAS_Profile>/dmgr/etc/DummyClientTrustFile.jks <WAS_Profile>/dmgr/config/cells/dmgrCell/
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
In environments where several server instances are distributed across multiple machines, it is highly recommended that the OPSS security store be LDAP- or DB-based configured in the dmgr server.
If, however, a file- based store is used in a multiple-node environment (not recommended), any changes to the store should be performed in the dmgr server so that those changes can be propagated to all other servers in the environment. The data on servers other than dmgr is refreshed based on caching configuration.
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 reset the default connection timeout, proceed as follows:
Open the file soap.client.props, located in the properties subdirectory of the profile_root directory, for edit.
In that file, modify the value of the property com.ibm.SOAP.requestTimeout to a desire value, such as 1200 (seconds).
Save and close the file.
The following is a sample run of this scrip:
wsadmin> Opss.reassociateSecurityStore(domain="farm", servertype="DB_ORACLE", jpsroot="cn=jpsroot", datasourcename="opss_ds")
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.
This section describes the settings required for TAI to work with the OPSS keystore on the WebSphere platform, in the following sections:
To set the Trust Association Interceptor, proceed as follows:
Login to WebSphere administrative console.
Click Security > Global Security.
In the Authentication section, expand Web and SIP security.
Click Trust Association, select the check box Enable trust association, and save the settings.
Back in the Global Security page, in the Additional Properties section click Interceptors.
Click New and enter the following fully-qualified name as the interceptor class name:
oracle.security.jps.was.providers.trust.TrustServiceAsserterTAI
Save your changes.
To configure the OPSS Keystore Service on WebSphere, run the following script with the appropriate values:
# Update following values with correct value user = "wasadmin" password = "<password>" wlsurl = "http(s)://<host>:<port>" wlsServerName = "AdminServer1" stripeName = "opss" #----------------------------------------------- ksName = "trustservice_ks" + "_" + wlsServerName tsName = "trustservice_ts" aliasName = wlsServerName print "Importing certificate for : " + wlsServerName print "Stripe Name: " + stripeName print "TrustStore Name: " + tsName print "Alias Name: " + aliasName #----------------------------------------------- connect(user, password, wlsurl) svc = getOpssService(name='KeyStoreService') svc.listKeyStores(appStripe=stripeName) # Need it to switch Trust service to using FKS svc.createKeyStore(appStripe=stripeName, name=ksName, password="", permission=true) svc.createKeyStore(appStripe=stripeName, name=tsName, password="", permission=true) svc.importKeyStoreCertificate(appStripe=stripeName, name=tsName, password="", alias=aliasName, keypassword="", type="TrustedCertificate", filepath="AdminServer1client.cer") svc.listKeyStoreAliases(appStripe=stripeName, name=tsName, password="", type="TrustedCertificate") exit()
To create a JDBC data source in a WebSphere cell, proceed as follows:
Login 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 Authenticaion 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.
This section provides information about running Keystore Service commands that is specific to IBM WebSphere.
permission Option Requires Quotes
Certain Keystore Service commands include the permission option. When running commands containing this option on IBM WebSphere, enclose the permission option's value in single quotes (''). For example:
wsadmin>Opss.createKeyStore(appStripe='owsm', name='keystore1', password='password',permission='true')
You can perform custom registration of your application to the audit service by configuring OPSS deployment descriptors, as explained in Register Application with the Registration Service in the Oracle Fusion Middleware Application Security Guide. On IBM WebSphere you set these registration parameters in the opss-application.xml file.
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|