> The actual implementations of mappings would be MBeans whose
> names would be specified in the jboss container configuration.
> This would allow mappings to use various persistence
> mechanisms: an XML file saved in the EJB jar (like JAWS O/R
> mappings), or a database, and would allow the mappings to be
> edited at runtime based on any appropriate mechanism--a third
> party application, JMX, etc. It would also allow mappings to be
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.
Say that we decide to change the add a user to the role "admin" in a
application.
How does the Realm get updated? Can we do it runtime, no redeploy? Is it
transparent to the container? the application? can we synchronize access to
this security resource while we tune it and change it? What interface are
you talking about? can you describe it? yes....
For the rest I am no security expert...
marc
> reused when appropriate, simply by specifying the same MBean in
> the container configuration. This will help the potentially common
> case where EJBs roles and permissions are configured according
> to consistent company-wide standards. It's possible that only a
> single mapping MBean instance would be necessary for many
> uses. (An ASP would obviously need to register many mapping
> MBeans. These would probably point to various database tables.)
>
