[stellation-res] RFC: Authentication, authorization, ACLs and JAAS.

["Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>]

So... I've been spending a lot of time lately on working out how to
handle access control in Stellation, and how to fix the security holes
that we currently have.

Following advice from others on this list, I've been reading up
on JAAS, the Java Authentication and Authorization Service, to
see if it's something we should be using.

Based on my reading, I'm leaning heavily against using it. I'll
give my reasons, and then I'd like to hear what others think,
particularly if you think I'm wrong, and we should use JAAS.

My arguments against JAAS are all related to complexity. JAAS
is a very complicated, very messy system. Frankly, it's just plain
ugly. But ugliness isn't my main concern: what I really dislike
is the effect that it will have on the usability and extensibility
of Stellation.

First, JAAS has a significant administrative load. To use Stellation, you
already need to be able to install and maintain a relational database
system; anything that adds to that administrative burden is a significant
issue affecting the usability of Stellation.

Second, JAAS interconnects with the Java security manager in 
a fairly deep way.  To use JAAS authentication would mean
making very deep changes to a very wide body of code, inserting
a very large number of wrapper classes to establish credentials
with the security manager.  It will add a very significant amount
of complexity to Stellation, not just in the implementation of the 
necessary JAAS interfaces, but in any code that calls into 
access controlled methods in the repository.

Third, JAAS's interaction with the security manager creates
problems with the extension architecture of Stellation. Stellation
does a lot of dynamic loading and configuration; to use JAAS
with it means that every component needs to be registered as
a codesource, and lots of administrative work needs to be done
to establish credentials for dynamically loaded code. (Just thinking
about writing all the administrative files to make sure that extension 
components providing ArtifactAgent implementations can access
the database gives me the screaming willies.) I think we're talking
about dramatically raising the barrier to entry for extension writers,
and dramatically increasing the complexity of installing extension
components. (You'd have to edit the administrative files every time
you added a new trigger!) .

Overall, I see a lot of added complexity, both in the code and in
administration, but I just don't see a significant payoff. 

(On the other hand, I've learned quite a bit about using
the crytographic capabilities of Java, and I'm seriously considering
using them to improve the security of our communication and 
authentication. Details to follow when I have time. Expect
a writeup of an ACL proposal later today.)

	-Mark

-- 
Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center  
*** The Stellation project: Advanced SCM for Collaboration
***		http://www.eclipse.org/stellation
*** Work Email: mcc@xxxxxxxxxxxxxx  ------- Personal Email: markcc@xxxxxxxxxxx