Re: [xacml] change request: xacml context attributes and data types

[Polar Humenn <polar@syr.edu>]

On Wed, 2 Oct 2002, Anne Anderson wrote:

> I work with Anne Anderson here at Sun, and recently we've been having some
> discussions about the issue of including type information in Attibutes and
> AttributeValues. I know that there are open issues where feedback is wanted,
> and so she suggested that I send my thoughts to this xacml-comment list
> (I am not on the xacml mailing list). I have been giving her feedback on the
> spec for some time, and I have also been doing some implementation work, so
> these comments come both from the point of view of a policy language designer
> and an implementor.
>
> I am (somewhat) concerned about the choice to remove type information from
> the AttributeValue type in the Policy schema. I understand that the Function
> listed in the AttributeValue tells us what types are allowed, but there are
> two problems I see here.

> First, It is significantly more work for a programmer
> to support this method for finding the attribute's type,

I am always surprised by the way the seller always wants to make his job
easier and make his customer's job more difficult. :)

> and it requires an API that is more complex (for extending the engine
> to support custom functions). This is a small issue, but it's one to
> consider when making a language change.

I'm glad he thinks it's a small issue.

> The second problem I see is more serious. While the function
> gives us the type the attribute is expected to be, it doesn't tell us what
> the attribute's type actually is.

Nor would naming the type in the "dataType" attribute.

> If someone builds a policy, and puts in an integer value (for
> instance) as an input for a function that expects a string, the
> attribute will parse fine, but will not be used in the way that was
> intended for the attribute value.

Is he talking about the "dataType" attribute in the AttributeValue in the
Policy or the Attribute of the RequestContext? I'm confused.

> Obviously this is a simple example where it might not be such a
> problem, but with custom datatypes this could be more serious. There
> is no way to check that the attribute type being used is the correct
> one.

A strong type system like the one we have does so.

> Including the attribute type in the AttributeValue object may be
> redundant from a language point of view, but it provides (in my
> opinion) a valuable reality-check to make sure that the policy isn't
> being evaluated in a manner that the policy author didn't intend.

You should be having tools generating this language in the proper
way. And your typechecker should be doing the proper analysis.

> In the case of the Attribute type in the Context schema, the problem
> is compounded.

I agree that not having the "dataType" in the Attribute of the
RequestContext does present a small problem for some, but only if the
policy really has no idea of the input data model, or the requestor
has no idea of the input model of the policy.

I think that is the real dangerous situation, especially if you
want to have any integrity and/or assurance in your systems.

> First, the implementation is harder, since when you're
> parsing the Request object you can't parse any of the attribute types,
> since you don't know what type they are until you start processing the
> policy and find what functions are being used.

You don't know this anyway, unless you spec out your input model
with the specification of your policy. If you follow strict type
guidelines that compilers have been doing for years, you can actually
deduce the proper types of the RequestContext.

> Not only is this harder, but it's (arguably) less effecient.

If you do this work up front by building a good compiler, it will
be more efficient.

> Second, because you can't parse the attribute values until you
> consider them in the scope of a function, you could end up with
> designators that select the same attributes as inputs into functions
> that take different values. Drawing from the example above, what
> happens if a policy wants to interpret the same attribute as a String,
> an Integer, and some custom type? Is this an error, or should this be
> allowed?

This should be a type inference error since you will have inferred two
conflicting types for the same AttributeDesignator.

> I suspect that all Requests will be formed with attributes of
> known and intended values, so I think this is a real problem.

Huh? That is *exacly* why it would not be a problem.

> Last, because the Attributes aren't being included in the Request in
> the scope of a Function, the requestor has no idea how the attribute
> will be used in the policy, and so trying to guess at the value based
> on the function's types seems very dangerious to me.

The requestor of the PDP should send the PDP what it is expecting. This is
one problem with describing distribted systems with XML. Higly structured
unstructed data. In standard distributed systems, such as CORBA, and even
Java RMI, and believe it or not, DCOM, the server (PDP) specifies its
inputs and the requestor must adhere to that input specification or it
doesn't work, i.e. invalid request.

> I would suggest that the type field in the Attribute type be made
> manditory. It may not seem as pretty in the language, but it heads off
> a lot of ambiguity without adding almost any overhead to the language
> (or making it any harder to form a Request), and that seems like a
> very worthwhile tradeoff to me.
>
> I would welcome any discussion on this topic with those of you on the list. I
> would like to see a final version of the language soon, so please don't take
> any of this as an attempt to slow things down. I have backed off on other
> issues with Anne that I didn't think were worth taking the time to address,
> but I feel this issue is pretty important to sort out. Including the types
> of Attibutes and AttributeValues is a seriously small piece of the schema,
> but it can have significant effects on implementation and interpretation.

I strongly suggest not putting the dataType back into the Policy schema.
It is not needed, and it can cause policy validation problems.

One Issue:

What should a compliant XACML parser do when one attribute Designator for
AttributeId="A" is supplied as an "xs:integer" and the another for
AttributeId="A" is specified with a dataType of "xs:dateTime"?

If we call that an error, then the DataType attribute is not needed,
and your type system can take care of the whole shibang and even
produce a specification of the types of the specific attributes.

Not being able to call this an Error forces you to interpret data on the
fly, removing the benefit of compliation, causing you to think that
attribute "A" should be both an integer or a dateTime.

You may notice I didn't use xs:string in this argument, because that makes
the arguments seemingly easy, because you think you can always do
promotion from data types to strings and back, so you seemingly think you
don't have a problem. A small problem with XML since everything can be
represented as a string.

In the request context, geez, do you really think somebody should be
throwing a bunch of data at a PDP and hope for the best. You should
already know what types and what formats you need.

Cheers,
-Polar


> thanks
>
>
> seth
> --
> Internet Security Research Group
> Sun Microsystems Labs
> ------- end of forwarded message -------
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>