incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [PROPOSAL] Incubate JSecurity Project
Date Mon, 09 Jun 2008 05:05:58 GMT
On Sun, Jun 8, 2008 at 12:16 PM, Les Hazlewood <> 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.


> 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.


P.S. this my AuthZ bible [1].

[0] -
[1] -

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message