"...and when one common language is used, policy management becomes much easier."
"Easier" - compared to what? Who and how have measured this?
Do you suggest that the administrators will have to manage raw XML? If not, does it really matter whether you use XML or anything else? If yes, try to imagine a human being with a living soul inside typing in Notepad something of the following kind:
We have developed our own language for expressing policies in XML in our own time (http://sec.isi.salford.ac.uk/permis/). What we have found out was that NOBODY wants to learn XML just to be able to write our "simple" policies. Note that we even suggested them to use Xeena with DTD of our policy loaded, to make their life easier.
Conclusions? You need a really human friendly tool for writing policies, and humans, apart from those who debug the decision-making engine, don't give a crap for the ENCODING of the policy (XML? ASN.1 BER?).
Now, imagine parsing a string to parsing a definite-length BER - that's earth and heaven! Because in XML you need to _search_ for tags and think about their names, and in BER you instantly get the size of a data block. BER is determined to be space efficient, and XML isn't.
Have you ever considered to have a BER-encoding of XACML? Really, there are only syntactical differences between ASN.1 definitions and XML schema. Encoding policies in XML is no different to encoding policies in BER.
In our own time we have done performance tests. XML is about an order of magnitude bigger and slower than BER. Compare loading an XML policy of 4KB in size to loading ten 400byte-BER-encoded-certificates - almost 1.5 seconds against under half a second with signature verifications on each of the certificates.
Questions:
1. Do you see XACML as a human-friendly language?
2. What priority do you set for a policy editor?
3. Any considerations about BER-encoding of XACML?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just some of my thoughts as an 'outside observer' i.e. not involved in the XACML definition.
XACML is different to most Access Control definitions because it is an 'open ended' language, i.e. not constrained to an object model (such as roles, attributes and targets). This makes it potentially far more powerful e.g. allowing dynamic and complex relationships to be included in the policy definitions.
In XACML its the PAP, which defines the policies, and presumable have the 'user interface'.
Ultimately any but the simplest construct in XML is not human readable, or readable by most humans. This probably true of any formalisation e.g. COBOL, SQL and other 'natural' programming languages, Mathematical notations or even legal documents.
The point about the OASIS / ebXML process and XML is achieving some kind of consensus. I.E. the drivers are pragmatics / political not purely technical. If the choice of technologies was purely technical then we would be using CMIP, GDMO and ASN.1 / BER or CORBA not SOAP, schemas / DTD and XML etc. for web services, object modelling and encoding. However those earlier technologies only achieved a limited industry consensus (i.e. didn't include you know who).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am novice to XACML, and I appreciate its extensibility. (Though, I don't see why we have XML-text encoding, and perhaps we could think about XML-binary encoding).
I am not sure how a Role Hierarchy could be expressed in terms of XACML definitions. I simply don't see the means of defining how a policy can define the order of values for a particular attribute. Do you know what XACML mechanism I should look at?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry I've been slow here. In case anyone is still looking for some answers...
Manageability obviously means a lot of things. No, I don't think that XACML is user-friendly, and I certainly don't expect many people will want to work directly with the XML. Do I see tools as a high priority? Definately. I have a (slowly moving) project in this space. If more people wanted to get involved (hint, hint) then it would move faster.
So, given this, why do we claim that a standard, general language helps with management? Well, for one thing because tools are written on top of languages. Even if you don't have to learn the XML tags, you still need to learn something about the sematics of a language, and you need to learn the tools. A single language means you only need to learn these things once.
Another big thing is that XACML makes cross-domain management easier. If different administrative domains are writing policies that need to work together (which is something that XACML is explicitly designed to support), then having a single representation, even if it's only used as an intermediate form, makes this _much_ easier, and lets you do things like infer and reason about the system as a whole. This is really powerful stuff that you can't do if there are myriad different languages floating aound.
Does XACML solve all the problems in this space? Probably not. I'm pretty familiar with PERMIS, and I think there's a lot of cool stuff there. David Chadwick and I have spoken at length about some of the policy and related challenges in these systems, and there's definately more progrtess to be made. I personally think that XACML is a good step towards a more managable system. I would be very interested in hearing your thoughts about this!
FYI, about the XER question, I answered that one in a separate thread. Personally, I like binary encoding schemes provided by ASN.1-related technologies, but I think I'm part of an increasing minority.
seth
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Our work started from your premise, with which I emphatically agree. When XACML is judged by the standard of other human-computer languages, it is by far the worst I've ever seen (far worse than COBOL). And only some of its problems can be blamed on XML.
Our first shot at addressing this was to transform XACML to ACE (Attempto Controlled English). This was quickly dropped when we realized ACE has nothing like parentheses for handling precedence issues, and these are very common in XACML policies. Using commas to swap and-or precedence helps correctness, but not readibility.
The next pass was to compile XACML to Java. This worked extremely well. The generated Java code is easier to read than the original XACML (our real goal), and has the added advantage that you can then debug policies directly (instead of stepping through the internals of an XACML interpereter. Best of all, the compiled code executes in about a tenth the time and space. I'm installing this in a SOA PDP and for release on forge.mil when it stabilizes. The compiled code passes all of the Oasis compliance tests except for ~10 cases that the standard was to vague on to comprehend.
Although I'm convinced this path is more viable than working with raw XACML, I'm not at all sure that either approach will be viable as the problem scales. I'm hoping to discover some domain specific language that would put bring both syntax and semantics down to where real people can work with it. Java's not bad for that but hardly ideal.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What I don't really get is:
"...and when one common language is used, policy management becomes much easier."
"Easier" - compared to what? Who and how have measured this?
Do you suggest that the administrators will have to manage raw XML? If not, does it really matter whether you use XML or anything else? If yes, try to imagine a human being with a living soul inside typing in Notepad something of the following kind:
AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-time"
We have developed our own language for expressing policies in XML in our own time (http://sec.isi.salford.ac.uk/permis/). What we have found out was that NOBODY wants to learn XML just to be able to write our "simple" policies. Note that we even suggested them to use Xeena with DTD of our policy loaded, to make their life easier.
Conclusions? You need a really human friendly tool for writing policies, and humans, apart from those who debug the decision-making engine, don't give a crap for the ENCODING of the policy (XML? ASN.1 BER?).
Now, imagine parsing a string to parsing a definite-length BER - that's earth and heaven! Because in XML you need to _search_ for tags and think about their names, and in BER you instantly get the size of a data block. BER is determined to be space efficient, and XML isn't.
Have you ever considered to have a BER-encoding of XACML? Really, there are only syntactical differences between ASN.1 definitions and XML schema. Encoding policies in XML is no different to encoding policies in BER.
In our own time we have done performance tests. XML is about an order of magnitude bigger and slower than BER. Compare loading an XML policy of 4KB in size to loading ten 400byte-BER-encoded-certificates - almost 1.5 seconds against under half a second with signature verifications on each of the certificates.
Questions:
1. Do you see XACML as a human-friendly language?
2. What priority do you set for a policy editor?
3. Any considerations about BER-encoding of XACML?
Just some of my thoughts as an 'outside observer' i.e. not involved in the XACML definition.
XACML is different to most Access Control definitions because it is an 'open ended' language, i.e. not constrained to an object model (such as roles, attributes and targets). This makes it potentially far more powerful e.g. allowing dynamic and complex relationships to be included in the policy definitions.
In XACML its the PAP, which defines the policies, and presumable have the 'user interface'.
Ultimately any but the simplest construct in XML is not human readable, or readable by most humans. This probably true of any formalisation e.g. COBOL, SQL and other 'natural' programming languages, Mathematical notations or even legal documents.
The point about the OASIS / ebXML process and XML is achieving some kind of consensus. I.E. the drivers are pragmatics / political not purely technical. If the choice of technologies was purely technical then we would be using CMIP, GDMO and ASN.1 / BER or CORBA not SOAP, schemas / DTD and XML etc. for web services, object modelling and encoding. However those earlier technologies only achieved a limited industry consensus (i.e. didn't include you know who).
So do you plan to support XER?
http://www.itu.int/ITU-T/studygroups/com17/languages/X.693-0112.pdf
I am novice to XACML, and I appreciate its extensibility. (Though, I don't see why we have XML-text encoding, and perhaps we could think about XML-binary encoding).
I am not sure how a Role Hierarchy could be expressed in terms of XACML definitions. I simply don't see the means of defining how a policy can define the order of values for a particular attribute. Do you know what XACML mechanism I should look at?
Sorry I've been slow here. In case anyone is still looking for some answers...
Manageability obviously means a lot of things. No, I don't think that XACML is user-friendly, and I certainly don't expect many people will want to work directly with the XML. Do I see tools as a high priority? Definately. I have a (slowly moving) project in this space. If more people wanted to get involved (hint, hint) then it would move faster.
So, given this, why do we claim that a standard, general language helps with management? Well, for one thing because tools are written on top of languages. Even if you don't have to learn the XML tags, you still need to learn something about the sematics of a language, and you need to learn the tools. A single language means you only need to learn these things once.
Another big thing is that XACML makes cross-domain management easier. If different administrative domains are writing policies that need to work together (which is something that XACML is explicitly designed to support), then having a single representation, even if it's only used as an intermediate form, makes this _much_ easier, and lets you do things like infer and reason about the system as a whole. This is really powerful stuff that you can't do if there are myriad different languages floating aound.
Does XACML solve all the problems in this space? Probably not. I'm pretty familiar with PERMIS, and I think there's a lot of cool stuff there. David Chadwick and I have spoken at length about some of the policy and related challenges in these systems, and there's definately more progrtess to be made. I personally think that XACML is a good step towards a more managable system. I would be very interested in hearing your thoughts about this!
FYI, about the XER question, I answered that one in a separate thread. Personally, I like binary encoding schemes provided by ASN.1-related technologies, but I think I'm part of an increasing minority.
seth
Our work started from your premise, with which I emphatically agree. When XACML is judged by the standard of other human-computer languages, it is by far the worst I've ever seen (far worse than COBOL). And only some of its problems can be blamed on XML.
Our first shot at addressing this was to transform XACML to ACE (Attempto Controlled English). This was quickly dropped when we realized ACE has nothing like parentheses for handling precedence issues, and these are very common in XACML policies. Using commas to swap and-or precedence helps correctness, but not readibility.
The next pass was to compile XACML to Java. This worked extremely well. The generated Java code is easier to read than the original XACML (our real goal), and has the added advantage that you can then debug policies directly (instead of stepping through the internals of an XACML interpereter. Best of all, the compiled code executes in about a tenth the time and space. I'm installing this in a SOA PDP and for release on forge.mil when it stabilizes. The compiled code passes all of the Oasis compliance tests except for ~10 cases that the standard was to vague on to comprehend.
Although I'm convinced this path is more viable than working with raw XACML, I'm not at all sure that either approach will be viable as the problem scales. I'm hoping to discover some domain specific language that would put bring both syntax and semantics down to where real people can work with it. Java's not bad for that but hardly ideal.