Admin right's delegation use case plus processing steps...

[Frank Siebenlist <franks@mcs.anl.gov>]

This note includes a short description of a use case and the detailed processing 
of the associated access control decision request.

The model it uses, differentiates between access-policy statement and 
admin-policy statement, and the equivalent access-decision query and 
admin-decision query. It also uses distinct levels of delegation that are 
traversed until an explicit decision is determined or until no more potential 
delegation levels are left to consider. A separate email gives more detail of 
the motivation behind that choice.

It also very loosly uses an indentation scheme to depict data structures to 
avoid the use of page after page of xml... hopefully the notation won't cause 
too much confusion and won't leave too much ambiguity...(...no warm body should 
ever be exposed to xml...)

Note also that the xacml policy statements for this example have been 
simplified: no explicit PolicySet/Policy/Rule just a "policy statement", and no 
additional conditions - simple matching on the target yields Permit.

Looking forward to a white board on Monday...

Enjoy, Frank



-------------------------------------------------------------------------------


* Use case

Consider a resource "ABC" with a local PEP, local PDP and local PAP, subject to 
its company XYZ's policy.
It is configured such that it will call out for all its authorization decisions 
to another central PDP authorization service.
Some request come from foreign administrative domains, like the ACME 
corporation, and there is an agreement between XYZ and ACME, that the complete 
authorization policy to access a subset of XYZ's resources for ACME's employees 
is managed/administered by ACME's own admins.
When these ACME's employees want to access XYZ's resource, they will first go to 
ACME's own Community Authorization Service (CAS), who provides them with policy 
statements/assertions that are to be presented to XYZ's resources with the 
access request.

To make this all work, consider the following:


* XYZ's resource ABC bootstrap configuration

The resource ABC's local PAP has only one admin-policy statement:

AdminPolicyStatement Id=XYZ-Admin-PS-0
   Target
     Admins
       group==xyz-admins@xyz-attribute-authority@x509
     Subjects
       anySubject
     Resources
       anyResource
     Actions
       anyAction
   IssuingAdmin
     self

which essentially states that for any access control decision a PDP should be 
consulted with an admin identity that has an xyz-admins group membership 
asserted by xyz-attribute-authority.

Furthermore, the resource is also pre-configured with the following attribute 
assertion:

AttributeStatement Id=XYZ-AS-1
   name=pdp-admin1@x509
   group=xyz-admins
   issuer=xyz-attribute-authority@x509

Lastly, it is also preconfigured to trust x509 asserted names from some root CAs.


* XYZ's admin-policy statements concerning the ACME corporation

XYZ's centralized PDP has many access-policy statements in its PAP, but an 
arrangement has been made with the ACME corporation to outsource the access 
control policy for its employees. This is expressed in the following 
admin-policy statement:

AdminPolicyStatement Id=XYZ-Admin-PS-1
   Target
     Admins
       group==acme-admins@acme-attribute-authority@509
     Subjects
       group==acme-employees@acme-attribute-authority@509
     Resources
       Request.Resource.name==xyz:abc
     Actions
       Request.Action.name==read
   IssuingAdmin
     name=pdp-admin1@x509

which states that any ACME administrator with a valid 
acme-admins@acme-attribute-authority group membership assertion is allowed to 
administer the read access on resource abc for all ACME employees that can 
provide a acme-employees@acme-attribute-authority group membership assertion.


* ACME's CAS issued access-policy statement

The ACME admins run a Community Authorization Service (CAS), that provides their 
employees with a (temporary) access-policy assertion that should allow them 
access to read XYZ's resource xyz:abc. Such a statement for ACME's employee 
"john" looks like:

AccessPolicyStatement Id=ACME-Access-PS-1
   Target
     Subjects
       Request.Subject.name==john@x509
     Resources
       Request.Resource.name==xyz:abc
     Actions
       Request.Action.name==read
   IssuingAdmin
     name=cas-admin@x509

which states that the cas-admin allows subject john to read XYZ's resource ABC.


* ACME's attribute assertions

Furthermore, both john and the cas-admin have attribute assertions from the 
acme-attribute-authority:

AttributeStatement Id=ACME-AS-1
   name=cas-admin@x509
   group=acme-admins
   issuer=acme-attribute-authority@x509

AttributeStatement Id=ACME-AS-2
   name=john@x509
   group=acme-employees
   issuer=acme-attribute-authority@x509


* ACME's employee john's access of XYZ's resource ABC

When john requests to read XYZ's resource abc, he presents all the authorization 
and attribute assertions that he has: ACME-Access-PS-1, ACME-AS-1 and ACME-AS-2.

The resource's PEP prepares a request context with the following content:

Request
   Subject
     category=access-subject
     name=john@x509
     group=acme-employees@acme-attribute-authority
   Subject
     name=cas-admin@x509
     group=acme-admins@acme-attribute-authority
   Resource.name=abc
   Action.name=read
   AccessPolicyStatements
     ACME-Access-PS-1


* Processing and evaluation by resource's local PDP

** Preprocessing

The access-policy statement ACME-Access-PS-1 in the Request context will 
(logically) be moved to the local PAP and treated as any other policy statement. 
The processing procedure guarantees that the pushed policy statements will be 
considered at the right time.
Furthermore, all the Subject statements from the Request context will be 
logically grouped in a "possible-admin-subjects" set, with the already present 
bootstrap Subject statements. So, the possible-admin-subjects includes the 
subject info from the AttributeStatement XYZ-AS-1, ACME-AS-1, and ACME-AS-2, or 
in other words it is a list of attribute info for pdp-admin1@x509, 
cas-admin@x509 and john@x509.

** zero-level processing

At the zero'th level, there is an implicit understanding that self has empowered 
itself to administer the access rights for any target.

With the request context, the resource's PDP will evaluate a zero-level 
authorization decision by only considering the access-policy statements that 
have been issued by "self", i.e. where issuing-admin==self.
This returns an "Indeterminate" as there only is a local admin-policy statement 
XYZ-Admin-PS-0 issued by self and no access-policy statement issued by self. 
Note that the newly added ACME-Access-PS-1 has been issued by the acme-admin and 
is therefor not considered.
As the result was indeterminate, the local PDP will now look if a next level 
delegation would yield an explicit permission.

** first delegation level processing

The processing consists of two steps. First, those subjects from the 
possible-admin-subjects list are determined, that have been empowered by self to 
administer the Request context under consideration.
For each subject in the possible-admin-subjects list, a admin-authorization 
decision is evaluated from all admin-policy statement that are issued by self. 
The Request context for this evaluation is the exact same as the one under 
consideration, except that the possible-admin-subjects' subject information is 
added as the admin-subject for each authorization decision. If this decision 
yields Permit, then the possible-admin-subjects' subject is authorized by self 
to admin the rights for that particular target: a first-level delegated admin.
If the possible-admin-subjects did not include a single subject that was 
empowered as a delegated admin, then processing stops, and a result of 
"Indeterminate" will be returned to the local PEP.
So, the only admin-policy statement issued by self is XYZ-Admin-PS-0. The list 
of possible admin-subjects is pdp-admin1@x509, cas-admin@x509 and john@x509.
For each of these possible admin-subjects, their attributes are added to the 
Request context, and an authorization decision is evaluated with the 
admin-policy statement XYZ-Admin-PS-0. The only subject that yields Permit is 
pdp-admin1@509

If first-level admins were found, then the next step is for each of these 
first-level admins to evaluate the authorization decision for the access-policy 
statements issued by that particular first-level admin, and to combine those 
individual decisions.
For each first-level admin, with the Request context, only those access-policy 
statements are considered that are issued by that particular first-level admin.
So, the only "real" access-policy statements, ACME-Access-PS-1, is not issued by 
pdp-admin1@509, and should therefor not be considered.
However, the equivalent of the local evaluation of an access-policy statement 
issued by a certain subject, is the evaluation of that same authorization 
decision query by an external PDP that is identified by that same subject.
In other words, the Request context can be forwarded to XYZ's centralized PDP if 
it authenticates itself as pdp-admin1@509.
The authorization query with the forwarded Request context will result in a 
Indeterminate response, because the centralized PDP/PAP does not have any 
explicit access control policy statements concerning subjects from ACME for 
XYZ's resource ABC. It has outsourced that responsibility to ACME.
As a result, a next delegation level has to be considered.


* generic "next" level processing

Within the processing context, there is a set of subjects with attribute 
information that are collected from the Request context and from locally 
maintained subject-attribute assertions. Each of these subjects is a potential 
admin-subject.

For each delegation level, a new set of admin-subjects are found that are 
empowered by the previous level admin-subjects to administer rights for the 
target under consideration. In other words, only those admin-policy statements 
issued by the previous level admin-subjects are considered.
If none of these admin-subjects is found, "Indeterminate" will be returned to 
the PEP.

Then for each of those admin-subjects, an authorization decision is evaluated 
for that target while only considering those access-policy statements that were 
issued by that particular admin-subject.
The individual decisions are combined through a deny-overrides combinator. If 
the combined result yields an explicit decision of "Permit" or "Deny", then that 
is returned to the PEP. A combined result of Indeterminate will start processing 
of the next delegation level.

All the admin-subjects that were used for this level can be removed from the set 
of potential admin-subjects for the next levels.


* Second level processing

The previous level admin-subject was pdp-admin1@509.
For each of the remaining potential admin-subjects, cas-admin@x509 and 
john@x509, we have to look for admin-policy statements issued by the previous 
admin-subject pdp-admin1@509.
The only local admin-policy statement is issued by cas-admin@x509, and can 
therefor not be considered.
Following the analogy in the previous level, the equivalent of local evaluation 
of a admin-policy statement issued by pdp-admin1@509, is the use of a remote PDP 
that authenticates itself as pdp-admin1@509.
An admin-authorization decision query to XYZ's central PDP will yield 
Indeterminate for subject john@x509, but will yield Permit for cas-admin@x509.
Note that this "admin-authorization" query has the admin-subject added to the 
Request context.

Next is the authorization decision evaluation based on those access-policy 
statements issued by cas-admin@x509.
There is one locally available that came in with the initial request context: 
ACME-Access-PS-1.
Note that XYZ's PDP should not be considered because the associated "issuer" 
pdp-admin1@509, does not match cas-admin@x509.
Finally, an authorization decision is evaluated with the initial request context 
and with only the access-policy statement issued by CAS for john: this will 
yield Permit, and the ultimate result is returned to the resource's PEP.

QED

-- 
Frank Siebenlist               franks@mcs.anl.gov
The Globus Alliance - Argonne National Laboratory