On Sun, Jun 8, 2008 at 12:16 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote:
> The reason it is not in place now and hasn't been in 3 years is that > because the vast majority of our community - application and framework > developers - could care less about JAAS - it is a cumbersome, > difficult to understand, quirky mechanism. > +1 to that. Java 2 Security in general is a complete mess. It's an utterly convoluted mosaic, parts of which have been pieced together as its flaws were slowly discovered over time. I've got far too many bones to pick with JAAS to inject into this thread, but top on my list is the fact that it's a complete misnomer: it barely accounts for any kind of AuthZ. At best, it's Java's PAM framework. > > I've given presentations on JSecurity and had many discussions in > private, and I always ask my audience: "How many people have heard of > JAAS?" Maybe 40-50% of the listeners affirm they have. Then I ask, > "how many of you have used the JAAS API or its constructs (permissions > files, etc)?". That number has been consistently around 1-2%. > Question is, what portion of that 1-2% are involved in writing containers? :) > > In fact, JAAS was _the_ primary driving factor in what eventually > became JSecurity: I had to execute a number of security operations > for an application, and the only thing out there was JAAS. I found > myself drowning in their mish-mash of incomprehensible APIs and > obscure VM-level security constructs (which I didn't care about - I > wanted application-level security). I've had a similar situation and have for some time been searching for a coherent API to tie together both system, and application space security with some elegance. This has lead to some of our work on ApacheDS and Triplesec [0] at Apache Directory. Although we might not have the whole picture yet, we do see some synergy between protocols like Kerberos, LDAP and general application security. After all, at some point, applications are dropped into environments and thats where we see most frameworks loosing some of their elegance. As I said, I can't say we have the full picture yet, but hopefully with JSecurity in the family we can round out that picture better. SNIP > > Finally, although not necessarily our initial intentions, I think it > would be amazing if JSecurity could be a model for a new JSR that > could supplement or replace what JAAS is today. I don't know if that > will ever happen, but if we as an ASF community desire it, then I > think it would be a great idea for further discussion. > That would be wonderful but we don't need the JCP to bless a coherent API. The user community will do that for us. "Build it [well] and they will come", and eventually it will become the status quo. The JSR thingy is just sprinkles on the frosting. I've been on he hunt for a solid RBAC API that fits well with Java 2 security, while being simple, and easy to use for application developers for some time now. At the same time I've wanted it to have enough granularity to be able to expose policies expressed in SAML/XACML. I've tried designing one several times, and found several shortcomings after looking at integrating it into the big picture. Hopefully something worth while will emerge soon. That's my technical hope for JSecurity, which eventually I'd like to roll into Apache Triplesec. My hopes for this podling and its community are independent from my technical aspirations and so the community can still succeed where the technical aims may fail. Hopefully though we can kill many birds with one stone. Alex P.S. this my AuthZ bible [1]. ------- [0] - http://directory.apache.org/triplesec [1] - http://www.amazon.com/Role-Based-Access-Control-Second-Ferraiolo/dp/1596931132
