Authorization and policy decisions
AM provides access management, which consists of:
-
Authentication: determining who is trying to access a resource
-
Authorization: determining whether to grant or deny access to the resource
The decision to grant access depends on a number of factors:
-
the policies governing access
-
who is trying to gain access
-
possible additional conditions, such as whether the access needs to happen over a secure channel or what time of day it is.
AM relies on policies to reach authorization decisions, such as whether to grant or deny access to a resource, or to grant or deny OAuth 2.0 scopes.
Related information: Dynamic OAuth 2.0 authorization
Protect resources
When you configure policy sets to protect resources, AM acts as the policy decision point (PDP), whereas AM web and Java agents act as policy enforcement points (PEP). In other words, an agent or other PEP takes responsibility only for enforcing a policy decision rendered by AM. When you configure applications and their policies in AM, you use AM as a policy administration point (PAP).
Authorization policies work to protect resources in the following way:
-
A PEP requests a policy decision from AM, specifying the target resource(s), the policy set, and information about the subject and environment.
-
AM, as the PDP, retrieves policies within the specified policy set that apply to the target resource(s).
-
AM evaluates the policies to make a decision based on the conditions matching those of the subject and environment.
When multiple policies apply for a particular resource, the default logic for combining decisions is that the first evaluation resulting in a decision to deny access takes precedence over all other evaluations.
AM only allows access if all applicable policies evaluate to a decision to allow access.
-
AM communicates the policy decision to the PEP. The decision, applying policy for a subject under the specified conditions, is called an entitlement.
The entitlement indicates the resource(s) it applies to, the actions permitted and denied for each resource, and, optionally, response attributes and advice.
When AM denies a request due to a failed condition, AM can send advice to the PEP, so that the PEP can take remedial action.
For example, a user wants to access a particular website. The website is protected by a policy that requires authentication level 1, but the user authenticated with an email address and password, which is configured as authentication level 0. The user cannot access the website. AM sends advice, prompting the PEP to request the user to reauthenticate using a one-time password to gain authentication level 1. Now AM grants access to the protected page.
Policy decisions
AM matches policies to resources to make policy decisions.
For a policy to match:
-
The resource must match one of the resource patterns defined in the policy.
-
The user making the request must match a subject.
-
At least one condition for each condition type must be satisfied.
When multiple policies match, the order in which AM uses them to make a policy decision is not deterministic. However, a deny decision overrides an allow decision. By default, once AM reaches a deny decision, it stops checking further policies.
Example
Consider the case where AM protects a user profile web page. An AM web agent installed in the web server intercepts client requests to enforce policy. The policy states that only authenticated users can access the page to view and to update their profile.
When a user browses to their profile page, the AM agent intercepts the request. The web agent notices the request is to access a protected resource, but that the request is from a user who has not logged in yet, and so has no authorization to visit the page. The web agent redirects the user to AM to authenticate.
AM serves a login page that collects the user’s email and password. AM authenticates the user’s credentials, and creates a session for the user. AM then redirects the user to the web agent, which gets the policy decision from AM for the page to access, and grants access to the page.
While the user has a valid session with AM, the user can browse other pages and then return to their profile page, without having to enter their email and password again.
Notice how AM and the web agent handle the access in the example. The website developer can offer a profile page, but does not have to manage login or handle who can access a page. As an AM administrator, you can change authentication and authorization independently of updates to the website. You might need to agree with website developers on how AM identifies users, so web developers can identify users by their own names when they log in. By using AM and web or Java agents for authentication and authorization, your organization no longer needs to update web applications when you want to add external access to your intranet for roaming users, open some of your sites to partners, only let managers access certain pages of your HR website, or allow users already logged in to their desktops to visit protected sites without having to type their credentials again.