Hi Oleg,
Remember that IMHO, authentication and principal-to-role
mappings are unrelated activities. JAAS should absolutely be used
for the first, but possibly not for the second (at least I see no
advantage for JAAS, though perhaps no disadvantage either).
Once we decide that we are going to use JAAS for the principal-to-
role mappings, we should have as a primary design goal the ability
to plug-in unmodified third party authentication modules, with a
"role mapping layer" on top. One of the points of JAAS is to allow
for such pluggable authentication, and requiring authentication
modules to perform role mapping themselves would defeat this
goal.
If I understand your summary of Edward Kenworthy's proposal, his
approach would facilitate using unmodified third-party JAAS
modules for authentication. If my understanding is correct, consider
me +1. Otherwise, just ignore me. :-)
-Dan
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]
>
