RE: [xacml] URI-match function proposal

["Daniel Engovatov" <dengovatov@bea.com>]

Completely agree.  There is no value in trying to define a Yet Another
Regex standard to implement.   Not to mention that to put it into the
rule target, which is supposed to be used for easy rule search and
analysis, is even less helpful: for those who are concerned about
runtime efficiency and policy analysis - we define a different way to
handle applying rule to a hierarchy of resources.  For those who can
live with evaluating regular expressions for every rule in the system
when looking them up - we already have that. :)

Daniel

-----Original Message-----
From: Bill Parducci [mailto:bparducci@gluecode.com] 
Sent: Wednesday, June 23, 2004 11:55 AM
To: 'xacml'
Subject: Re: [xacml] URI-match function proposal

in contrast to functions like e-mail matching where we can reference an
accepted 
standard for format (and leave the 'proof to the reader'), i posit that
what we 
are trying to do here is create our own version of regex matching syntax
(as was 
the case with version). as pointed out by michiharu--things like
hierarchies can 
be syntactically variable so the problem is unbounded without general
string 
operators and XACML defining such operators seems a bit risky to me.

maybe i am not missing something important here but we have a way to
match 
hierarchical expressions against a filter: regexp-string-match. per the
current 
spec, it uses the XPath/XQuery implementation of regex (extending
XMLSchema's 
use by including things like '$' and '^') and should be able to match
any 
hierarchy you can think of.

using some of the examples on the list i came up with the following:

Pattern: ^/a[^/]*$
  MATCHES  /a
  MATCHES  /ab
  NO MATCH /a/
  NO MATCH /ac/
  NO MATCH /a/b/c
  MATCHES  /askfjl28746.82347

Pattern: ^a[^:]*$
  MATCHES  a
  NO MATCH a:
  NO MATCH a:b
  MATCHES  abc
  NO MATCH abc
  MATCHES  abc/d

Pattern: ^http:\/\/a\.b[^/]*$
  MATCHES  http://a.b
  MATCHES  http://a.bclkjdslkj
  NO MATCH http://a.b/
  NO MATCH http://a.bkljlk/
  NO MATCH http://a.b/d

Pattern: ^/a.*\/..*\.html[^/]*$
  NO MATCH /a
  MATCHES  /a.html
  MATCHES  /a/y.html
  MATCHES  /a1/y1.html
  NO MATCH /a1/y1.html/

Pattern: ^http:\/\/a\.b\/x\/.*$
  NO MATCH http:/a
  NO MATCH http://a
  NO MATCH http://a.b
  NO MATCH http://a.b/x
  MATCHES  http://a.b/x/
  MATCHES  http://a.b/x/kjlkj
  MATCHES  http://a.b/x/kjlkj/klj

is it me, or is this pretty straightforward? as far as i know, the
expressions 
above conform with the XPath/XQuery use of regex.

b

Michiharu Kudoh wrote:

 > Of course this is not complete but I believe that this covers several
 > peoples' requirements including me.
 >
 > The basic idea is the following:
 > - Match function that works on URI syntax (including URL and URN)
 > - Pattern match character includes "*", "?", and "**" (maybe more)
 >   + "*" is used for single-node match.
 >   + "**" is used for sub-tree match (from Ant).
 >   + "?" is used for one-character match.
 > - Hierarchical separators are "/" and ":" (or more).

[...]

 > One problem I had in the above example is that there is no simple
syntax
 > that matches both the indicated node and its sub-tree. For example,
if we
 > need to specify a policy that matches to /a and the sub-tree, we need
to
 > specify two patterns i.e. /a and /a/**. JSR115 uses /a:/a** where ':'
 > indicates 'or' combination of two patterns that conflicts with
patterns for
 > the urn cases above.
 >
 > So the following is one of the solution for this problem:
 > - Introduce "***" for representing both the indicated node and its
 > sub-tree. For example, /a/*** is a shorthand of /a and /a/**. Thus
/a/***
 > matches /a, /a/b, /a/b/c etc.

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_workgro
up.php.