When XACML talks about a "regexp-match", which regexp rules is it referring to?

Question

I've used up a lot of time on regular expressions that I thought concisely and accurately represented the resource URI and action string ranges I wanted to permit, but it returns a Deny for every seemingly valid match. I have yet to see a useful, real-world (as opposed to hello-world) example of a XACML regexp, and many of those I have seen don't even escape the dots in an IP address!

Regular expressions mean different things in different contexts, which is why Perl regular expressions are specifically referred to as such. The use of the generic term "regexp" tells me nothing, just as many of the XACML examples I've seen tell me nothing that is of any use to expand upon.

Have I missed an explicit set of rules or a source of imaginative uses for string-regexp-match and/or anyURI-regexp-match?

Thanks for tolerating my rant.

BTW, I found no parsers for XACML that give mere warnings for a missing DTD and continue parsing for real errors.

One final question: Is there anything in this dependency excerpt from build.gradle that might prevent regexp matching even on something as wimpy and simpleminded as some of those I've seen documented for XACML?

compile group: 'org.herasaf', name:"xacml-core", version: 'latest.integration'

Answer 1

So many questions in a single question. I'd recommend you'd split it. Also, your question is very broad. Not the best format for a good quality answer but here goes.

1. Why a regexp-match function in XACML?

Actually you are putting your finger in the right spot: a well-written attribute-based access control policy using XACML should probably not use regular expressions. You typically use regular expressions when the attribute values you use to make decisions are not normalized. For instance imagine you wanted to match a phone number with Raleigh, NC (919 area code). You'd use a regular expression (or maybe more simply a stringIsIn). But in fact what you should do is either a function that given a phone number returns the area code or - even better - a policy information that given a phone number returns the town it belongs to.

I write a lot of policies for Axiomatics customers and the only time I have to use regexp-match is when data is dirty and not normalized.

Another argument against using regexp-match is that it makes the policies harder to understand. You want to keep it simple e.g.

A person can view a medical record if they own the record or if the record is owned by a dependent.

That's meaningful and human-readable. Regexps are not.

In the same category, you could add attribute selectors, this capability in XACML to define XPath expressions to extract information from XML content.

2. XACML parsers

By definition XACML parsers are XML parsers that validate the structure of the document only. That's how XML parsing works. That's how DTD (or XSD) works. You will not get a warning if you use invalid values. For instance in XACML, if you use a fake datatype e.g. bla:fake:NotBoolean, then a plain XML parser against the XACML schema would not complain.

You need additional logic to be implemented. I am pretty sure the SunXACML engine will give you that. Alternatively the Axiomatics engine will. It would complain that there is an unknown data type, combining algorithm or function.

In any case, none of the parsers would tell you whether the policy makes sense. If you write a target that says a>1 AND a<1 (this will never happen), the parser would not tell you that there is an invalid expression. It's not invalid from its perspective.

HerasAF is pretty old if I remember correctly. I'd have a go at any of the following:

• SunXACML (Java / Open Source / not actively maintained), the mother of all implementations
• ATT XACML Engine (Java / Open Source / new) a new implementation written by AT&T
• Axiomatics Policy Server (Java & .Net / Closed Source - commercial / active) a commercial solution for ABAC and XACML (disclaimer: I work there).