Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Date: Tue, 2 Nov 2004 18:58:57 -0500 (EST)
From: Aaron Mulder <ammulder@alumni.princeton.edu>
To: dev@geronimo.apache.org
Subject: Security Refactoring
Message-ID: <Pine.LNX.4.58.0411021847340.14620@saturn.opentools.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

	I think I'd like to propose some refactoring of the current 
security realm, configuration entry, and login module structure.  This is 
related to issues 424, 410, 409, 422, and 419.

	I'd like to generalize the security realm implementation, and make
it take a more arbitrary/configurable list of login modules.  That would
let you implement features like auditing and lockout as login modules, and
hopefully entirely encapsulate Kerberos, SQL, and File access as login
modules.  Then you pick login modules from here and there and pop them
into a general security realm, and off you go.  It makes it all much more
modular, and lets us reuse the same features across realm types without
needing to separately update multiple security realm implementations to 
handle them.

	While I'm in there, I'd like to make the ConfigurationEntry 
process more automatic (since every realm needs one), and remove some of 
the redundant configuration options for login modules.

	I'm not sure how best to proceed.  I assume that Alan (and perhaps
others) are going to want to look this over before it goes in.  The
easiest way would be to put a code proposal together -- I'm not sure if a
branch or a giant patch would be easier -- it seems like they both have
disadvantages.  I could also try to write it up in sufficient detail for
someone else to code, but that feels like it would just introduce
additional delay.  Any thoughts on this?

Thanks,
	Aaron