[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 email@example.com The Globus Alliance - Argonne National Laboratory
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]