listEntitlements Managing Application Policies with OPSS Scripts

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. 9-32 Oracle Fusion Middleware Application Security Guide The reason for this outcome is that the policy cache has been refreshed with the change introduced in step 3 above. Scenario C 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 does not log out and remains able to access the functionality secured by the application role within 10 minutes. The reason for this outcome is that the policy cache has not yet been refreshed with the change introduced in step 3 above. Scenario D 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 does not log out, waits more than 10 minutes, and then attempts to access the functionality secured by the application role: the access is denied. The reason for this outcome is that the policy cache has been refreshed with the change introduced in step 3 above.

9.5 Granting Policies to Anonymous and Authenticated Roles with WLST Scripts

Several WLST scripts require the specification of the principal name and the principal class for a role involved in the operation. For example, the following invocation adds a principal to the role with application stripe myApp and name myAppRole: grantAppRole.py -appStripe myApp -appRoleName myAppRole -principalClass myPrincipalClass -principalName myPrincipal When in such scripts the principal refers to the authenticated role or the anonymous role, the principal names and principal classes are fixed and must be one of the following pairs: ■ Authenticated role – Name: authenticated-role – Class: oracle.security.jps.internal.core.principals.JpsAuthentica tedRoleImpl ■ Anonymous role – Name: anonymous-role – Class: oracle.security.jps.internal.core.principals.JpsAnonymousR oleImpl