Introduction
This document describes the Authorization architecture (process and features) of Project OpenPTK. Authorization is used to determine if a given Request should be allowed. Before this decision can be made, the following information is needed:
| Who is making the request |
- An unknown user
- A verified user
- An administrator
|
| What needs to be done |
What is the Request's Operation
- CREATE a new entry
- READ an existing entry
- UPDATE an existing entry
- DELETE an existing entry
- SEARCH for entries
|
| Where is it being done |
Where in the RESTful uri path will the Request be applied :
- contexts
- contexts/{contextId}
- contexts/{contextId}/subjects
- contexts/{contextId}/subjects/{subjectId}
- contexts/{contextId}/subjects/{subjectId}/relationships
- clients
- clients/{clientId}
|
| When should the request / response be checked |
As a Request is processed through the OpenPTK Tiers, when should it be checked. These are called Policy Decision Points (PDP).
- When the request first "hits" the Servlet(Filter)
- When the Engine (Resource) is called
- When the Representation (Framework) is called
|
| Why is it needed (optional) |
Additional information which may be used by Request may use information beyond the required Who, What, Where, and When.
- It came from a certain host/port
- It came from an entries "parent"
- It was issued during a certain time-of-the-day
|
|
Please refer to the Design Authentication Framework document for more information on Authentication (AuthN). All references to authorization in this page are for the REST interface protection. This interface is under
/<context-root>/resources/*
All URIs under this base URI will be in scope for the authorization design.
|
Requirements
Once a user is successfully authenticated, authorization will be performed in order to prevent the user from accessing features which they are not authorized.
- The design should provide a complete internal implementation of authorization services. The basic requirements are course grained authorization for ANONYMOUS, USER and ADMINISTRATOR access. ANONYMOUS will have read only access to specific contexts The USER will be able to update their own record, the ADMIN will have full access. More information about the SESSION types is defined in Design Authentication Framework
- The configuration of authorization should be able to disable authorization if necessary
- but allow for a pluggable configuration for external integration with another authorization infrastructure (An example of this is integration with Oracle Entitlement Server).
Scope
The authorization on the server is focused on the REST resources:
- REST interface access
- REST URI's
- HTTP operations on REST URI's
Session Types
|
See the Terminology section for Session details |
The following session types are available and will be used to determine the access level of the session in order to determine what authorizations will be allowed.
| Session |
Description |
Capabilities |
| ANON |
No authentication was performed, the end-user is "unknown" by the system. This type of Session is typically enabled to allow READ-ONLY access to Targets. |
Limited READ-ONLY.
This type of Session can not perform any CREATE, UPDATE, DELETE type Operations, with the exception of registration and Forgotten Password service |
| USER |
User and/or Client credentials have been verified using the configured Authenticator (for the given Client). |
Limited READ-ONLY access.
Can UPDATE their own information. |
| SYSTEM |
An administrative account. |
Has access to all Operations on all data. |
Requests
Authorization of HTTP Requests will be performed prior to invoking the resource on the server. This includes both access to web pages as well as access to REST uri's.
Examples
- If anonymous access is allowed, and for all logged in users - access is allowed to the /user pages. The session type is enough information to determine when to allow this access. If anonymous access is not enabled, users will only get a login page on the server, nothing more.
- Only allow users with a SYSTEM session type to access the /config pages. These pages show detailed internal configuration and performance information that should not be available to anyone other that a SYSTEM user. The session type is enough information to determine when to allow this access. For information on setting up an authenticator to obtain SYSTEM access, see the authentication design.
- REST URI's and REST HTTP Operations - Examples of what is to be enforced
- Anonymous and end users (Session types: ANON and USER) will be allowed to use HTTP GET operations on all URI's under
- /resources/clients
- /resources/contexts
- Only configuration / superusers (Session type: SYSTEM) will be allowed to access (any HTTP operations) URI's under
- End users (Session type: USER) will be allowed full access to their record, (any HTTP operations) URI's under
- /resources/contexts//subjects/*userid where userid is the userid of the logged in user
- (post v2.0) /resources/contexts//subjects/*userid where userid is the in a specific allowed relationship of the logged in user: example: Managers can manage their own direct reports - /resources/contexts//subjects/*userid/relationships/authorized-relationship/* where the relationship configured for this authorization is: direct reports. NOTE: only the relationship(s) configured to be used in authorization decisions will be used.
Responses
Authorization of HTTP Responses will be performed prior to returning a response on the server. This is specific to responses from REST uri's.
Examples
- When performing forgotten password services with REST, an anonymous user can obtain the questions (step 1), answer questions (step2), and then change their password (step 3). This is the only circumstance that should allow an anonymous user to change a password and must be enforced at the business logic layer. Since caching session information is used for step 1 and 2, step 3 can only be performed after step 1 and 2 have been completed.
- (post v2.0) Anonymous user performs a search and is allowed to obtain the results of the search, only attributes which are allowed to be seen by anonymous users are displayed
- (post v2.0) End user (logged in) performs a search and is allowed to obtain the results of the search, only attributes which are allowed to be seen by anonymous users are displayed. If the user is a manager we may allow additional attributes to be displayed.
Architecture
The Authorization solution needs to address "policies" related to operations that are "requested", on a given resource, by a user/principal. Need to define the Who, What, Where, When, and Why. These are considered the inputs to any access decision which is performed.
| Who |
The "end user" that initiates a Request. The "who" is represented as a Session . A Session may be:
- A real user, represented by a Principal
- A generic anonymous user
- may be null
|
| What |
What is the Principal (who) trying to accomplish. The "what" is represented as an Operation . Operations can be:
- CREATE, add a new Target
- READ, get the details (attributes) about a single Target
- UPDATE, change one or more attributes on a single specific Target
- DELETE, remove a single specific Target
- SEARCH, get a collection of Target items
|
| Where |
The "thing" (object) that the Principal wants to effect. The "where" is represented as a Target . The Target it typically a String that "refers to" the actual target (uri, object, file, etc.). A Target can be:
|
| When |
When should the Request be "checked" to determine if it will be allowed. The "when" is represented as an Environment. In the terminology which follows, this is related to the Enforcer. The Environment indicates when the Decider (PDP) should process a set of Policies. The "when" will also indicate if it is inbound or outbound. Environments can be:
- ServletFilter
- Engine
- Representation
|
| Why |
The ability to further "constrain" the evaluation of a given Request by the Decider (PDP). A "constraint" is type of rule or logic that evaluates to a TRUE or FALSE. Type of "constraints" could be:
- Did (not) the Request come from a specific host
- Is the Request within the proper time-of-day
- Is the Session/Principal the "manager" of the Target
|
 Terminology
| OpenPTK |
Description |
XACML |
JAAS |
Enforcer
"The App" |
The "application" / "service", the Enforcer (PEP), that will create a Decider and use its check() method to determine if something should be allowed or denied |
This is the Policy Enforcement Point (PEP) |
|
| Effect |
What the Decider will return after it is request to evaluate a "request":
|
Effect. The values can be either Allow or Deny |
grant TRUE if a permission is TRUE |
| Environment |
The environment for the Policies, how/when should a Policy be applied. This is used by those Deciders (PDPs) that look for a specific Policy.
Valid environments:
- ServletFilter
- Engine
- Representation
|
Environment |
codeBase |
| Decider |
A class that is responsible for accepting inputs and applying a specific "set" of Policies based on the environment. The Decider and its associated Policies are the Authorization mechanism. Users of a Decider (and Policies) can include:
- ServletFilter
- Engine
- Representation
|
The Policy Decision Point (PDP) |
|
| Operation |
The operation that is being executed, (options):
- CREATE
- READ
- UPDATE
- DELETE
- SEARCH
- PWDCHANGE
- PWDRESET
- PWDFORGOT
|
Action |
action |
| Policy |
The logical association of something that needs to be enforced. A Policy (one or more) is used by a Decider / Policy Decision Point (PDP) to determine it should "tell" the Enforcer / Policy Enforcement Point (PEP) to "allow" or "deny" a given Request. The default "effect" of a Policy is "deny". A Policy can have a Condition which would be used by the PDP to determine if a Policy "should" evaluated. |
Request associated Subject, Target, Action, Environment |
permission: contains a perm_class_name, "target_name", "action" |
| Principal |
This is the who. The End-User that is executing an operations.
This is an "implied" (automatic) variable/object that would be available to the class that implements the PolicyIF |
Subject |
Subject
contains one or more Principal objects |
| Session |
The object that tracks a user's interaction with the Server. It may belong to an anonymous user or an authenticated users. A Session has the following structure:
- Session
- uniqueId
- type (ANON, USER, SYSTEM)
- clientId
- principal
|
|
contains one session object |
| Target |
The "item", "object" that is being protected.
This can be a "path", "pointer", "reference", "object"
In the case of a "path" or URI: * is used as a wild-card place hold, such as in a URI component.
A variable can be used, such as referencing the "end-user": {id} |
Resource |
target_name |
Enforcer a Policy Enforcement Point (PEP)
|
The "application" or "service" can be an Enforcer (a.k.a. Policy Enforcement Point) that will leverage a Decider (a.k.a. Policy Decision Point) where a Request is inbound and where a Response is outbound. The Authorization architecture provides the following configurable Enforcers:
- SERVLET
- ENGINE
- REPRESENTATION
The Enforcer can check both inbound Requests and outbound Responses
|
|
Enforcer Scenario, Servlet
The following "example" show how a SERVLET Enforcer would interact with a Decider to determine if a Request should be allowed or denied.
- A Request is submitted. It may contain the following information:
- Session/Principal, The Session is created (or evaluated) by the ServletFilter (the Enforcer). If the Session has a type of USER, it will contain information about the end-user (Principal).
- Operation, what to do: CREATE, READ, UPDATE, DELETE, etc.
- Target, where does the Request need to be applied (to the URI)
- The Enforcer (the ServletFilter) processes the Request
- Gets (or creates) a Decider instance
- Call DeciderManager.getDecider() using the enumeration Environment in the constructor to pass in the environment type.
- Gather information for the Decider:
- Session from HTTP Header/Cookie
- Operation from HTTP method or OpenPTK Operation.
- Target from the URI, and the Operation
- Environment is SERVLET. This will include inbound/outbound information.
- Execute the Decider.check() method.
- The Decider, evaluates the information. It returns true for allow and false for deny.
|
|
Enforcer Scenario, Engine
The following "example" show how a ENGINE Enforcer would interact with a Decider to determine if a Request should be allowed or denied.
- A Request is submitted. It may contain the following information:
- Session/Principal, The Session is created (or evaluated) by the ServletFilter (the Enforcer). If the Session has a type of USER, it will contain information about the end-user (Principal).
- Operation, what to do: CREATE, READ, UPDATE, DELETE, etc.
- Target, where does the Request need to be applied (to the URI)
- The Enforcer (the ServletFilter) processes the Request
- Gets (or creates) a Decider instance
- Call DeciderManager.getDecider() using the enumeration Environment in the constructor to pass in the environment type.
- Gather information for the Decider:
- Session from HTTP Header/Cookie
- Operation from HTTP method or OpenPTK Operation.
- Target from the URI, and the Operation
- Environment is ENGINE. This will include inbound/outbound information.
- Execute the Decider.check() method.
- The Decider, evaluates the information. It returns true for allow and false for deny.
|
|
BasicDecider
The BasicDecider leverages the org.openptk.authorize.policy.PolicyIF classes to determine if a Request should be allowed or denied. A "decision" is made using the following process:
- The default "decision" is deny, return false
- Select all Policies (allow and deny) in the configuration file
- Those that have the Environment set to a given value:
- SERVLET
- ENGINE
- REPRESENTATION
- Those that have the mode set to a given value:
- Process all of the "ALLOW" Policies
- Evaluate each ALLOW Policy in order.
- If an ALLOW Policy returns TRUE then all remaining ALLOW Policies are skipped.
- The "decision" is allow, return true
- If any of the ALLOW Policies returned TRUE, process all of the "DENY" Policies:
- Evaluate each of the "DENY" Policies
- If a DENY Policy returns TRUE then then all of the remaining DENY Policies are skipped.
- The "decision" is deny, return false
Configuration
The Authorization capabilities are configured by two sections, under <Security>, in the openptk.xml file:
- Enforcers
- Deciders
- Policies
<Security>
...
<Enforcers>
...
</Enforcers>
<Deciders>
...
</Deciders>
<Policies>
...
</Policies>
</Security>
Enforcers
The Enforcer maps an environment to a Decider
<Enforcers>
<Enforcer id="webfilter" environment="servlet" decider="internal" />
<Enforcer id="operation" environment="engine" decider="internal" />
<Enforcer id="outbound" environment="representation" decider="internal" />
</Enforcers>
Deciders
The authorization architecture can support various implementations of the DeciderIF interface. The default (internal) implementation is the BasicDecider.
<Deciders>
<Decider id="internal" >
<Properties>
<Property name="decider.classname" value="org.openptk.authorize.decider.BasicDecider">
</Properties>
</Decider>
<Decider id="external" >
<Properties>
<Property name="decider.classname" value="...">
</Properties>
</Decider>
</Deciders>
The BasicDecider leverages the internal Policies.
Policies
The <Policies> are used by the BasicDecider. The openptk.xml configuration file has a section for defining Policies. The <Policies> section, within the configuration file, contains one more <Policy> Elements.
The top-level <Policies> section can contain a <Properties> section which would be "inherited" by all of the <Policy> elements. This is useful for setting the classname.
<Policies>
<Properties>
<Property name="policy.classname" value="org.openptk.authorize.policy.BasicPolicy"/>
</Properties>
<Policy ....>
...
</Policy>
...
</Policies>
|
Each Policy must have the following XML Attributes:
- id
- environment
- mode
- effect
The description is optional.
The id can be any String as long as it unique to one Policy.
The environment must be one of these values (case insensitive):
- SERVLET
- ENGINE
- REPRESENTATION
The mode must be one of the these values (case insensitive):
The effect must be either of these values (case insensitive):
If a Session element (not required) is configured, then it will be used to evaluate the Policy. A Session element must have at least one Type element. The Request must contain a Session and Type that matches one of the configured Type values. If there is no match, the Policy will stop and return deny (FALSE). A Type can be one of these values (case insensitive):
The Session may have a clientId and/or a principal, these could be null.
A Targets element and at least one Target sub-element are required. Each Target must have a id and a uri attribute. The id must be a unique identifier. The uri is a valid Target path filter. The asterisks character (*) can be used within the path to indicate a "wildcard". The uri can also contain variables that refer to "run time" data. Variables need to be specified using the ${<variable>} syntax.
If an Operations element (not required) is configured, then it will be used with the Target to evaluate the Policy. An Operations element must have at least one Operation element. The Request must match one of the configured Operation elements for the Policy to return allow (TRUE).
|
| <Policies> |
| |
<Properties> |
| |
<Policy> |
| |
|
id |
| |
|
environment |
| |
|
mode |
| |
|
effect |
| |
|
<Properties> |
| |
|
<Session> |
| |
|
|
<Types> |
| |
|
|
|
<Type> |
| |
|
|
|
|
id |
| |
|
|
<Clients> |
| |
|
|
|
<Client> |
| |
|
|
|
|
id |
| |
|
|
<Principal> |
| |
|
|
|
id |
| |
|
|
|
context |
| |
|
<Targets> |
| |
|
|
<Target> |
| |
|
|
|
id |
| |
|
|
|
uri |
| |
|
|
|
<Operations> |
| |
|
|
|
|
<Operation> |
| |
|
|
|
|
|
id |
|
Samples
SERVLET Environment
This scenario describes in detail the function of the servlet filter in the acting as an Enforcer. The servlet filter will enforce all authentication requirements as described in Design Authentication Framework. This will ensure that a valid session and principal (if relevant) will be present fo all requests. The Servlet Filter's Decider will then be responsible for preventing course grained access. The primary requirement for the servlet filter is to prevent access to the sensitive configuration information for the server ( /openptk/resources/engine/ ). This URI provides access to information which should not be exposed to end users. The Decider will evaluate the policy which prevents all users except SYSTEM level sessions from accessing this URI.
 |
All the Target elements in this environment do not involve any Operation in the decision process. |
|
Not Enfored URIs
Allow all access to the Targets that support the "Forgotten Password" process. This process has three phases that must be successfully completed in this order:
- Allow the user to get their forgotten questions
- Enable the user to answer the questions
- Ensure the user can change their password
Note: The Session is not involved in the decision process.
<Policy id="NotEnforcedURIs" environment="SERVLET" mode="inbound" effect="allow">
<Properties>
<Property name="policy.description" value="Not Enforced URIs"/>
</Properties>
<Targets>
<Target id="forgotP1" uri="/resources/contexts/*/subjects/*/password/forgot/questions"/>
<Target id="forgotP2" uri="/resources/contexts/*/subjects/*/password/forgot/answers"/>
<Target id="forgotP3" uri="/resources/contexts/*/subjects/*/password/forgot/change"/>
</Targets>
</Policy>
|
|
End User URIs
Allow End-User (non-SYSTEM) access to specific sub-resources:
- Configured client capabilities
- Configured contexts
Note: The Session is not involved in the decision process.
<Policy id="NonEngineURIs" environment="SERVLET" mode="inbound" effect="allow">
<Properties>
<Property name="policy.description" value="End User URIs"/>
</Properties>
<Targets>
<Target id="clients" uri="/resources/clients/*" />
<Target id="contexts" uri="/resources/contexts/*" />
</Targets>
</Policy>
|
|
Internal SYSTEM URIs
Allow access to internal SYSTEM Targets if the Request has a Session that has a Type equal to SYSTEM.
- Internal Engine information
<Policy id="EngineURIs" environment="SERVLET" mode="inbound" effect="allow">
<Properties>
<Property name="policy.description" value="Internal SYSTEM URIs"/>
</Properties>
<Session>
<Types>
<Type id="SYSTEM"/>
</Types>
</Session>
<Targets>
<Target id="clients" uri="/resources/engine/*" />
</Targets>
</Policy>
|
ENGINE Environment
This scenario describes in detail the function of the engine in the acting as an Enforcer. The Engine is responsible for inspecting the request URI as well as the operation which is requested. It will have access to a session and principal for the request (if applicable).
|
Not Enforced Operations
Allow all access to the Targets and Operations that support the "Forgotten Password" process. This process has three phases that must be successfully completed in this order:
- READ, user can get their forgotten questions
- UPDATE, user can answer the questions
- UPDATE, user can change their password
Note: The Session is not involved in the decision process.
<Policy id="NotEnforcedOps" environment="ENGINE" mode="inbound" effect="allow">
<Properties>
<Property name="policy.description" value="Not enforced Operations"/>
</Properties>
<Targets>
<Target id="forgotP1" uri="/resources/contexts/*/subjects/*/password/forgot/questions">
<Operations>
<Operation id="read"/>
</Operations>
</Target>
<Target id="forgotP2" uri="/resources/contexts/*/subjects/*/password/forgot/answers">
<Operations>
<Operation id="update"/>
</Operations>
</Target>
<Target id="forgotP3" uri="/resources/contexts/*/subjects/*/password/forgot/change">
<Operations>
<Operation id="update"/>
</Operations>
</Target>
</Targets>
</Policy>
|
|
Anonymous Operations
Allow anonymous READ access to the following resources:
- Configured client capabilities
- Configured contexts
The Request may contain a Session that may have one of the following Type elements:
<Policy id="Anonymous" environment="ENGINE" mode="inbound" effect="allow">
<Properties>
<Property name="policy.description" value="Anonymous Operations"/>
</Properties>
<Session>
<Types>
<Type id="ANON"/>
<Type id="USER"/>
<Type id="SYSTEM"/>
</Types>
</Session>
<Targets>
<Target id="clients" uri="/resources/clients/*">
<Operations>
<Operation id="READ"/>
</Operations>
</Target>
<Target id="contexts" uri="/resources/contexts/*">
<Operations>
<Operation id="READ"/>
</Operations>
</Target>
</Targets>
</Policy>
|
|
End-User Self Service
The Request must have a Session that is of Type USER.
Allow the authenticated user to UPDATE:
- Their own information
- Change their password
The Resource must match the specific uri:
- The uri context must match the contextid in the Principal
- The uri subject must match the uniqueid in the Principal
<Policy id="User" environment="ENGINE" mode="inbound" effect="allow">
<Properties>
<Property name="policy.description" value="End-User Self Service"/>
</Properties>
<Session>
<Types>
<Type id="USER"/>
</Types>
</Session>
<Targets>
<Target id="update"
uri="/resources/contexts/${session.principal.contextid}/subjects/${session.principal.uniqueid}">
<Operations>
<Operation id="UPDATE"/>
</Operations>
</Target>
<Target id="pwdchange"
uri="/resources/contexts/${session.principal.contextid}/subjects/${session.principal.uniqueid}/password/change">
<Operations>
<Operation id="UPDATE"/>
</Operations>
</Target>
</Targets>
</Policy>
|
|
System user access
Allow the SYSTEM user to perform all Operations on:
- Client information
- Configured Contexts
- Engine information
<Policy id="System" environment="ENGINE" mode="inbound" effect="allow">
<Properties>
<Property name="policy.description" value="System user access"/>
</Properties>
<Session>
<Types>
<Type id="SYSTEM"/>
</Types>
</Session>
<Targets>
<Target id="contexts" uri="/resources/contexts/*">
<Operations>
<Operation id="CREATE"/>
<Operation id="READ"/>
<Operation id="UPDATE"/>
<Operation id="DELETE"/>
<Operation id="SEARCH"/>
</Operations>
</Target>
<Target id="engine" uri="/resources/engine/*">
<Operations>
<Operation id="READ"/>
</Operations>
</Target>
</Targets>
</Policy>
|
|
Block access
Deny all from a specific clientId:
<Policy id="denyClient" environment="ENGINE" mode="inbound" effect="deny">
<Properties>
<Property name="policy.description" value="Block all request from the client"/>
</Properties>
<Session>
<Clients>
<Client id="portlet"/>
</Clients>
</Session>
<Targets>
<Target id="all" uri="*">
<Operations>
<Operation id="CREATE"/>
<Operation id="READ"/>
<Operation id="UPDATE"/>
<Operation id="DELETE"/>
<Operation id="SEARCH"/>
</Operations>
</Target>
</Targets>
</Policy>Deny the updating / deleting of Special / System users: <Policy id="SpecialUsers" environment="ENGINE" mode="inbound" effect="deny">
<Properties>
<Property name="policy.description" value="Special Users: do not Updated or Deleted"/>
</Properties>
<Session>
<Types>
<Type id="ANON"/>
<Type id="USER"/>
<Type id="SYSTEM"/>
</Types>
</Session>
<Targets>
<Target id="superuser" type="uri" value="/resources/contexts/./subjects/suser">
<Operations>
<Operation id="UPDATE"/>
<Operation id="DELETE"/>
</Operations>
</Target>
</Targets>
</Policy>
|
Implementation
Interfaces and Classes
The org.openptk.authorize package / namespace is used for all the artifacts that support Authorization.
| Name |
Type |
Methods |
Arguments |
Return |
Description |
| org.openptk.authorize.BasicEnforcer |
class extends Enforcer |
|
|
|
Basic Enforcer class |
| org.openptk.authorize.BasicTarget |
class extends Target |
|
|
|
|
| org.openptk.authorize.EnforcerIF |
interface extends ComponentIF |
setEnvironment()
getEnvironment()
setDecider()
getDecider() |
|
|
Interface for the Enforcer. This is use internally by the configuration process when the XML file is parsing authorization elements. |
| org.openptk.authorize.Enforcer |
abstract class implements EnforcerIF |
|
|
|
Abstract base class |
| org.openptk.authorize.Environment |
enumeration |
|
|
|
Valid environments: SERVLET, ENGINE, REPRESENTATION |
| org.openptk.authorize.TargetType |
enumeration |
|
|
|
Valid types: URI, FILE |
| org.openptk.authorize.TargetIF |
interface extends ComponentIF |
|
|
|
Interface for the policy evaluation to formalize an object for the target resource being requested and the operation to perform on the resource. |
| org.openptk.authorize.Target |
abstract class |
|
|
|
|
| Policy: |
|
|
|
|
|
| org.openptk.authorize.policy.PolicyIF |
interface |
|
|
|
Defined a situation that can be evaluated to "allow" or "deny" |
| org.openptk.authorize.policy.Policy |
abstract class implements PolicyIF |
|
|
|
Initializes "based class" facilities |
| org.openptk.authorize.policy.BasicPolicy |
class extends Policy |
|
|
|
Basic Policy implementation |
| |
|
getPolicies() |
Environment |
List<PolicyIF> |
Returns an ordered list of Policies related to the Environment |
| Decider: |
|
|
|
|
|
| org.openptk.authorize.decider.DeciderIF |
interface |
check() |
Session
Target |
Component |
Evaluates the requests and determines if it should be "allowed" or "denied". The Target will optionally contain an OpCode |
| org.openptk.authorize.decider.Decider |
abstract class |
|
|
|
Initializes "based class" facilities, implements the DeciderIF |
| org.openptk.authorize.decider.BasicDecider |
class extends Decider |
|
|
new instance |
Created by the DeciderFactory
Processes and evaluates Policies associated to a given environment |
| |
|
check() |
Session
Target |
Component |
Implements the interface method |
| org.openptk.authorize.decider.DeciderManager |
class |
Constructor |
|
|
Creates a DeciderFactory objects |
| |
|
getDecider() |
Environment |
DeciderIF |
Creates / Returns an instance of DeciderIF |
Start-up process
This section outlines the logic associated with initiating the authorization mechanisms.
- For each Policy, in the Policies section,
- Create a new Policy instance
- Set the id
- Set the Environment
- Set the Mode
- Set the Effect
- If there is a Session
- For each Type, in the Types section
- Create a new SessionType instance
- Add SessionType to the Policy
- For each Client, in the Clients section
- Validate the Client
- Add ClientId to the Policy
- For each Target, in the Targets section
- Set the id
- Set the type
- Set the value
- If there are Operations ...
- For each Operation, in the Operations section
- Add Operation to the Target
- Add Target to the Policy
- Add the Policy to the Configuration's Map
- For each Decider, in the Deciders section
- Create a new Decider instance using the classname
- Set the id
- Add the Decider to the Configuration's Map
- For each Enforcer, in the Enforcers section,
- Created a new Enforcer instance
- Set the id
- Set the Environment
- Verify and then set the decider
- Add the Enforcer to the Configuration's Map
- Create DeciderManager in Configuration
Using authorization
This section covers how a class will use the authorization facilities.
- Get the DeciderManager (from the Engine/Configuration)
- Get a Decider from the DeciderManager
- Specify the Enforcer id
- Run-time
- For each request:
- Get Session
- Get Operation
- Get Target
- Execute Decider.check() method
- Post-process check()
- If "true" ... allow to continue
- Else "false" ... reject request
Authorization Logic
This section covers some design decisions of the authorization configuration and evaluation.
Configuration:
Session Types for not enforced policies
The Session Type of INTERNAL is used in a policy when a session is not required to access the target defined in the policy. This is used for not enforced URI's like forgotten password uri's, and /resources/clients, which must be accessible for use in the bootstrapping process of the client API.
Wildcard configuration in policies
| Character |
Description |
|
|
This is used as a wildcard in a policy target value to define a wildcard in a resource path. If a '*' is the last character of a target value, then the evaluation will only any additional relative levels in the request target. |
| . |
This is used as a wildcard in a policy target value to define a single instance of a wildcard in a resource path. If a '.' is the last character of a target value, then the evaluation will only allow the value as a wildcard to this level. |
|
