Authorization Architecture OpenAM
Authorization Concepts
Policy components
Concepts to Configs — OpenAM specific
Resource Match , Condition check and Policy eval
Policy evaluation
Resource Comparator
OpenAM Authorization Architecture :
Authorization Concepts
This article discusses the authorization architecture of OpenAM. We will see how the different authZ components combine to provide authorization to users accessing a pre-configured resource.
When users try to access a resource, the access is determined by the
Authorization policy. The different components of Authorization architecture are:
Resource,
Subject,
Action,
Condition,
and Rules, Responses.
The configured policy is checked for any resource the user requests access. The simplified figure is below.
Policy components:
The examples of policy components are the Web Urls, Access to account resource, Db resource and UI components.
The actions the users are allowed to perform on a resource are — Read,Update, Delete a resource if it is a DB resource and GET, POST and DELETE for web resource.
It is better to define clearly the components of the policy. The components are divided into syntax and semantic components. Subjects and Actions are clearly defined and they fall under the syntax piece of the component. Whereas the resource urls, the URI, the query strings fall under the semantics part of the policy framework.
Authentication is closely tied with Authorization, without AuthN there is no Authorization. For an application to know which subject needs access, the subject has to verify the identity with valid credentials. Once the user is verified, the policy engine extracts the verified user information to validate against the subject’s policy component. The access manager is the policy decision evaluation piece (PDP) and the Java or Web agent which enforces resource access is the policy enforcement piece (PEP). The PEP agent evaluates the policies and makes the decision to either allow or deny access to the resource.
The PEP and the PDP makes it possible to enforce policy and resource decisions on authorization. The enforcement point checks for valid action that are allowed such as either allow or deny resources access and it also checks for the resource endpoints and if a valid cookie is set.
AM makes decisions based on those policies and sends the decision to PEP (agent) to enforce it.
Concepts to Configs — OpenAM specific
The different policy components are Rules, Conditions, Subjects and Response providers.
Two types of policies can be configured — Referral and Normal. Referral policy delegates the resources and definition. Whereas the normal policy directly defines the access and definition. The referral policy delegation can happen on the same realm scope and to the sub realm.
Access Manager stores the policy information in the AM configuration repository.
A referral policy has a unique name and consists of the following components
Referral — The referral defines the object to which the policy evaluation request is referred. The objects available for referral depend on the referral types, they are:
Peer Organizations — Peer organizations are on the same level in the directory hierarchy where delegation happens. Sub organizations allow delegation to a realm on a sub level.
Sub organizations allow delegation to a realm on a sub level.
What is a subject — A subject has unique valid credentials and is a user or object that needs access to a resource. Subjects can be users, groups or organizations. If the access is required for all users, then use the user identity config — All Authenticated Users.
If the access needs to be restricted on an organization level, then use the organization as the subject and assign rules to the organization.
In defining a group/ LDAP group, all the members for the group will have access or may not have access to a particular resource.
Identity Membership : The group which the user belongs to, which the resource has access.
Time policy definition: The policy defined (time, date, & timezone) on which the user can access the resource.
Rules — Rules define the policies or association between the subject and the resource. The definition like what kind of authentication, what kind of Authorization and which roles the resources get. Rules define resources, action and the associated response. The resource is the URL which needs protection or the user should have access to. The actions are allow or deny for web URL, if it is a DB resource, read, update or delete.
Rules can have complete resources or resources with wildcards. Ex: http://app.example.com/ — will match the exact URL or http://app.example.com/* will match all the matching URI below it.
Wild card like the * or ? can be used. Wildcards can be used in protocols, hostname and port numbers.
Conditions : Define a constraint, such as — if the request is from this IP range or if the access between particular time, don’t allow access. Users can be denied access based on the session assurance being low. The conditions can be extended to a particular resource, for a particular time and also the conditions can have geographical location and IP address as the it to restrict or allow access.
Response providers — The policy configuration for response providers will usually include the header or attribute values that needs to be sent after successful authentication/authorization. After authentication, the responses are sent to the user, through headers or a cookie. The values of the headers will be from the attribute value of the user profile or roles assigned to the user.
OpenAM provide three types of policies :
URL policy is the most commonly used. In this, the protected resource is a URL and the actions that can be performed are POST and GET . Their values are Allow or Deny.
Get Mat David’s stories in your inbox
Join Medium for free to get updates from this writer.
Discovery Service is used in federated access management, used for web service, allows read or update access — basically the actions are modify or Query for a string and the actions are allow or deny.
AM also allows custom services types, where you can define your own actions and rules load it to AM.
Policy Advice: When a user tries to access a resource, there are occasions when the conditions are not met. When faced with such scenarios, AM would deny access to the resource, but will provide some information as a piece of advice and redirect the user to a different module for example step up authentication. This is called policy advice. AuthN level advice is one such advice. Once the user fulfils the advice, the user session will be upgraded.
Session upgrade : Once a policy is evaluated and a resource/ user is provided with policy advice and redirected to a new module, and on successful user authentication, the session is upgraded. With this session upgrade, that happens transparent to the user, the user is now allowed to access resources which requires a higher level of assurance.
Resource Match , Condition check and Policy eval.
Resource evaluation happens for all policies irrespective of realms. If any of the policy fails, the access to the resource is denied.. The policies defined in any realm will get evaluated for a policy check request irrespective of the realm the policy is defined.
Policy evaluation
Different authN modules/ realms can be used to evaluate the policy — either all authenticated users, or realms like customer realm or employee realm can be used.
For AuthZ policies to take effect, agents should not be running on SSOOnly mode. AM makes a query to check for policy evaluations on non SSOOnly mode.
When a request comes for a policy evaluation, the following entities are involved — The subject , the resource, SSOtoken (action), and condition.
- AM retrieves the subject from the SSOToken and inserts into the policy resource decision. It also has the condition sent with the request. That condition is evaluated by AM and a response is sent back to the agent to allow or deny the resource.
- The Request ID (for tracking request in logs), the application token, user SSO token, the resource and the env parameters like the IP address are all part of the request.
- It is normal for all the policies to be evaluated for a resource request. The policies defined in the realms are not the only one evaluated. So if a resource is evaluated to allow, but a different resource evaluated is deny, then the decision is a deny.
- An entitlement component called, — Resource comparator — evaluates the resources. To evaluate custom policies that are not resource, a custom resource comparator should be developed.
- The conditions such as IP address range or time range are also evaluated. The combination of AND or OR conditions are evaluated. In an AND , both the conditions should match. In an OR scenario, only one of the conditions need to match for the rule to pass.
- The resource and subject are primary for a policy to pass. If the resource or resource is not present, then the policy becomes irrelevant. If a resource and subject match and the condition are within the acceptable scope, then resource eval will be “Allow” response. If one of the conditions doesn’t match, then it will be responded with Advice. A response is a corrective action.
- Policy conditions play a pivotal role in defining the rules, the different policy conditions can be IP address/DNS that lets you configure a specific IP range and traffic coming from a DNS alias.
- Session Time : How long the session needs to be active.
- Authentication Level : The minimum acceptable authN level the session needs to be set before the user can have access to the resource.
- AuthN Realm : The realm to which the user needs to authN before the user can get access to the resource.
- All the policies are evaluated irrespective of the realm. Policy evaluation starts at the top realm, and is evaluated until a match is reached. The policy evaluation has different components that do that job, one is the resource comparator.
Resource Comparator
The resource comparator does the following :
- Condition check.
- Check if Advice Exist.
- Result — Allow or Deny with Advice.
- Different types of advice exist.
REST interface protection is configured in AM through authentication filter and authZ filter rather than policy agents to protect the endpoints.
The AuthN filter checks if the user has the valid SSOtoken and the Authz filter checks if the user with valid SSOToken has the permission to access the resources.
The ssoadm command can be used to create-policy, list, delete and update. The REST API to check the authz is below:
http://hostname/am/identity/authorize? uri=<>subjectid=<SSOToken>
How all the components fit in to evaluate the policy after the user is authenticated is shown in the figure below. A successfully authenticated subject (user in the repository) is able to access a resource and execute an action like search, or update resources. Access is granted only if the policy conditions are met, like if the request is from a specific IP or within a time range.
Resource : https://<hostname>:443/abc/logon.jsp or https://<hostname>:443/abc/userprofile.jsp
Configured Res patterns URI: /abc/* ; /…/*
This article covered the authorization architecture and components of OpenAM. It covered how the Subjects, Rules, policies and conditions can be combined to configure a web URL protection. How the subjects can be grouped into all authenticated users, or groups was covered.
Conditions, like the IP range or time of resource access, plays a role in providing advanced authentication. The role of policy enforcement points vs policy decision point was touched upon.
We wrapped up discussing the role of resource comparator and saw some examples of web resources.
