OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

Re: [xacml] Issues for the next delegation draft

  • 1.  Re: [xacml] Issues for the next delegation draft

    Posted 11-01-2005 09:00
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xacml message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


    Subject: Re: [xacml] Issues for the next delegation draft


    Frank Siebenlist wrote:
    
    > Erik Rissanen wrote:
    >
    >> ...
    >> 2. Franks stuff.
    >> ...
    >> For 2, I am waiting for Frank to provide more input.
    >>
    >>   
    >
    >
    > Ok, I'm trying to understand the F2F minutes and have copied some text
    > with my comments.
    
    
    Yes, the minutes can be hard to understand. It's good to hear from you
    though. We didn't understand the minutes from the previous F2F
    ourselves. :-)
    
    > From Day1 F2F minutes:
    >
    >> For Frank's case of wanting to pass Issuer Attributes from the PEP:
    >>
    >> Could handle via Frank's idea of passing additional sets of
    >> Attributes from the PEP as part of initial request.
    >> Could handle via call-backs to the PEP
    >> Could use "Policy Handler" that retrieves those Attributes (i.e. NOT
    >> from the PEP)
    >> Could load Issuer Attributes at the same time a Policy is loaded for
    >> use by the PDP (i.e. NOT from the PEP).
    >> How is the PEP supposed to know all the Attributes of all the Issuers
    >> that MIGHT be involved in the PDP's policies?
    >
    >
    > Day2:
    >
    >> Issue 6
    >> Identity attributes
    >>
    >> Anne: no arguments given yesterday for needing distinguished "*-id"
    >> attributes.
    >>
    >> Hal: use case is where you need to know which attributes might be
    >> keys for retrieving other attributes.
    >>
    >> Erik: Frank wanted to pass Identity Attributes outside of existing
    >> Subject, Resource, etc. "segments" for use in retrieving Attributes
    >> of Delegates and Issuers that may turn out
    >>
    >> to be required. But we are proposing use of SAML
    >> XACMLAuthzDecisionRequest to pass Attributes.
    >> Proposal: Add optional Boolean Identity XML attribute to XACML
    >> XACMLAuthzDecisionQuery
    >> ...
    >> Frank felt policy writer should also include Identity="true" XML
    >> Attribute on <Delegate> Attributes in a policy. But policy writer
    >> should understand all the Attributes used in a policy. Important
    >> thing is to be able to match them against extra Attributes in the
    >> XACMLAuthzDecisionQuery.
    >>
    >> Now when a RequestContext is constructed containing a Delegate
    >> element, attributes corresponding to that Delegate entity could be
    >> picked up from the <Attribute> section of the request. Match on
    >> <Attribute Identity="true" AttributeId="<match element in policy's
    >> <Issuer> Attributes when <Issuer> becomes a <Delegate>.
    >>
    >> Recommendation: add this <Attributes/> element to the
    >> XACMLAuthzDecisionQuery format in the SAML profile.
    >>
    >> How do you know what the potential delegates are?
    >>
    >> a.Could be decided out of band
    >> b.Could be determined by policies that the PEP passes to PDP.
    >
    >
    > I'm a little confused by some of the wording and conclusions in the
    > issue list.
    >
    > I believe that it has been decided to pass arbitrary attribute sets in
    > the xacml-saml authz query interface, but I'm not sure whether that
    > would include the request context...
    > Also, issue#31 is directly related to that, but I don't see any
    > discussion about #31.
    >
    > Then if you pass arbitrary attribute sets, isn't there a need to
    > "know" the primary-keys, i.e. which attributes are identity
    > attributes, to be able to construct the new request contexts?
    >
    > Could you please add some more context of the current state of these
    > related issues?
    
    
    It was decided that the additional attributes and policies would be
    added to the xacml-saml authorization query interface, but _not_ to the
    request context. The request context is not a transport format. It is an
    abstract model for describing the processing model. It was reused as a
    transport format in the current saml profile because that was an easy
    and quick solution, but since the addition of additional attributes in
    the request context does not fit the request context from the processing
    point of view, it was decided to instead redo the saml authz request.
    
    The saml authz request would contain mechanisms for passing additional
    attributes as well as indicating the primary keys among them. The
    attributes would migrate from the saml request to the context handler in
    an implementation specific manner. From the context handler, they will
    become available in the request context in the same form as "normal"
    attributes that were not coming from "outside".
    
    The F2F minutes are a bit confusing, as you say, since we did not know
    for sure exactly what your requirements are. I suppose what would be
    good is if you could propose concrete syntax for the saml authz request.
    
    
    >
    > Day3:
    >
    >> #4: Sub-PDPs: Frank needs to submit proposed syntax for the
    >> information he needs to pass to the sub-PDP.
    >
    >
    > Right now, a policy={target + effect-rules + policyIssuer}
    >
    > the idea is to have a pdpPolicy = {target + pdpReference + pdpIssuer}
    >
    > the semantics is that if the target matches the request context, then
    > that same request context will be used to query the PDP rferred to by
    > the reference, and the PDP's decision result will become the
    > equivalent policy decision with the associated pdpIssuer that should
    > be used by the evaluator.
    >
    > It would allow you to incorporate the decisions of external PDPs
    > within the local policy evaluation. We have essentially built this in
    > our code, and it would be great to be able to use xacml-3 for this.
    >
    > My main question is whether it is doable to add this kind of pdpPolicy
    > construct as a policy equivalent to the language?
    
    
    I am not a real XACML expert :-), so I am not sure about this. It makes
    sense form the logical point of view, but my concern is whether there
    are issues surrounding the context handler. Since the request context is
    an abstract construct representing all the attributes that the context
    handler knows, and not something fixed that comes from the outside, it
    might be complex at the implementation level to pass the _same_ request
    context to the other PDP. For instance, the context handler might not
    look up an attribute until the PDP encounters a reference to that
    attribute, meaning that even though the abstract request context is
    defined, it does not exist as an concrete fixed data structure during
    processing. This would mean that the request context sent to the other
    PDP might be indeterministic. Also, we have to factor in that the
    context handler at the remote PDP would affect the request context over
    there, so it would add additional indeterminism if we would view the PDP
    reference as evaluating remote policies with the _same_ request context.
    
    Of course, these issues could be solved simply be defining the PDP
    reference semantics in an appropriate way. Or, as you perhaps intend, to
    let the PDP reference use the transport format, rather than the request
    context as the input to the remote PDP.
    
    
    >
    >> #8: Alternate Owner-Policy-Statement to determine sentinel
    >>
    >> Hal: What does "sentinel" mean?
    >> Erik: detection of loops; we solve by excluding the policy being
    >> authorized. Delegation depth can also help with loop detection.
    >> STATUS: we need better explanation from Frank along with a proposal.
    >
    >
    > The idea was that you would have a policy database where each policy
    > statement could have a different policyIssuer, and that only at the
    > time of evaluation you would need to know who the resource-owner is,
    > i.e. the identity that has to be at the end of any valid policy
    > decision delegation chain.
    >
    > This means that you could make that resource-owner be associated with
    > the PDP, or you could let a client specify in the request context who
    > the resource-owner is for the requested evaluation. In the latter
    > case, you could share policy statements and a single PDP among several
    > different resource owners, and the use case will make most sense with
    > a central external PDP that is accessed through the xacml-saml authz
    > decision query.
    >
    > So the proposal is to allow a (optional) resource-owner that should be
    > considered for the evaluation, to be passed in the request context.
    
    
    This is interesting and is somewhat different from the current
    processing model and trust model. Currently the (unstated) assumption
    has been that each resource owner runs their own PDP, meaning that the
    resource owner controls the root policies in the PDP. In this case there
    is no need to define the sentinel, since the appropriate sentinel is the
    trusted issuer in all cases.
    
    What you envision here is a PDP that is not owned by the resource owner,
    rather is shared by many resource owners, where there are no special
    trusted policies, but rather every policy has an issuer and each PEP
    indicates in the request which issuer the PDP should reduce to. Without
    having thought too much about it, this seems like it might be a good
    idea, but I am not sure. It seems to me that  the same effect can always
    be achieved by entering a trusted root policy for each resource in the
    PDP. The trusted "resource root policy" would contain the resource
    owner, that is, the sentinel, as the delegate. Does the alternate
    sentinel model provide something that this
    root-policy-with-sentinel-as-delegate cannot do? Perhaps there are
    practical reasons for the alternate sentinel?
    
    
    > Thanks, Frank.
    >
    > PS. I'm unable to edit the issue wiki page as my oasis
    > username/password don't seem to work ... is there a separate access
    > control for this?
    
    
    I use my OASIS username/password, so I cannot really help you there.
    
    Best regards, Erik
    
    
    
    


    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]