OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

(old) XACML questions and feature requests

  • 1.  (old) XACML questions and feature requests

    Posted 08-07-2003 18:25
    During the conference call this morning, I alluded to some emails that I sent to 
    a subset of the xacml tc in April - Please find those attached.
    
    This was right after our group took a close look at xacml for potential future 
    inclusion in our globus toolkit, and before deciding to take a more active role 
    to ensure that our requirements would be addressed in the next incarnations of 
    xacml. In retrospect, these emails should probably have been sent to the 
    tc-mailing list...
    
    Some of the questions/requirements are based on misunderstandings, some are 
    already addressed in Anne's xacml 2.0 work item list, and some are not. I'll 
    take an other look.
    
    Enjoy, Frank.
    
    -- 
    Frank Siebenlist              franks@mcs.anl.gov
    The Globus Project - Argonne National Laboratory
    
    


    Hi XACML experts,
    
    We're trying to render some of our use cases on top of xacml, and I'm running into some problems of howto.
    
    I wasn't sure if the xacml mailing list is appropriate for these novice questions, so I'm bothering you directly. Hope you don't 
    mind, and maybe we should take it to a mailing list if appropriate.
    
    Our application is the following:
    
    We have an experimental implementation of the Community Authorization Service (CAS), which addresses some of the issues we see in 
    distributed environments where the resource owners do not have (and do not want) access control policy for the individual requesters 
    coming from a foreign domain.
    The idea is that these requesters will have a CAS in their domain "A", which they can ask for authorization assertions that can be 
    used on resources of domain "B". The access rights issued by that CAS should be a subset of the access rights that the CAS-identity 
    itself has on the resource in domain "B".
    
    The access control policy in domain B will know only the CAS-identity of domain A, give it access right to some of its resources, 
    and allow if to delegate its rights to other identities.
    CAS will manage the access control policy applicable to the resources in domain B for the identities in domain A.
    
    Our current CAS issues rights to requesters in the form of rules, e.g. "Frank has the right to read any file from directory 
    acme.com/docs/".
    
    If the requester from A presents a request to the resource in domain B to read file acme.com/doc/abc.txt together with the 
    CAS-issued assertion, the resource will validate the identities of both requester throught the message and CAS through the signed 
    assertion. It will then check whether the CAS identity is allowed to perform the requested action according to its own policy, and 
    if so, it will evaluate the rule in the assertion as it applies to the request. If the latter also yield a positive permission, the 
    request will be honored.
    
    Currently we use our own language to express these assertions, and we have our own evaluators on the resource. We would like to see 
    how we could implement this in a xacml-ruled world.
    
    My first idea was to have CAS issue the collection of xacml-policy-sets/policies/rules as a signed authorization assertion, which 
    would apply to the target, i.e. the requester's subject, with the resource and action requested.
    
    At the resource's PEP, the first <request> to the context handler should include the CAS's subject with the detailed 
    resource/action, which gets evaluated by the PDP according to the locally administered policy.
    
    The second <request> is more complicated, because now I have these CAS-policy/rules, that I would like to have evaluated by the 
    resource's PDP. It almost feels like I should be able to present these rules as an subject attribute value, and that I need some 
    "eval" function that makes the PDP evaluate the presented policy/rules instead of its own local ones.
    
    As a possible alternative, we could have the CAS issue the <result> as it is evaluated by its own pdp. This could also be seen as an 
    authorization assertion. However, this would probably only work if there is an absolute match of the target in this assertion and 
    the target as it is requested on the resource. It may not work if you ask the CAS to read permission in a directory, and then ask 
    the resource to read a file in that directory - this requires an additional matching of resource details. It also wouldn't work if 
    the CAS policy allows you read access only from 9am-5pm, as that rule has to be evaluated at the resource.
    
    An other option would be to feed the CAS-policies in through the administrative channel, i.e. the resource's PAP, but that doesn't 
    sound very "portable" and feels somewhat of a kludge.
    
    Anyway, I'm confident that you could direct us to the proper solution ... Please...
    
    Thanks for your help.
    Regards, Frank.
    
    -- 
    Frank Siebenlist              franks@mcs.anl.gov
    The Globus Project - Argonne National Laboratory
    
    




    Some more beginner's questions:
    
    1) How to specify policy rules for the requestor's authorization policy?
    The spec seems to be somewhat silent on the requestor's side authorization decision to see whether the requestor's policy allows the 
    service provider to service the request.
    There are subject categories defined for access-subject, recipient-subject, and intermediary-subject. I guess we could use the 
    recipient-subject for the service provider's subject, although I have the feeling that that was not its intension.
    Should we maybe define a "provider-subject" to more clearly distinguish the context where the access control decision is made?
    
    2) How to use xacml policy to bootstrap the trust?
    In a xacml-ruled world, all policy should be defined in policy-sets/policies/rules, and PDPs should be used everywhere for all 
    authorization decisions...
    If a resource's PEP uses an external access control decision service for its PDP, then we need to bootstrap that trust. The PEP must 
    have a locallly stored policy with a local PDP that is able to evaluate whether the subject associated with the PDP service is 
    allowed to decide on all relevant policy decisions for that PEP.
    It's not clear how you specify that rule. How do you express a rule that a subject is allowed to serve as a PDP for a certain set of 
    resources and actions? It seems to be implicit in a policy/rule, but I do not see how I can associate the policy authority's subject 
    with it...
    
    3) How to use xacml to delegate trust?
    This is very much related and maybe identical to 2), but the use case is different.
    In our Grid environment, we have resources with associated identities that are created on the fly. There is therefor no existing, 
    explicit policy for those entities.
    The way we deal with it is that there is one identity that is kind of the trust anchor for these newly created beings. This 
    so-called Grid Resource Identity Manager (GRIM) issues dynamically identity and authorization assertions that are used both by the 
    newly created services as well as the requestors to decide whether they are allowed to talk to each other.
    We therefor need to define a policy for the requestor that will "trust" this GRIM identity to function as a PDP for all the 
    authorization decisions related to access to the GRIM managed resources.
    
    Or as an alternative, the GRIM could send the relevant policies/rules to the requestor such that the requestor's PDP itself can 
    evaluate the rules. This is very much like the use case in my previous email, and that's actually how we have implemented it now.
    
    ---
    
    I hope my questions relate the fact that we are very seriously looking at XACML, and would love to see how we can deploy it in our 
    current applications.
    
    Regards, Frank.
    
    -- 
    Frank Siebenlist              franks@mcs.anl.gov
    The Globus Project - Argonne National Laboratory
    
    




    Hi Anne,
    
    Anne Anderson - Sun Microsystems wrote:
    > ...
    > I sent Tim Moses an example of a client policy and a server policy yesterday.
    > I need him to check them over, but I think once we get the example worked
    > out, it will help answer your first question.  Tim said he would probably 
    > be able to look at it at the end of this week.
    
    Good to hear that you're addressing one piece of the puzzle already
    (and that you're keeping Tim busy ;-)
    
    If you want we could give you a detailed example from our world, and try to figure out together what attributes, rules and condition 
    we need defined. I've come to the conclusion that we need such a worked out detailed example to see how far we get with xacml, where 
    the possible gaps are, and the possible solutions. We're willing to put time such an effort.
    
    
    Regards, Frank.
    
    
    > "Frank Siebenlist" <franks@mcs.anl.gov> wrote:
    > 
    >>Date: Wed, 23 Apr 2003 14:58:18 -0700
    >>Some more beginner's questions:
    >>
    >>1) How to specify policy rules for the requestor's authorization policy?
    >>The spec seems to be somewhat silent on the requestor's side authorization
    >>decision to see whether the requestor's policy allows the 
    >>service provider to service the request.
    >>There are subject categories defined for access-subject, recipient-subject, and
    >>intermediary-subject. I guess we could use the 
    >>recipient-subject for the service provider's subject, although I have the
    >>feeling that that was not its intension.
    >>Should we maybe define a "provider-subject" to more clearly distinguish the
    >>context where the access control decision is made?
    >>
    >>2) How to use xacml policy to bootstrap the trust?
    >>In a xacml-ruled world, all policy should be defined in
    >>policy-sets/policies/rules, and PDPs should be used everywhere for all 
    >>authorization decisions...
    >>If a resource's PEP uses an external access control decision service for its
    >>PDP, then we need to bootstrap that trust. The PEP must 
    >>have a locallly stored policy with a local PDP that is able to evaluate whether
    >>the subject associated with the PDP service is 
    >>allowed to decide on all relevant policy decisions for that PEP.
    >>It's not clear how you specify that rule. How do you express a rule that a
    >>subject is allowed to serve as a PDP for a certain set of 
    >>resources and actions? It seems to be implicit in a policy/rule, but I do not
    >>see how I can associate the policy authority's subject 
    >>with it...
    >>
    >>3) How to use xacml to delegate trust?
    >>This is very much related and maybe identical to 2), but the use case is
    >>different.
    >>In our Grid environment, we have resources with associated identities that are
    >>created on the fly. There is therefor no existing, 
    >>explicit policy for those entities.
    >>The way we deal with it is that there is one identity that is kind of the trust
    >>anchor for these newly created beings. This 
    >>so-called Grid Resource Identity Manager (GRIM) issues dynamically identity and
    >>authorization assertions that are used both by the 
    >>newly created services as well as the requestors to decide whether they are
    >>allowed to talk to each other.
    >>We therefor need to define a policy for the requestor that will "trust" this
    >>GRIM identity to function as a PDP for all the 
    >>authorization decisions related to access to the GRIM managed resources.
    >>
    >>Or as an alternative, the GRIM could send the relevant policies/rules to the
    >>requestor such that the requestor's PDP itself can 
    >>evaluate the rules. This is very much like the use case in my previous email,
    >>and that's actually how we have implemented it now.
    >>
    >>---
    >>
    >>I hope my questions relate the fact that we are very seriously looking at XACML,
    >>and would love to see how we can deploy it in our 
    >>current applications.
    >>
    >>Regards, Frank.
    >>
    >>-- 
    >>Frank Siebenlist              franks@mcs.anl.gov
    >>The Globus Project - Argonne National Laboratory
    >>
    > 
    > 
    > Anne
    > ------
    > Anne Anderson          Anne.Anderson@Sun.COM
    > Sun Microsystems Laboratories
    > Burlington, MA         781-442-0928
    > 
    
    -- 
    Frank Siebenlist              franks@mcs.anl.gov
    The Globus Project - Argonne National Laboratory
    
    




    A few more puzzle pieces that I can't find. They might be missing or I haven't 
    looked well enough:
    
    4) XACML wsdl/porttype definition for <Request>/<Response> exchange
    If we would use a centralized "authorization" service, it seems most natural to 
    abstract the decision request and response messages between the context handler 
    and the PDP into a wsdl/porttype definition.
    
    This context handler seems to be doing a lot of work to get all the required 
    info from the native formats into this canonicalized representation.
    I guess that the PIP could be an XKMS service?
    
    5) Need new SAML profile for XACML attribute assertions
    If application still have a choice, then it may make sense to make the 
    conversion to the xacml representation of attributes at soon as possible, and 
    they may even start out with that.
     From an application point of view it makes sense to translate all the receieved 
    assertions in a standard canonical representation, even outside of XACML, such 
    that it becomes easier to reason about them.
    There seems to be a mismatch betweeen the current SAML assertions and the XACML 
    attributes. It would be best to define a new SAML profile such that attribute 
    assertions can use the xacml representation.
    
    6) Need SAML profile for authorization/policy assertions
    As I mentioned in my first email, case "0)", we have a need to communicate 
    authorization assertions, and it may make sense to use the xacml 
    policy-set/policy/rule elements as the format. We still need to wrap them up in 
    some signed envelope in a standardized manner, and it could make sense to define 
    another SAML profile for that as it doesn't seem to fit well within the current 
    SAML authorization assertion.
    
    7) Primitive to express policy to reveal missing attributes?
    Quoting from the spec:
    <quote>
    "urn:oasis:names:tc:xacml:1.0:status:missing-attribute 2805
    A PDP MAY choose not to return any <StatusDetail> information or MAY choose to 
    return a 2806 <StatusDetail> element containing one or more 
    xacml-context:Attribute> elements. If 2807 the PDP includes <AttributeValue> 
    elements in the <Attribute> element, then this indicates 2808
    the acceptable values for that attribute. If no <AttributeValue> elements are 
    included, then 2809 this indicates the names of attributes that the PDP failed 
    to resolve during its evaluation. The list 2810 of attributes may be partial or 
    complete. There is no guarantee by the PDP that supplying the 2811
    missing values or attributes will be sufficient to satisfy the policy.
    </quote>
    I find the returning of missing attributes very intriguiging. It still is 
    unclear to me how we're going to find out what attributes we need from what 
    authority such that we may be able to satisfy the the policy that allows access. 
    If we could get that information by trying, or querying the policy service, that 
    could be a working solution.
    As mentioned, the returning of the missing attribute info is sensitive 
    information and should itself be subject to policy. What I can't figure out, 
    however, is what rule primitives I could use to express that policy...
    
    ---
    
    Enough for now...
    Regards, Frank.
    
    -- 
    Frank Siebenlist              franks@mcs.anl.gov
    The Globus Project - Argonne National Laboratory
    
    




    On 24 April, Frank Siebenlist writes: XACML Howto? (3)
     > 6) Need SAML profile for authorization/policy assertions
     > As I mentioned in my first email, case "0)", we have a need to communicate 
     > authorization assertions, and it may make sense to use the xacml 
     > policy-set/policy/rule elements as the format. We still need to wrap them up in 
     > some signed envelope in a standardized manner, and it could make sense to define 
     > another SAML profile for that as it doesn't seem to fit well within the current 
     > SAML authorization assertion.
    
    The draft XACML XML DSig Profile
    (http://lists.oasis-open.org/archives/xacml/200303/msg00063.html)
    contains an example of an XACML Policy enclosed in a SAML
    Assertion.  See Section 4.4.  It is very straightforward.  I used
    the issuer of the Assertion (policy) as the Subject.
    
     > 7) Primitive to express policy to reveal missing attributes?
     > Quoting from the spec:
     > <quote>
     > "urn:oasis:names:tc:xacml:1.0:status:missing-attribute 2805
     > A PDP MAY choose not to return any <StatusDetail> information or MAY choose to 
     > return a 2806 <StatusDetail> element containing one or more 
     > xacml-context:Attribute> elements. If 2807 the PDP includes <AttributeValue> 
     > elements in the <Attribute> element, then this indicates 2808
     > the acceptable values for that attribute. If no <AttributeValue> elements are 
     > included, then 2809 this indicates the names of attributes that the PDP failed 
     > to resolve during its evaluation. The list 2810 of attributes may be partial or 
     > complete. There is no guarantee by the PDP that supplying the 2811
     > missing values or attributes will be sufficient to satisfy the policy.
     > </quote>
     > I find the returning of missing attributes very intriguiging. It still is 
     > unclear to me how we're going to find out what attributes we need from what 
     > authority such that we may be able to satisfy the the policy that allows access. 
     > If we could get that information by trying, or querying the policy service, that 
     > could be a working solution.
     > As mentioned, the returning of the missing attribute info is sensitive 
     > information and should itself be subject to policy. What I can't figure out, 
     > however, is what rule primitives I could use to express that policy...
    
    
    I think this can be a standard access control policy:
      PDP doing the returning = access-subject Subject
      PEP receiving the returned attributes = recipient-subject Subject
      AttributeId to be returned = Resource
      "Disclose to PEP" = Action
    
    Sample rule:
    
     Pseudo-English:
    
      if  access-subject subject-id is PDP L
      and recipient-subject subject-id is PEP A, PEP B, or PEP C
      and resource-id is AttributeId X, or Y
      and action-id is "Disclose to PEP"
    
     Pseudo-XACML:
    
      <Rule Effect="Permit">
        <Target>
          <Subjects>
            <Subject SubjectCategory="recipient-subject">
               <SubjectMatch>
                  subject-id = PEP A
               </SubjectMatch>
            </Subject>
            <Subject SubjectCategory="recipient-subject">
               <SubjectMatch>
                  subject-id = PEP B
               </SubjectMatch>
            </Subject>
            <Subject SubjectCategory="recipient-subject">
               <SubjectMatch>
                  subject-id = PEP C
               </SubjectMatch>
            </Subject>
          </Subjects>
          <Resources>
            <Resource>
              <ResourceMatch>
                 resource-id = AttributeId X
              </ResourceMatch>
            </Resource>
            <Resource>
              <ResourceMatch>
                 resource-id = AttributeId Y
              </ResourceMatch>
            </Resource>
          </Resources>
          <Actions>
            <Action>
              <ActionMatch>
                action-id = "Disclose to PEP"
              </ActionMatch>
            </Action>
          </Actions>
        </Target>
        <Condition FunctionId="is-in">
            <AttributeValue>L</AttributeValue>
            <SubjectAttributeDesignator SubjectCategory="access-subject
                AttributeId="subject-id"/>
        </Condition>
      </Rule>
      
    -- 
    Anne H. Anderson             Email: Anne.Anderson@Sun.COM
    Sun Microsystems Laboratories
    1 Network Drive,UBUR02-311     Tel: 781/442-0928
    Burlington, MA 01803-0902 USA  Fax: 781/442-1692