OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


Subject: Re: [xacml] Re: [xacml-comment] D024


On Tue, 3 Dec 2002, Anne Anderson wrote:

> Polar, I disagree.  In my opinion, the type checking for
> arguments to functions should be done at the time the function is
> evaluated, not at the time the policy is parsed.

Hmmm. so, we must be calling every policy that merely passes the policy
schema a "valid" policy?

That's like saying that

class Josed
{
    String ridiculous(String s)
    {
        return 1 + s;
    }
}

is a valid Java class definition. Try to evaluate that.

> Since we have not specified the type-correctness of XACML functions
> using XML, the type correctness must be checked after the policy is
> parsed by the XML parser.

Well there is no way to describe type correctness in XML through the use
of a schema. That technology is far less advanced than the idea.  The
schema is merely a syntax grammar. That's why we have the document. To
describe the semantics that cannot be described in XML.

> It could be done as a second, XACML-specific parsing step, but I believe
> it is probably cleaner to have the type checking done at the time the
> function is evaluated.  This may make it easier to deal with plug-in
> custom functions.

Now, doesn't that force a PDP to accept BAD policies?

I wouldn't call that "security savvy".

Any policy that has something wrong with it, like a type error is
extremely suspect and leaves me no assurance as to its correctness of its
other parts.

Are we forcing PDP's to accept policy sets with nonsensical policies,
accept policies with nonsensical rules, accept rules with nonsensical
conditions, and accept conditions with nonsensical elements, for example,
within an AND or and OR, of which only depending on certain input you find
them invalid?

IMHO, horrible!

If XACML forces my PDP to accept Policy Sets that merely validate against
a parse tree but cannot come to some semantic meaning or integrity of
evaluation, then why bother with the types at all?

In fact, why even bother validating against the policy or request schema?

Do we have conformance tests for Policies and RequestContext that do not
conform to the schemas? If not, why not?

If so, what do they evaluate to?

A conformance test for:

<?xml version="1.0" encoding="UTF-8"?>
<Policy/>

against

<?xml version="1.0" encoding="UTF-8"?>
<RequestContext/>

Both structures are valid XML, aren't they? What would a compliant valid
PDP evaluate this scenario to?

Cheers,
-Polar




>
> Anne Anderson
>
> On 3 December, Polar Humenn writes: Re: [xacml-comment] D024
>  > From: Polar Humenn <polar@syr.edu>
>  > To: Anne Anderson <Anne.Anderson@sun.com>
>  > Subject: Re: [xacml-comment] D024
>  > Date: Tue, 3 Dec 2002 10:51:40 -0500 (EST)
>  >
>  >
>  > D024
>  >
>  > The condition that John is referring to in
>  >
>  > urn:oasis:names:tc:xacml:1.0:conformance-test:IID024:policy3
>  >
>  > in test D024 is not type correct and therefore is not a valid policy, and
>  > therefore not a valid policy set. Although it might niavely parse through
>  > the policy-schema, it should not even be evaluated, because it is not type
>  > correct.
>  >
>  > Cheers,
>  > -Polar
>  >
>  > On Tue, 3 Dec 2002, Anne Anderson wrote:
>  >
>  > > John Merrells,
>  > >
>  > > As in D002, this Condition was intended to produce an
>  > > Indeterminate result (by passing the wrong argument type to the
>  > > function) in order to test the requirements of the
>  > > "first-applicable" algorithm, which says that a Permit or Deny
>  > > result will be returned even if an Indeterminate result follows.
>  > >
>  > > Please let me know if I am overlooking something.
>  > >
>  > > Anne Anderson
>  > >
>  > > On 26 November, John Merrells writes: [xacml-comment] D024
>  > >  > From: John Merrells <merrells@jiffysoftware.com>
>  > >  > To: "'xacml-comment@lists.oasis-open.org'" <xacml-comment@lists.oasis-open.org>
>  > >  > Subject: [xacml-comment] D024
>  > >  > Date: Tue, 26 Nov 2002 17:36:20 -0800
>  > >  >
>  > >  >
>  > >  > Same as D002...
>  > >  >
>  > >  >             <Condition
>  > >  > FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
>  > >  >                 <SubjectAttributeDesignator
>  > >  >
>  > >  > AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
>  > >  >                       DataType="http://www.w3.org/2001/XMLSchema#string"/>
>  > >  >                 <AttributeValue
>  > >  >
>  > >  > DataType="http://www.w3.org/2001/XMLSchema#string";>Zaphod
>  > >  > Beedlebrox</AttributeValue>
>  > >  >             </Condition>
>  > >  >
>  > >  >
>  > >  >
>  > >  > ----------------------------------------------------------------
>  > >  > To subscribe or unsubscribe from this elist use the subscription
>  > >  > manager: <http://lists.oasis-open.org/ob/adm.pl>
>  > >  >
>  > >
>  > > --
>  > > 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
>  > >
>  > >
>  > > ----------------------------------------------------------------
>  > > To subscribe or unsubscribe from this elist use the subscription
>  > > manager: <http://lists.oasis-open.org/ob/adm.pl>
>  > >
>  >
>  >
>
> --
> 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
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>



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


Powered by eList eXpress LLC