RE: [xacml] URI-match function proposal

[Tim Moses <tim.moses@entrust.com>]

Bill - It's "starting" to make sense.  But, before I let you entirely off
the hook, there are just a couple of things ...

1. There seems to be nothing to distinguish your two <ResourceMatch>
elements, although they are to be treated entirely differently.  How will
the processor know that the first match is for the host and the second one
is for the resource?  Shouldn't they have different
<ResourceAttributeDesignator> elements?  Also, the fist match could include
the initial portion of the local path, could it not?

2. Remember, in my use-case, I need to create multiple queries for target
patterns that are "more general" than the PDP's topic.  For example, if the
"topic" is "www.example.com/resources" then I need to generate several
queries:

one that exactly matches "www.example.com/resources",
one that exactly matches "www.example.com/",
one that exactly matches "example.com/" and
one that exactly matches ".com/".

Otherwise, I won't find policies whose scopes "include" the topic.  Or were
you proposing a different approach?  It seems to me that this would be
rather difficult if the full freedom of reg-exp is allowed.

In addition, I have to locate policies that apply to a "more specific"
scope, such as "www.example.com/resources/finance"

All the best.  Tim.


-----Original Message-----
From: Bill Parducci [mailto:bparducci@gluecode.com] 
Sent: Friday, July 09, 2004 5:03 PM
To: 'xacml'
Subject: Re: [xacml] URI-match function proposal


Tim Moses wrote:
 > Bill - Are you (furthermore) claiming that your proposal addresses my  >
use-case (i.e. locating and retrieving applicable policies from an SQL  >
database)?  If so, I would like to understand how.  All the best.  Tim.

well, my thinking is this:

[...]
   <Resources>
    <Resource>
*   <ResourceMatch MatchId="url-subtree-match">
*    <AttributeValue>www.example.com</AttributeValue>
      <ResourceAttributeDesignator AttributeId="resource-id"/>
     </ResourceMatch>
*   <ResourceMatch MatchId="url-subtree-match">
*    <AttributeValue>\/.*\.cgi</AttributeValue>
      <ResourceAttributeDesignator AttributeId="resource-id"/>
     </ResourceMatch>
    </Resource>
   </Resources>
[...]

OR , if we wanted to express the matching of "cgi" files anywhere in the
universe:

[...]
   <Resources>
    <Resource>
*   <ResourceMatch MatchId="url-subtree-match">
*    <AttributeValue></AttributeValue>
      <ResourceAttributeDesignator AttributeId="resource-id"/>
     </ResourceMatch>
*   <ResourceMatch MatchId="url-subtree-match">
*    <AttributeValue>\/.*\.cgi</AttributeValue>
      <ResourceAttributeDesignator AttributeId="resource-id"/>
     </ResourceMatch>
    </Resource>
   </Resources>
[...]

in both cases the first resource attribute refers to the host (uri match)
and 
the second to the host resources (regex match).  this would also work for
all 
other url matches without creating another function. seems straightforward
to me 
(which usually means i am missing something ;o)

does this make sense?

b

as an aside, i would access applicable policies using resource from an RDBMS

using something like this:

SELECT * from policies where REGEXP_LIKE (resource, 
'^[hH][tT][tT][pP]:\/\/[eE][xX][aA][mM][pP][lL][eE]\.[cC][oO][mM]\/.*\.cgi')
;

assuming you are using oracle. db/2 (with extensions) and mysql can be used 
similarly. sqlserver requires some creative programming (i think). anyway,
my 
position is that anything we create with our policy definitions will require

some form of mapping to the policy store retrieval language, so precision is

highly desirable (all of the SQL LIKE variants i have seen haven't been much

prettier than regex ;o)

for 3 of the 4 DBMSs listed, the query string mapping is actually fairly
trivial 
since they support POSIX derivatives of regex natively.

now if the idea is to search for policies that themselves contain macro 
expressions for resources then the complexity of the description language 
argument becomes moot because this would almost have to be an (internal) 
mnemonic that is managed by the interface between the policy developer and
the 
policy store (the UI in my twisted world). free form definition of 
macros--particularly if they are non-standard--will not work in my opinion
(it 
is effectively "ANY" on steroids ;o)

ok, i am way out in the weeds here. sorry about that.


To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.p
hp.