[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Extended use cases (Re: Admin right's delegation use case plus processingsteps...)
I'd like to take the use case from the previous email and discuss two possible
changes/extensions and how they could be implemented within the presented model.
The original use case reads:
---
Use case #0
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 ABC's local PDP 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.
---
* Use case #1
We could extend use case #0 with the requirement that the admins from ACME who
will administer the right for ACME's employees to access XYZ's resources should
not be allowed to give themselves those rights.
One way to implement this is through a separation of responsibility within ACME
and to split the access control policy in two parts:
XYZ could empower ACME's admins with the right to administer its resources only
for those ACME's employees that have a group membership of
"acme-vice-presidents". As long as the authorization authority that asserts the
vice-presidents group membership is different from ACME's admins, and as long as
these admins are not part of that vice-presidents group, then none of the admins
can assign itself rights to access XYZ's resources that will prove valid.
This can be implemented through a change in the matching condition of the
admin-policy statement issued by XYZ:
AdminPolicyStatement Id=XYZ-Admin-PS-1-1
Target
Admins
group==acme-admins@acme-attribute-authority@509
Subjects
group==acme-vice-presidents@acme-attribute-authority@509
Resources
Request.Resource.name==xyz:abc
Actions
Request.Action.name==read
IssuingAdmin
name=pdp-admin1@x509
---
* Use case #2
XYZ will monitor the behavior of ACME's employees as they access its resources,
and wants to have the option to maintain a blacklist to deny access to any of
ACME's users that has violated its usage agreement.
In use case #0, XYZ does not maintain any access-policy statements for ACME's
employees. As a consequence, the associated Indeterminate authorization decision
resulted in exploring the next delegation level.
If XYZ would have an access-policy statement that yields an explicit Permit or
Deny, any further delegation would not be considered.
So, by maintaining explicit access-policy statements for individual ACME users,
XYZ could effectively enforce a blacklist for ACME employees without affecting
the general outsourcing policy.
The following XYZ' s access-policy statement:
AccessPolicyStatement Id=XYZ-Access-PS-1
Target
Subjects
Request.Subject.name==acme-mary@x509
Resources
Request.Resource.name==xyz:abc
Actions
Request.Action.name==read
IssuingAdmin
name=pdp-admin1@x509
Rule.effect = Deny
would explicitly deny access to ACME's Mary, and because the matching is
targeting only this mary, it won't affect the delegated access rights for any
other ACME employee.
Note that in similar fashion, XYZ could also explicitly allow some
ACME-employees selective access, independent from what the ACME admins may have
assigned.
All this is based on the precedence rule that the explicit policy of admins
overrides those of other admins further down the delegation chain.
---
* Use case #3
The acme employees will use an additional service, like a file-transfer-service
that will require access to the XYZ-resource that this employee is allowed to
access.
In essence, this is just an addition level of delegation, where the acme
employee needs to be empowered by ACME's admin not only to access XYZ's
resource, but also to further delegate these access rights to an other subject.
AdminPolicyStatement Id=XYZ-Admin-PS-0
Target
Admins
name=john@x509
Subjects
anySubject
Resources
Request.Resource.name==xyz:abc
Actions
Request.Action.name==read
IssuingAdmin
name=cas-admin@x509
AccessPolicyStatement Id=ACME-john-Access-PS-1
Target
Subjects
Request.Subject.name==file-transfer-svc@x509
Resources
Request.Resource.name==xyz:abc
Actions
Request.Action.name==read
IssuingAdmin
name=john@x509
By keeping the target/resources, target/actions and the associated conditions
identical of the access-policy and admin-policy statements issued to john, john
will never be able to empower any other subject with more rights then it has
itself. Of course, the cas-admin could cap the delagtion of rights further by
adding restrictions to the target/subjects with associated conditions, just like
XYZ has done for the ACME admins.
---
-Frank.
Frank Siebenlist wrote:
> 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]