You can set up some conditions to compare the values in the request against static values (A to B). Alternatively, you can compare static values to current values in the request (B to A). Within one policy, you must decide which direction to set up the comparisons and remain consistent unless there is a compelling reason to switch the direction for a particular condition.
For example, suppose you set up a rule to allow access to a resource only during the weekdays (Monday to Friday). You set up four of these conditions to compare if the date when the request is made matches with Monday, Tuesday, Wednesday, or Thursday. You set up the fifth condition to compare whether Friday matches the date when the request is made. This works, but maintaining this policy is difficult because each new policy manager will look at the Friday condition and wonder why it is configured differently.
Many conditions, when used as the sole condition of a rule, do not make useful rules. For example, you can create a rule that grants access if a user specifies a specific URL in the request. Such a rule has limited application. A rule that requires that the request contain a specific URL and that the user have a specific role is more useful because it can be used to limit access to the URL based on the user’s role. For information about how conditions can be ANDed or ORed together or placed in different condition groups, see Using the URL of the Protected Resource.
Authorization policies use the following conditions:
For the specific policies they can be used in Creating Access Gateway Authorization Policies.