MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Admin right's delegation use case plus processing steps...
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]