Yeah, I didn't mean to offend. We've all worked on software whose architects didn't make the best decisions. I've recently inherited such a product suite so I'm kind of on the offensive - but mostly yeah I'm just making the point that virtually any well-designed LOB software architecture should include XACML, and lack of apparent interest is more reflective of how slowly good architectural design has moved through the community. But microservices are on the rise, architectural decoupling is growing, the modern auth stack is finding growing adoption, and XACML's time is coming.
Of course, we need better tooling. And boy do I have ideas there. But first, we need the core product to work well. Also, I did get it running. I never got it to work right (lack of knowledge and documentation on my side), but I got it compiled and running in jetty. It's got to be possible to do a release soon. The biggest changes had to do with moving away from Ivy and moving toward Maven, and then making necessary changes to get it to run in a standard servlet server since the att team doesn't use a standard servlet server (I think they use some embedded jetty solution). On Feb 8, 2016 4:30 PM, "Carlos Perez" <[email protected]> wrote: It’s only my opinion but I do think David makes some good points… One point in particular is just the lack of devs really even knowing what XACML is, or what it’s for. I myself didn’t know what it was about until about 2 years ago, and only because I have a particular interest in security and access control did I go out in search for an alternative to some other XACML implementations. Some that would not share even the slightest amount of information before they get you into a hour+ long phone call to “find out your needs”. That said, I think it’s still a little harsh to say that I have been writing software that “sucks”, but I’m going to take that with a grain of salt and say it was for dramatic effect. =o) All that said, one major item of interest to email from David was his mention of a PR, and then I remembered this… https://github.com/apache/incubator-openaz/pulls Now I’m not sure if this counts as activity, nor will I even try to qualify this as a community, but there are now 3 pending PR’s dating back to December 3rd, 2015 that’s… Well it’s something. Anyway, I know the AT&T group has been a little incommunicado but they are the best people to put SOME kind of docs put there, even a video of how to download/setup/and run would be a start. I know the lack of docs has been my biggest weakness but so far I’ve been trying to learn via YouTube videos and reading what I can of the spec (good bedtime reading BTW, knocks you out quick). I know that Colm (I think it’s Colm) did some write up recently which was an attempt to show OpenAz used in an app, it was lite but still a start. Any who, this emails gotten a bit long so I’m going to cut it off here, but I would like to see David’s port of the AT&T admin portal (I think that will really help), and if possible could Colm reply back with his write up?? Regards, Carlos On 2/8/16, 5:02 PM, "David Ash" <[email protected]> wrote: >I have submitted a pull request for my port of the Admin interface. I'll >check what other changes were made and see what else I can submit. > >BTW, although I had previously worked for AT&T, including working on >software that interacted with AT&T's original XACML engine, I no longer >work for AT&T. My interest in this project came from my desire to have a >RESTful API for XACML authorization, I found this project via Google, and >my contributions to this project are my own. In this regard I am a truly >independent contributor. > >On Mon, Feb 8, 2016 at 2:42 PM, David Ash <[email protected]> wrote: > >> I think it hasn't seen much activity over the past two months because >>it's >> been a holiday season. I know most of the AT&T people take most of >> December off (once upon a time, I was one). >> >> It has a lot of work to be done before it's functional and even remotely >> mature, and we're not going to see a lot of outside interest until it >>gets >> there. >> * The Admin part is crucial, and it hadn't even been ported over (I >>ported >> it myself, still need to fork in github and do a pull-request). >> * There's a shortage of documentation. To the point that it's unusable. >> * It's complicated enough that its difficult to come up with the >> documentation. >> >> Now, sure there seems to be a shortage of interest but I say give that >> time. XACML is not a thing of the past, it's still part of the future. >> Organizations and software developers are still slowly moving to XACML >>-- >> it is the best authorization solution in existence to my knowledge, and >> fits nicely into a modern auth stack with SCIM, JSON Identity Suite, >>OpenID >> Connect, and OAuth. ( >> http://www.slideshare.net/nordicapis/1415-twobo-nordicap-istour >> ). Most developers still aren't using an external authorization >>solution >> because they are building highly-coupled monolithic software that sucks. >> And honestly, there aren't a lot of other free open source options. The >> only alternative I see that is any good is WSO2's Identity Server >>(which is >> vastly superior to this product, but hey that's an opportunity in some >> ways). If this project really succeeded, it would at least allow >> developers of open source systems to build better, more modular >>software. >> >> The main problem I see is that AT&T still has most of the knowledge and >>is >> able to put very little effort behind it. We need Pam's team to write >>up >> some high quality documentation (particularly for the API's) and release >> that information. >> >> The other problem I see is there's kind of a lack of vision as far as I >> can tell. We need someone in the lead that has the time to craft a >>vision >> for what this product should really be. When you look at WSO2's >>Identity >> Server, you immediately start realizing the possibilities -- things that >> this project haven't even touched yet. >> >> >> Thanks, >> >> David Ash >> >> >> PS. I'll put in a pull request for my port of the Admin interface. >> >> >> >> On Mon, Feb 8, 2016 at 9:59 AM, Emmanuel Lécharny <[email protected]> >> wrote: >> >>> Le 08/02/16 16:53, Carlos Perez a écrit : >>> > Hi guys, >>> > >>> > While I completely understand the reasoning for the discussion to >>>retire >>> > OpenAXZ, and to be completely honest I was surprised it took this >>>long), >>> > it would be a real shame to see it just fade away into oblivion. >>> >>> I Agree. >>> >>> > >>> > That said, what does happen when a project never makes it to a TLP? >>> >>> From Apache POV, not a lot. We just shut down the mailing lists, and >>> close the repos (no more writes allowed). >>> >>> >>> > Does >>> > it have a chance to be resuscitated later if it is deemed worthwhile >>>and >>> > has more interest? >>> It's always a possibility. A very remote one, I have to say. The fact >>> that in almost 2 years the project hasn't be able to attract any new >>> contributors, and that almost no activity has been seen from the >>>initial >>> contributors make it unlikely that the project could make a come back. >>> >>> In 10 years, I haven't seen that happen. Not once. >>> >>> >>> > Does the license revert back to AT&T? >>> >>> Good question. I can ask [email protected] about that. The fact that it didn't >>> make it to a TLP might be relevant. For TLPs, the code base has been >>> granted to The ASF and remains so, same for the name. >>> > >>> > XACML is a complicated spec and I can¹t say that I fully understand >>>it >>> > yet, but I think it solves a real problem (I just regret not having >>>the >>> > time personally to help push it along). >>> >>> That's the main issue : the fcat that it's a complex code base might be >>> intimidating for many of the potential users. But IMHO, would it be >>> really a critical brick of many IT systems, it *would* have attracted >>> developpers. That raises the question of XACML as a useful technology. >>> It as been around for more than 10 years now, and I'm not sure that it >>> captured a lot of interest. But that may be just me... (and I *think* >>>it >>> could have been a big hit years ago. Not so sure nowadays.) >>> >>> Thanks ! >>> >>> >> This e-mail message and any attachments to it are intended only for the named recipients and may contain legally privileged and/or confidential information. If you are not one of the intended recipients, do not duplicate or forward this e-mail message.
