[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] URI-match function proposal
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]