RE: [xacml-users] RE: XACML ipAddress-regexp-match and how to author a policy with dynamic

[Oleg Gryb <oleg_gryb@yahoo.com>]

I think you can't use FunctionId attribute in Condition, you need Apply inside Condition to be able to use functions. Check XACML 2.0 syntax.

--- On Fri, 5/8/09, Chris McKenzie <chris.mckenzie@thirdbrigade.com> wrote:

> From: Chris McKenzie <chris.mckenzie@thirdbrigade.com>
> Subject: RE: [xacml-users] RE: XACML ipAddress-regexp-match and how to author a policy with dynamic
> To: "Rich.Levinson" <rich.levinson@oracle.com>
> Cc: xacml-users@lists.oasis-open.org
> Date: Friday, May 8, 2009, 10:03 AM
> Ok, I think I've got the general idea
> and syntax.
> 
> AttributeDesignator can return multiple values for an
> attribute and is generally handled as a typed bag, and even
> if only one value is set/returned. So by simply making an
> attribute MustBePresent, the -is-in function can be used to
> determine if one attribute is contained in an external bag.
> 
> <Condition
> FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-is-in">
>  <AttributeValue
>    AttributeId="urn:oasis:names:tc:xacml:1.0:security:threats:badIpAddresses"
>    MustBePresent="true"
>    DataType="http://www.w3.org/2001/XMLSchema#string"/>
>  <SubjectAttributeDesignator
>    AttributeId="urn:oasis:names:tc:xacml:1.0:subject:ipAddress"
>    MustBePresent="true"
>    DataType="http://www.w3.org/2001/XMLSchema#string"/>
> </Condition>
> 
> Am I close? ;-)
> 
> Thanks.
> 
> -Chris
> 
> -----Original Message-----
> From: Chris McKenzie 
> Sent: Wednesday, May 06, 2009 11:54 AM
> To: 'Rich.Levinson'
> Cc: xacml-users@lists.oasis-open.org
> Subject: RE: [xacml-users] RE: XACML ipAddress-regexp-match
> and how to author a policy with dynamic
> 
> Thanks for the quick reply Rich!
> 
> I was aware of the Context Handler, but the policy XML
> syntax sort of eluded me. The Data Flow diagram was also
> pretty clear but how the PIP tied into the policy XML syntax
> was also unclear.
> 
> Thanks for filling in my blank that it's the Context
> Handler's job to populate any unknown Attributes by
> AttributeId, and that the Context Handler or PIP
> implementation is required to interpret the requested
> AttributeId to something we expect the policy to use. (like
> a set or string, etc...)
> 
> So the policy syntax for external PIP Attributes for a mock
> policy (without any real implementation) could be anything
> representative. E.g.
> urn:oasis:names:tc:xacml:2.0:resource:target-namespace
> 
> The only unanswered question is how would the syntax to
> request a set/bag of Attributes work? There isn't a Data
> Type for set/bag, more that the string-bag/string-set
> functions can enumerate a list of strings in the policy. So
> how would I externally reference an Attribute list?
> 
> For example, here's a Condition where the bag is created
> from a policy included list:
> 
> <Condition
> FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-set-equals">
>  <Apply
> FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
>   <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string";>116.14.1.95</AttributeValue>
>    <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string";>65.4.89.192</AttributeValue>
>  </Apply>
>  <SubjectAttributeDesignator
> AttributeId="urn:oasis:names:tc:xacml:1.0:subject:ipAddress"   DataType="http://www.w3.org/2001/XMLSchema#string"/>
> </Condition>
> 
> How would I externally reference an Attribute value that
> needs to be a list? Something like this:
> 
> <Condition
> FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-set-equals">
>  <AttributeValue
>    DataType="http://www.w3.org/2001/XMLSchema#string";
>    AttributeId="urn:oasis:names:tc:xacml:2.0:resource:badIpAddresses"/>
>  <SubjectAttributeDesignator
> AttributeId="urn:oasis:names:tc:xacml:1.0:subject:ipAddress"
>    DataType="http://www.w3.org/2001/XMLSchema#string"/>
> </Condition>
> 
> Or am I completely off and I should be interoperating the
> PIP response as XML based, and look at the XPATH functions?
> 
> This is just one of those cases where an example is either
> missing, or I'm just again not familiar with the terminology
> and its right in front of me.
> 
> Thanks again!
> 
> -Chris
> 
> 
> From: Rich.Levinson [mailto:rich.levinson@oracle.com]
> 
> Sent: Tuesday, May 05, 2009 6:48 PM
> To: Chris McKenzie
> Cc: xacml-users@lists.oasis-open.org
> Subject: Re: [xacml-users] RE: XACML ipAddress-regexp-match
> and how to author a policy with dynamic
> 
> Hi Chris,
> 
> I think you have analyzed the situation pretty well,
> however, it appears to me that there is one key concept that
> you need to incorporate, which is the role of the context
> handler (XACML 2.0 lines 246-248):
> Context handler - The system entity that converts decision
> requests in the native request format to the XACML canonical
> form and converts authorization decisions in the XACML
> canonical form to the native response format.
> The key concept here is that the ch is responsible for
> converting between canonical XACML form and native forms. 
> 
> The 2nd key concept you need is that of "missing
> attributes", which is defined in several places in the spec,
> primarily section 7.15.3 and related sections such as 5.37
> lines 2614-2617 where MustBePresent is defined, and provides
> further refs to relevant info in the spec.
> 
> Basically, what it all boils down to is the following:
> 1. If an attribute defined in a Policy has MustBePresent
> set to true, then if that attribute is not present in the
> Request, then the ch is invoked as described in section
> 7.2.5 lines 3313-3315:
> o "The PDP SHALL reference the attributes as if they were
> in a physical request context document, but the context
> handler is responsible for obtaining and supplying the
> requested values by whatever means it deems appropriate."
> 2. The "appropriate means" is described, for example, in
> section 3.1 lines 584-592, steps 5-10, which is basically,
> as in steps 6 and 7, that the ch tells the PIP what it wants
> and gets it. We can assume that the ch translated the XACML
> AttributeId of the missing attribute to whatever native
> format the PIP uses to access the attribute and return it to
> the ch.
> The 3rd and final key concept that is required is that one
> must assume that all attributes come from outside the XACML
> domain in some sense and there must be a mapping of the
> XACML AttributeId to the native attribute access mechanism.
> This is really true for attributes submitted to the PEP as
> well, since those attributes will be in some native format,
> and something must associate that native format with a XACML
> AttributeId and DataFormat in the process of submitting the
> request.
> 
> I think the general answer is that there needs to be a
> mapping between AttributeIds defined in XACML policies and
> native attributes that come from systems external to XACML
> that are used in evaluating XACML Policies, and that these
> mappings are defined by the organizations that define the
> Policies and attributes that are used by those Policies.
> 
> Let me know if this helps or if you need any further
> details.
> 
>     Thanks,
>     Rich
> 
> 
> Chris McKenzie wrote: 
> I've made some progress, so please let me refine my
> question.
> 
> I can't determine how a policy might reference a source of
> PIP
> information in different formats. For example, in the below
> policy, the
> Condition's set/bag would ultimately be referencing an
> external PIP
> source of information. There's a gap in the XACML spec
> between where the
> PIP is a source of Attributes and how to reference those
> Attributes and
> how the resulting policy might reflect this.
> 
> For example, my policy CAN'T list every set/bag attribute
> individually.
> It would be impractical. So what's the syntax for
> referencing said
> set/bag? I'll keep digging, and its probably spelled out in
> the spec,
> but for right now it feels like the spec doc is missing
> this piece.
> 
> Thanks!
> 
> <Policy
> PolicyId="urn:oasis:names:tc:policy:WebAccess">
>   <Description>This policy is intended to allow
> access to corporate web
> servers, except where threat hosts have been
> identified.</Description>
>   <Target>
>    <Subjects>
>      <AnySubject/>
>    </Subjects>
>    <Actions>
>     <AnyAction/>
>    </Actions>
>    <Resources>
>     <Resource>
>      <ResourceMatch
> MatchId="urn:oasis:names:tc:xacml:2.0:function:ipAddress-regexp-match">
>       <AttributeValue
> DataType="http://www.w3.org/2001/XMLSchema#string";>
>        
> ^(10)\.(10)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9])\:([80|443])$
>       </AttributeValue>
>       <ResourceAttributeDesignator
>        
> AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
>        
> DataType="urn:oasis:names:tc:xacml:2.0:data-type:ipAddress">
>       </ResourceAttributeDesignator>
>      </ResourceMatch>
>     </Resource>
>    </Resources>
>   </Target>
>   <Rule
> RuleId="urn:oasis:names:tc:policy:ThreatRule:0"
> Effect="Deny">
>    <Description>Hosts will be
> conditionally granted access as long as
> their are not identified as a threat.</Description>
>     <Target>
>      <Subjects>
>       <AnySubject/>
>      </Subjects>
>      <Actions>
>       <AnyAction/>
>      </Actions>
>      <Resources>
>       <AnyResource/>
>      </Resources>
>     </Target>
> 
>     <Condition
> FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-set-equals">
>      <Apply
> FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-bag">
>       <AttributeValue 
>  
> DataType="http://www.w3.org/2001/XMLSchema#string";>116.14.1.95</Attribut
> eValue>
>       <AttributeValue 
>  
> DataType="http://www.w3.org/2001/XMLSchema#string";>65.4.89.192</Attribut
> eValue>
>      </Apply>
>      <SubjectAttributeDesignator
>  
> AttributeId="urn:oasis:names:tc:xacml:1.0:conformance-test:test-attr"
>       DataType="http://www.w3.org/2001/XMLSchema#string"/>
>     </Condition>
> 
>   </Rule>
>  </Policy>
> 
> 
> 
> -----Original Message-----
> From: Chris McKenzie 
> Sent: Tuesday, May 05, 2009 10:12 AM
> To: 'xacml-users@lists.oasis-open.org'
> Subject: XACML ipAddress-regexp-match and how to author a
> policy with
> dynamic 
> 
> Hi.
> 
> The mailing list isn't easy to search, so I thought I would
> pose my
> question while commanding the list to e-mail me the last
> 150 posts.
> 
> I was trying to put together an XACML 2.0 policy set that
> captured 2
> policies, which when combined, allowed for both a sort of
> global allow
> and selective deny. Essentially a Firewall access policy
> where hosts
> which have been identified as a threat would be denied
> access to the
> target resource. (say a web server) The PIP information
> supplying the
> list of threat IP Addresses could be sorted in a database.
> 
> My main query that I can't gather from the literature I've
> read so far
> is how all attributes of a Subject, Action or Resource are
> identified.
> (I'm sure it's an easy answer, I'll be happy with anything
> really) For
> example, an external system identifies a point of
> information which the
> policy would use to help determine if a deny rule should be
> applied. In
> this case, how is the policy authored to reference
> attributes of said
> piece of information?
> 
> For example, a SIM event (we'll just go with this for now)
> which
> contains the threatening host IP and requested resource.
> (say a
> protected portion of the corporate web site) How do I
> identify the PIP
> information in a urn? I was assuming that when the PDP
> gathers
> information from the PIP (and from the PEP's access request
> message?)
> that the Subject, Action and Resource will have things like
> subject-id's
> ipAddress attribute already populated, because the Subject
> in question
> has an IP.
> 
> Maybe I'm just not there yet. So I'll leave my query here.
> If anyone has
> a bit of practical advice to enlighten me, it would be very
> beneficial.
> 
> Thanks!
> 
> Sample policy with a hole (note the ...???) where the
> external PIP
> information on threat host IPs would be referenced:
> 
> <Policy
> PolicyId="urn:oasis:names:tc:policy:AttackerThreat">
>   <Description>This policy is intended to deny
> attacking hosts for
> corporate web servers.</Description>
>   <Target/>
>   <Rule
> RuleId="urn:oasis:names:tc:policy:ThreatRule:1"
> Effect="Deny">
>    <Description>All identified host
> threats shall not be permitted
> access.</Description>
>     <Target>
>      <Subjects>
>       <Subject>
>        <SubjectMatch
> MatchId="urn:oasis:names:tc:xacml:2.0:function:ipAddress-regexp-match">
>         <AttributeValue
> DataType="http://www.w3.org/2001/XMLSchema#string";>
>           ...???
>         </AttributeValue>
>         <SubjectAttributeDesignator
>          
> AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
>          
> DataType="urn:oasis:names:tc:xacml:2.0:data-type:ipAddress">
>        
> </SubjectAttributeDesignator>
>        </SubjectMatch>
>      </Subjects>
>      <Actions>
>      
> <AttributeValue></AttributeValue>
>      </Actions>
>      <Resources>
>        <Resource>
>          <ResourceMatch
> MatchId="urn:oasis:names:tc:xacml:2.0:function:ipAddress-regexp-match">
>           <AttributeValue
> DataType="http://www.w3.org/2001/XMLSchema#string";>
>  
> ^(10)\.(10)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9])\:([80|443])$
>           </AttributeValue>
>          
> <ResourceAttributeDesignator
>  
> AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
>            
> DataType="urn:oasis:names:tc:xacml:2.0:data-type:ipAddress">
>          
> </ResourceAttributeDesignator>
>      
>    </ResourceMatch>
>        </Resource>
>      </Resources>
>     </Target>
>     <Condition>
>       <Apply
> FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
>         <Apply
> FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">
>          
> <SubjectAttributeDesignatorAttributeId="protocol"
>             DataType="http://www.w3.org/2001/XMLSchema#string"/>
>         </Apply>
>         <AttributeValue
>           DataType="http://www.w3.org/2001/XMLSchema#string"/>tcp
>         </AttributeValue>
>       </Apply>
>     </Condition>
>   </Rule>
>  </Policy>
> 
> 
> 
> 
> Chris McKenzie
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xacml-users-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xacml-users-help@lists.oasis-open.org
> 
>   
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xacml-users-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xacml-users-help@lists.oasis-open.org
> 
>