On 27 Jun 00, at 9:11, marc fleury wrote:
Hi Marc,
The MBean must make the following interface available to the
security infrastructure; the application server has "don't care"
semantics for the implementation:
public interface RealmMapping
{
public boolean doesUserHaveRole( Principal principal, Set
roleNames );
}
>
> Say that we decide to change the add a user to the role "admin" in a
> application.
> How does the Realm get updated?
Depends on the implementation. For instance, a RealmMapping
may store information in database tables, which could be updated
via SQL inserts. The Realm might read the information from the
database for each Principal. (= bad performance, which is why I
talked about a cache for this information. The cache could expire
after a certain amount of time, allowing the new information to be
read.) A different RealmMapping implementation may read the
Principal/ role mappings from an XML file and store them in
memory; you might have to redeploy the application to update the
information. (In fact, the persistence mechanism is one of two
primary ways in which RealmMapping implementations will differ.
The other difference is how or if they expose management
functionality.)
A RealmMapping might get updated by a standalone client
application (e.g. by accessing a database), or it might get updated
by a client application that connects to the RealmMapping
instance on the server (e.g. through a management application).
How the Realm gets updated is independent of any other
component of the application server.
Of course, our security infrastructure will include some specific
RealmMapping implementations. I think probably we should
provide two persistence mechanisms for the mappings: database
tables and XML files. The database tables should probably be
updated through JMX instrumentation of RealmMapping MBeans, if
possible. The XML file would be created by a standalone
application (e.g. an EJX plugin).
> I am very interested in hearing the JMX runtime interface to edit
the
> rights.
> From what I understand you would specify such an interface for
other
> instrumentation tools to plug in.
I'm not quite sure of the mechanism to do this, because the
mapping is a one-to-many-to-many (many principals have many
roles.) There are two mechanisms to represent complex data in
the JMX spec: javax.jmx.openmbean.CompositeData and
javax.jmx.openmbean.TabularData. I'm hoping that I can expose
the mappings as these datatypes, and leave the details of the user
interface to the management applications. My experience with
JMX is pretty limited. Am I wrong?
> Can we do it runtime, no redeploy?
Depends on the implementation. Certainly for the RealmMapping
with the database persistence mechanism, you should be able to
do this.
>Is it
> transparent to the container?
Yes.
> the application?
Yes.
> can we synchronize access to
> this security resource while we tune it and change it?
Sure. The implementation could have a many readers/ one writer
synchronization mechanism for mapping information. Why would
you want to do this? To me, it's more important that security
changes be reflected immediately. If we've revoked someone's
rights, we don't necessarily want them to finish their current
transaction. :-)
Thanks,
Dan
