addResourceToEntitlement Managing Application Policies with OPSS Scripts

9-30 Oracle Fusion Middleware Application Security Guide ■ domain: on WebLogic, specifies the domain name where the reassociating takes place; on WebSphere, specifies the WebSphere cell name. ■ admin specifies, in case of an LDAP target, the administrator’s user name on the target server, and the format is cn=usrName. In case of a DB target, it is required only when the DB has a protected data source protected with userpassword; in this case, it specifies the user name set to protect the data source when the data source was created; that user and password must be present in the bootstrap credential store. ■ password specifies the password associated with the user specified for the argument admin. It is required in case of an LDAP target. In case of a DB target, it is required only when the DB has a protected data source; in this case, it specifies the password associated with the user specified for the argument admin. ■ ldapurl specifies the URI of the LDAP server. The format is ldap:host:port, if you are using the default port, or ldaps:host:port, if you are using an anonymous SSL or one-way SSL transmission. The secure port must be configured to handle the desired SSL connection mode, and must be distinct from the default non-secure port. ■ servertype specifies the kind of the target LDAP server or DB server. The only valid types are OID and DB_ORACLE. ■ jpsroot specifies the root node in the target LDAP repository under which all data is migrated. The format is cn=nodeName. ■ join specifies whether the domain is to share an OPSS security store in another domain. Optional. Set to true to share an existing store in another domain; set to false otherwise. The use of this argument allows multiple WebLogic domains to point to the same logical OPSS security store. ■ datasourcename specifies the JNDI name of the JDBC data source; this should be identical to the value of the JNDI name data source entered when the data source was created; see Section 8.3.1.3, Creating a Data Source Instance. Examples of Use reassociateSecurityStoredomain=myDomain, admin=cn=adminName, password=myPass, ldapurl=ldaps:myhost.example.com:3060, servertype=OID, jpsroot=cn=testNode Suppose that you want some other domain distinct from myDomain, say otherDomain to share the policy store in myDomain. Then you would invoke the script as follows: reassociateSecurityStoredomain=otherDomain, admin=cn=adminName, password=myPass, ldapurl=ldaps:myhost.example.com:3060, servertype=OID, jpsroot=cn=testNode, join=true Important: When an OPSS security store is reassociated with join=true, the bootstrap wallet from the first domain must be manually copied to the second domain. The reason for this requirement is that the first domain generates a local key that is used to encrypt the keystore data and the second domain needs to have the same key in its bootstrap wallet in order to decrypt that data. Managing the Policy Store 9-31

9.4 Caching and Refreshing the Cache

OPSS optimizes the authorization process by caching security artifacts. When an application policy or some other security artifact is modified, the change becomes effective depending on where the application and the tool used to modified the artifact are running: ■ If both the application and the tool are running on the same host and in the same domain, the change becomes effective immediately. ■ Otherwise, if the application and the tool are running on different hosts or in different domains, the change becomes effective after the policy store cache is refreshed. The frequency of the cache refresh is determined by the value of the property oracle.security.jps.ldap.policystore.refresh.interval. The default value is 10 minutes.

9.4.1 An Example

The following use case illustrates the authorization behavior in four scenarios when from a different domain or host Oracle Entitlements Server is used to modify security artifacts, and the property oracle.security.jps.policystore.refresh.interval is set to 10 minutes. The use case assumes that: ■ A user is member of an enterprise role. ■ That enterprise role is included as a member of an application role. ■ The application role is granted a permission that governs some application functionality. Under the above assumptions, we now examine the authorization result in the following four scenarios. Scenario A 1. The user logs in to the application.

2. The user accesses the functionality secured by the application role.

3. From another host or domain, Oracle Entitlements Server is used to remove the enterprise role from the application role. 4. The user logs out from the application, and immediately logs back in. 5. The user is still able to access the functionality secured by the application role. The reason for this outcome is that the policy cache has not yet been refreshed with the change introduced in step 3 above. Scenario B 1. The user logs in to the application. 2. The user accesses the functionality secured by the application role. 3. From another host or domain, Oracle Entitlements Server is used to remove the enterprise role from the application role. 4. The user logs out from the application, and logs back in after 10 minutes. 5. The user is not able to access the functionality secured by the application role.