Hi Dan,
On Thursday 14 December 2000 22:02, Dan OConnor wrote:
> If I understand your summary of Edward Kenworthy's proposal, his
> approach would facilitate using unmodified third-party JAAS
> modules for authentication.
As well as "my" approach - with it you may perform authentication by one
LoginModule and role mapping by another.
Edward
1) moves role mapping from LoginModule to Principal
2) makes authentication to be performed exactly once.
> If my understanding is correct, consider
> me +1. Otherwise, just ignore me. :-)
Dan, I'll count you +1 when you will give me another reason :-)
I aswered to your argument about third-party JAAS modules during our old
discussion, you have just forgot that :-)
Regards,
Oleg
> On 14 Dec 00, at 21:12, Oleg Nitz wrote:
> > Hi All,
> >
> > Dan, Rickard, I ask you to read this message, it runs about redesign of
> > JAAS security stuff, proposed by Edward Kenworthy.
> > Edward, please, read the following and correct me if I retell your ideas
> > incorrectly.
> > First of all, I'd like to remind the current approach.
> > LoginContext and Subject are created once per pair <user, security view>.
> > This Subject serves solely for needs of EJB security service, other
> > services shouldn't touch it.
> > This makes possible to put security info to the cache and drop it at any
> > moment.
> > Edward proposes to create LoginContext and Subject once per user, and
> > then to call a sequence of LoginModules that would add Principals, one
> > per security view.
> > Moreover, Edward admits that some other services may use JAAS, and they
> > should use the same Subject, but own Principals.
> > Principal for EJB security should contain a set of roles as its
> > attribute. Principal should provide the cache for the security info.
> > Subject should exist until shutdown of the server.
> > Edward's approach looks attractive and more in spirit of JAAS then the
> > current one, I confess this.
> > But it implies that all Principals that are needed for all security views
> > and for all other services must be created during LoginContext.login().
> > This yields some overhead.
> > In order to minimize it we should make Principal just a facade, which
> > does nothing on creation and takes few memory, and then loads security
> > info lazily, by request.
> > Okay, this should work.
> > But then almost all JAAS stuff should be refactored... :-(
> > All role mapping stuff should be moved from LoginModule to EJBPrincipal;
> > auth.conf should contain only one application entry "other";
> > Principals should have method "getSecurityView()" to distinguish them.
> > We can have one standard LoginModule which accepts the name of the
> > Principal implementation class as a parameter, creates instance and adds
> > to the Subject. To add new authentication algorithm JBoss user writes new
> > LoginModule (which doesn't have to add any Principals).
> > To add new role mapping algorithm JBoss user extends EJBPrincipal and
> > implements methods for reading bean principal and set of roles.
> >
> > Comments?
> >
> > Oleg
> >
> > > >On Wednesday 13 December 2000 10:49, Kenworthy, Edward wrote:
> > > >> Hi Oleg
> > > >>
> > > >> Hmm thinking about this more I am not sure that this would work.
> > > >> Credentials are attached to Subject. And instances of Subject can be
> > >
> > > shared
> > >
> > > >> across many applications (JAAS spec).
> > > >
> > > >Hey, JBoss is an APPLICATION SERVER, so I guess it should have more
> > > >permissions than all other applications ;-)
> > >
> > > Indeed, however perhaps I should have said services. A single instance
> > > of Subject can be shared across jBoss, an Oracle server, an MQ server
> > > etc etc. jBoss can't assume it owns the Subject, in fact what it knows
> > > it that it doesn't own the Subject.
> > >
> > > >Regards,
> > > > Oleg
> > >
> > > Edward
> > >
> > >
> > > --
> > > --------------------------------------------------------------
> > > To subscribe: [EMAIL PROTECTED]
> > > To unsubscribe: [EMAIL PROTECTED]
> > > Problems?: [EMAIL PROTECTED]
