Slashdot Mirror
Sun Releases Open Source XACML Language
LowneWulf writes "An InternetNews.com article mentions that the OASIS standards group today ratified the Extensible Access Control Markup Language 1.0 specification. But even better, Sun Microsystems Labs has backed this up with an open-source version in Java on Sourceforge."
YAUML (Yet Another Useless Markup Language) should become more commonly used around here.
How can a language be open source? A language doesn't need source; it's a syntax. Compilers need source, not languages. 'Open Source Language' sounds like more hype to me. I may be stupid, but I don't know of any truly open source implementations of the Java that this 'Open Source Language' is in (Last I checked, Sun had a pretty strict licensing scheme going for Java implementations)
using namespace slashdot;
troll::post();
there are those who disagree, but those whose jobs require complexity, it is a step towards easier integration. Microsoft should just go with the architecture Oasis has laid out for ebXML and dump their piece of junk which originally had no concept of coreography.
How can a language be open source?
I consider a language to be "open source" if it has a reference implementation available to the public as OSI Certified(TM) open source software.
Will I retire or break 10K?
Does it ever occur to Sun that Java is not the answer to all problems? That maybe, just maybe, an implementation in C would be more generally useful as a reference implementation?
I know more Java programmers than C programmers
All industry software projects I'm involved in are in
HINT: its not C and its not C++.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
This seems to be a mostly server-side technology, and Java is generally accepted on the server, so I don't see it as a bad thing that it's in Java.
.NET or Java is a very negative thing, because many clients will either not have the necessary runtimes, or will have very outdated versions of them. Both .NET and Java weigh in at at least 10mb, and that will definitely hurt deployment of any technology.
However, if this technology requires the client to implement some complex authentication stuff, you've got a problem. Exclusively tying your reference implementation to 'weighty' technologies like
using namespace slashdot;
troll::post();
Hey, it's just a prototype/demo application that conforms to the standard. If you don't like it write your own in your favorite language (and feel free to borrow as much as you like from the source code).
Besides, this kind of thing would typically be used in a web application environment, where C typically is not the language of choice (mostly because core dumps are not acceptable in a server environment). And guess what, sun happens to produce some of the most popular tools and techniques for web applications (mostly Java based).
Jilles
* One standard access control policy language can replace dozens of application-specific languages
* Administrators save time and money because they don't need to rewrite their policies in many different languages
* Developers save time and money because they don't have to invent new policy languages and write code to support them; they can reuse existing code
* Good tools for writing and managing XACML policies will be developed, since they can be used with many applications
* XACML is flexible enough to accommodate most access control policy needs and extensible so that new requirements can be supported
* One XACML policy can cover many resources; this helps avoid inconsistent policies on different resources
* XACML allows one policy to refer to another; this is important for large organizations, for instance, a site-specific policy may refer to a company-wide policy and a country-specific policy.
Before someone else rants about copy protection, find out what it is before you start typing. I'm guitly of it in the past, but this is a useful language will real benefits.
Does it ever occur to Sun that Java is not the answer to all problems
Did it occur to you that Sun would write the code to match whatever use fits THEM the best. The fact that they then turn around and make the code OS is a gesture on their part. Did you think they sat around and said "hey, lets write an implementation of this for the masses"? Nope, their needs came first, as it should be.
The requirement of having robust access control (beyond simple enter your name and password) is not very common outside the corp. world. So those who've not had to deal in that code would not fully understand how big of a deal that this markup language CAN be (assuming it's adopted, robust, etc, etc). This is definitely one of those areas where "everybody rolls their own", or worse, they dumb down their access control to fit things like directory services and the ilk, that were never intended to do what this is trying to.
Funny how in many posts this has degenerated into either "we don't need no more stinkin languages" or "Sun/Java sucks, yadda, yadda".
Intercal? BrainF*ck? Fundies? Well for god's sake man, do tell!!
Like so many other "XML-based" standards, XACML is horribly constrained by the lack of general logical or procedural primitives in XML. As we all know, XML is not a programming language - it was never intended to be computationally complete - yet there seem to be a neverending stream of attempts that effectively try to turn it into one.
It is a fundamental mistake to try to shoehorn semantics which will generally include logic - such as an access control decision - into a language which has no support for them. While XACML "is not intended to form the basis of an authorization decision by itself" it must of necessity include the means to combine and modify rules - hence requiring logical operators which of course have no standard representation in XML.
The specific result is that each attempt to use XML for anything other than the simplest semantics (SOAP, Schema, XSLT, JSP...) must invent its own representations of operators, variables, modules and so forth.
The general result is one unholy mess. We, the poor bloody coding infantry, have to face learning a dozen or more ways of representing the same fundamental concept in a multitude of languages, each supposedly specialized for a narrowly-defined task, but in reality incorporating almost-but-not-quite-all the features of a general purpose language. XML's ugly syntax becomes the least of our problems - that can always be hidden by visual tools or 'generators', but no tool is likely to be able to reunite fundamental concepts fragmented into so many different representations.
Standards such as these do not represent progress, they represent a growing mass of redundancy that one day will have to be refactored into more coherent form. Anyone who studied LISP, or some other language capable of representing the popular data and programming paradigms (logic, procedural, declarative...) will be aware that common ways of representing such semantics have been known for decades. The fact that the practice of XML continues to ignore such basic prior art is an extraordinary indictment of the state of our industry today.
I welcome any explanation from the individuals or organizations concerned as to what obliged them to make yet another idiosyncratic elaboration of the generally incoherent and unusable body of XML specifications.