Part two of the reply to Oleg's follow up comments.
> > 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?
>
If the EJB Principal/Role notion can be implemented using JAAS you have a
model that also supports any permission check of the form:
AccessController.checkPermission(new MyPermission(...))
This combined with access to the current Subjects Principals & creditials gives me
a security model that can handle any type of security checks. This includes permissions
that are a function of the bean which is something the current EJB model cannot handle.
> > - 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.
>
The issue here is that each LoginModule is responsible for the Principals and
crenditials
that it associates with a Subject. If I have an LDAP based LoginModule it could be
watching for LDAP v3 event notifications concerning user addition/removal as well as
password changes. Likewise a PKI based LoginModule that represents Principal identities
as X509 certs could be watching for certificate revocations. The natural place for any
cache policy is the layer that creates that cached information. In JAAS this is the
LoginModule
layer. Does the application server even need to worry about this?
> > - 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.
>
Ok, that's a fair position for now. However, my stance is that the EJB model could
be implemented using JAAS and in so doing provide a framework that extends to
support all the security requirements of a J2EE server. The extensible JMX based
framework used by JBoss has the drawback of having to reconcile N-modules
custom security policies unless there is a common security representation.
