OAM Configuration Example Optionally, manage the provider Custom Properties using the buttons Add, Edit,

8-28 Oracle Fusion Middleware Application Security Guide 9 Managing the Policy Store 9-1 9 Managing the Policy Store The following sections explain how an administrator can manage policies using either Fusion Middleware Control, OPSS scripts, or Oracle Entitlements Server: ■ Managing the Policy Store ■ Managing Policies with Fusion Middleware Control ■ Managing Application Policies with OPSS Scripts ■ Managing Application Policies with Oracle Entitlements Server Typical operations include: ■ Changing the grants of an existing application role. ■ Revoking a permission from a principal. ■ Creating and deleting application roles. ■ Listing all application roles and members of an application role. This chapter also includes the following sections: ■ Caching and Refreshing the Cache ■ Granting Policies to Anonymous and Authenticated Roles with WLST Scripts ■ Application Stripe for Versioned Applications in WLST Scripts ■ Guidelines for Configuring the Policy Store

9.1 Managing the Policy Store

Only a user with the appropriate permissions, such as the domain administrator, can access data in the policy store. The following sections explain how an administrator can manage policies using either Fusion Middleware Control, OPSS scripts, or Oracle Entitlements Server. Typical operations include: ■ Managing Policies with Fusion Middleware Control ■ Managing Application Policies with OPSS Scripts ■ Managing Application Policies with Oracle Entitlements Server To avoid unexpected authorization failures and to manage policies effectively, note the following important points: 9-2 Oracle Fusion Middleware Application Security Guide

9.2 Managing Policies with Fusion Middleware Control

Fusion Middleware Control allows managing system and application policies in a WebLogic domain, regardless of the type of policy store provider used in the domain, as explained in the following sections: Important Point 1: Before deleting a user, revoke all permissions, application roles, and enterprise groups that have been granted to the user. If you fail to remove all security artifacts referencing a user to be deleted, they are left dangling and, potentially, be inadvertently inherited if another user with the same name or uid is created at a later time. Similar considerations apply to when a user name or uid is changed: all policies grants, permissions, groups referring to old data must be updated so that it works as expected with the changed data. See Section L.11, User Gets Unexpected Permissions. Important Point 2: Policies use case sensitivity in names when they are applied. The best way to avoid possible authorization errors due to case in user or group names is to use the spelling of those names exactly as specified in the identity store. It is therefore recommended that: ■ When provisioning a policy, the administrator spell the names of users and groups used in the policy exactly as they are in the identity repository. This guarantees that queries into the policy store involving a user or group name work as expected. ■ When entering a user name at run-time, the end-user enter a name that matches exactly the case of a name supplied in the identity repository. This guarantees that the user is authorized as expected. See Section L.4, Failure to Grant or Revoke Permissions - Case Mismatch. Important Point 3: The name of a resource type, a resource, or an entitlement can contain printable charactes only and it cannot start or end with a white space. For other considerations regarding the use of characters in policies, in particular in role names, see Section L.15, Characters in Policies. Important Point 4: Authorization failures are not visible, by default, in the console. To have authorization failures sent to the console you must set the system variable jps.auth.debug as follows: -Djps.auth.debug=true In particular, to have JpsAuth.checkPermission failures sent to the console, you must set the variable as above. Managing the Policy Store 9-3 ■ Managing Application Policies ■ Managing Application Roles ■ Managing System Policies

9.2.1 Managing Application Policies

This section explains the steps you follow to manage application policies with Fusion Middleware Control for an application deployed on Oracle WebLogic Server or on WebSphere Application Server.

1. Log in to Fusion Middleware Control and navigate to Domain Security

Application Policies if the application is deployed on Oracle WebLogic Server, or to Cell Security Application Policies if it is deployed on WebSphere Application Server, to display the Application Policies page partially illustrated in the following graphic: The area Policy Store Provider is read-only and, when expanded, displays the policy store provider currently in use in the domain or cell where the application is deployed. Note: If multiple applications are to share a permission and to prevent permission check failures, the corresponding permission class must be specified in the system class path.