Managing Access Policies Oracle Fusion Middleware Online Documentation Library

Managing Access Policies 16-13 resource. You must create the same number of access policies as that of instances of same resource that is to be provisioned. ■ If a resource object has a process form that has fields marked as account discriminator fields, then the value of these fields must be specified in any access policy that provisions that resource. Not doing this can result in behavior that cannot be determined, for example, provisioning of multiple accounts the next time policies are evaluated. ■ If a resource object has a process form that has fields marked as account discriminator fields and if you use the access policy engine to provision this resource to one or more users, then the values of the account discriminator fields must remain constant throughout the lifecycle of the account. In other words, the values of the account discriminator fields must not be changed. This is because the access policy engine uses the resource object key and the account discriminator values to decide whether or not to provision a new account to the user. By modifying account discriminator values, you modify the basis on which the provisioning decision had been taken. and the behavior of the access policy engine cannot be determined. Therefore, it is recommended that you do not modify account discriminator values. And the process form values of the account discriminator fields must not be changed. ■ If access policies are configured with different account discriminator values, they provision different accounts to the user. A resource object of this type must have the Allow Multiple flag set. Otherwise, provisioning fails. Note: Account discriminator values that are different only in casing for example, abc and aBc are also treated as different values. With this data, two accounts are provisioned to the end user. Consider the following scenario: Two access policies are provisioning the same resource with the same account discriminator data. The policies are applied through a request. These two policies apply to a user, and policies are re-evaluated for the user. Here, only one resource is provisioned to the user through a request. Now, suppose request approval is in progress. In the meantime, the priorities of these two policies are swapped, which means that the higher priority policy becomes the lower one and the other becomes the higher priority policy. While the request is in progress, if policies are re-evaluated for the user, a second request is created to provision the same resource but through the current higher priority policy. This issue is not currently handled by the policy engine. To avoid this issue, you must ensure that all pending requests for a specific resource are either approved or rejected before modifying the properties of the access policy that provision the resource, especially through a request.