Re: [xacml] Issues for the next delegation draft

[Erik Rissanen <mirty@sics.se>]

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