Hi Scott,
On Thursday 14 December 2000 23:41, Scott M Stark wrote:
> > Moreover, Edward admits that some other services may use JAAS, and they
> > should use the same Subject, but own Principals.
>
> By 'own Principals' do you mean Principals of a class that is specific to
> the service?
Yes.
> I believe that all Principals should be associated with the
> current LoginContext Subject.
>
> > Principal for EJB security should contain a set of roles as its
> > attribute.
>
> Here I don't agree. The roles are a subset of the Principals associated
> with the Subject executing the EJB.
New mapping "EJB security -> JAAS" was born.
Okay, how do you define to which security view the given Principal-principal
or Principal-role belongs?
Either we need Principal.getSecurityView() method, i.e. we go outside of the
public interfaces, or we need different classes for different security views,
which is in general acceptable, but kills the idea of parameterized class
which serves to several security views.
> Neither Subject nor Principal support
> the notion of attributes so you would have to go outside of the public
> interfaces to implement this.
This is what Edward proposes.
>
> > Principal should provide the cache for the security info.
>
> But in JAAS security info is a property of the Subject and is created by
> one or more LoginModules. When a logout is issued against the current
> LoginContext all security info and Principals should be removed from the
> Subject.
Logout never happens. Logout makes JBoss server stateful, which is
undesirable.
> I think your moving too much behavior to Principal which is little
> more than an identity token.
Edward does that, not me :-)
> How does the cache relate to the JAAS
> LoginContext, LoginModule, Subject,
Doesn't relate in Edward's model.
In my model all that entities die after LoginContext.login(), the gathered
security info is put to the cache.
> Refreshable, & Destroyable entities?
Not used.
>
> > 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.
>
> I agree that the current security should be make more consistent use of
> JAAS, but I think we need to enumerate the security use cases JBoss will
> support before getting to this level of discussion. Use case titles that I
> would like to see discussed include:
>
> - Scope of a Subjects security info(Principals, credentials) in the context
> of the various units of deployment: ears, wars, ejbs. How does each level
> introduce the security info revelant for that level?
I don't agree that we should discuss this, because there is EJB security
model which operates with two notions: Principal and role.
What could we change here?
> - Caching and expiration of security info. What is the lifecyle of this
> information and how does it synch with the true source of the info(LDAP,
> JDBC, Kerberos, ...).
I don't see any alternatives to time expiration.
> - Authorization beyond the simple role based model. Is there going to be
> support for modifying the Java2 security policy for the current Subject.
> The issue is are the AccessController.checkPermission() calls a function of
> the Subject as per JAAS or are they the user independent CodeSource based
> view supported by Java2 < JDK1.4?
Let's don't mix two models. Let Sun guys think how to converge EJB security
model and JAAS. I don't think that we should add JBoss-specific EJB
authorization.
Thank you for your feedback,
Oleg
