Authorization and policy decisions
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.
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
When you configure policy sets to protect resources, 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 Identity Cloud. When you configure applications and their policies in Identity Cloud, you use 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 Identity Cloud, specifying the target resource(s), the policy set, and information about the subject and environment.
Identity Cloud, as the PDP, retrieves policies within the specified policy set that apply to the target resource(s).
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.
Identity Cloud only allows access if all applicable policies evaluate to a decision to allow access.
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 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. Identity Cloud sends advice, prompting the PEP to request the user to reauthenticate using a one-time password to gain authentication level 1. Now Identity Cloud grants access to the protected page.
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 Identity Cloud uses them to make a policy decision is not deterministic. However, a deny decision overrides an allow decision. By default, once Identity Cloud reaches a deny decision, it stops checking further policies.
Consider the case where 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 Identity Cloud to authenticate.
Identity Cloud serves a login page that collects the user’s email and password. Identity Cloud authenticates the user’s credentials, and creates a session for the user. Identity Cloud then redirects the user to the web agent, which gets the policy decision from Identity Cloud for the page to access, and grants access to the page.
As long as the user has a valid session with 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 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 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 Identity Cloud identifies users, so web developers can identify users by their own names when they log in. By using 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.