OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

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

  • 1.  Re: [xacml] Re: [xacml-comment] D024

    Posted 12-03-2002 13:18
     MHonArc v2.5.2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    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