Authorization and policy decisions
Advanced Identity Cloud 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.
Advanced Identity Cloud 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, Advanced Identity Cloud acts as the policy decision point (PDP), whereas the web and Java policy agents act as policy enforcement points (PEP). In other words, an agent or other PEP takes responsibility only for enforcing a policy decision made by Advanced Identity Cloud. When you configure applications and their policies in Advanced Identity Cloud, you use Advanced Identity Cloud as a policy administration point (PAP).
Authorization policies work to protect resources in the following way:
-
A PEP requests a policy decision from Advanced Identity Cloud, specifying the target resource(s), the policy set, and information about the subject and environment.
-
Advanced Identity Cloud, as the PDP, retrieves policies within the specified policy set that apply to the target resource(s).
-
Advanced Identity Cloud 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.
Advanced Identity Cloud only allows access if all applicable policies evaluate to a decision to allow access.
-
Advanced Identity Cloud 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 Advanced Identity Cloud denies a request due to a failed condition, it 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. Advanced Identity Cloud sends advice, prompting the PEP to request the user to reauthenticate using a one-time password to gain authentication level 1. Now Advanced Identity Cloud grants access to the protected page.
Policy decisions
Advanced Identity Cloud 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 Advanced Identity Cloud uses them to make a policy decision is not deterministic. However, a deny decision overrides an allow decision. By default, once Advanced Identity Cloud reaches a deny decision, it stops checking further policies.
Example
Consider the case where Advanced Identity Cloud protects a user profile web page. A 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 web agent intercepts the request. The web agent assesses that the request is to access a protected resource, but comes from a user who has not yet logged in and so has no authorization to visit the page. The web agent redirects the user to Advanced Identity Cloud to authenticate.
Advanced Identity Cloud serves a login page that collects the user’s email and password, authenticates the user’s credentials, and creates a session for the user. It then redirects the user to the web agent. The web agent gets a policy decision from Advanced Identity Cloud for that specific page and grants access to the page. As long as the user has a valid session with Advanced Identity Cloud, they can browse other pages and then return to their profile page, without having to enter their email and password again.
Notice how Advanced Identity Cloud 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 Advanced Identity Cloud administrator, you can change authentication and authorization independently of updates to the website. You might need to agree with website developers on how Advanced Identity Cloud identifies users, so web developers can identify users by their own names when they log in. By using Advanced Identity Cloud 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.