geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: J2EE security
Date Tue, 12 Aug 2003 13:27:36 GMT
JAAS is required for compliance.  JAAS CallbackHandlers are required for J2EE client authentication
and JAAS Subjects are an integral part of the J2EE Connector Architecture.  The Java Authorization
Contract for Containers spec is also built on JAAS -- also required for compliance.

It's not really an open issue or up to our discretion; more one of those just get it done
things.

-David

On Tue, Aug 12, 2003 at 10:02:39AM -0700, Edward Flick wrote:
> OK, I like the reference authorization system in place
> in JAAS.  But the reference JAAS implementation has
> shortcomings pertaining to remote Authentication:
> 1) By nature, it is designed to populate a local
> Subject (and Subject(s) are declared final so we can't
> just implement a RemoteSubject and use their
> framework).
> 2) JAAS is more or less designed to run in its own
> bubble.  The only semi-efficient way to pass in a
> method for the LoginModule to actually do something
> besides just load a Subject with dummy values for a
> remote Authenticator to process is to pass in a
> Callback with something like an ObjectOutputStream or
> something like that.  Not to say that this would be
> the worst way to do it, but if you are going to be
> writing LoginModules that try to workaround
> limitations inherent in the framework, then maybe you
> should be questioning the frameworks feasability for
> that particular task
> 3) The standard LoginModule approach could be used to
> populate the Subject with dummy principals and
> credentials (which are not allocated Permissions) and
> then have the remote authenticators read from the
> Subject to find what to authenticate as.  But this has
> the problem that when you actually do the login you
> don't immediately get Exceptions thrown back at you at
> failed login attempts, because the actual loggin in is
> deferred until later.
> 
> This is why I like SASL so much.  To the end user you
> actually use it much the same way as you interact with
> LoginContext/LoginModules you just pass-in a few
> parameters including a Map of params, protocol name,
> and a CallbackHandler to createSASLClient and you have
> a ready made authenticator, just waiting to negotiate
> remote authenticity and data confidentiality and
> integrity wrappers.
> 
> I'm very pro-SASL.  I don't know if you can tell. 
> Also, after the Authentication phase is complete.  I
> think we should pass the Subject (on the remote end)
> that is authenticated into a CredentialDelegator which
> should load up any extra credentials/principals (based
> on the current set of principals assigned to the
> Subject) from an LDAP server/AD or from a local XML
> file or from whatever depending on how you have it
> defined as to where to pull its info from.  This way
> you can recursively import added
> principals/credentials to the authenticated Subject. 
> This is what I'm working on for the AltRMI (a very
> good alternative/easier/more logical RMI
> implementation) project, also in incubator.  What do
> you guys think?
> 
> =====
> Edward Flick
> Enterprise Applications Designer / Database Administrator / Web Administrator
> CDF, Inc.
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com

Mime
View raw message