I am moving towards an Application Service Provider (ASP) model for my applications. It will reduce redundancy, increase time-to-market, decrease maintenance, and increase capacity and flexibility.
In the COM world I developed application independent base classes that brought RAD to fruition. One of the features was complete role-based security. Modules, used to define privileges, could represent anything the developer wanted, from tables/classes to business processes or functional groups.
The code was literally shared by multiple projects, minimizing maintenance. The Rose models design shared the base data classes as well. However, since each application required a distinct copy of the role based security data, there was still work to setup all the database instances, as well as configure each application.
The ASP model I envision would encapsulate the role-based security and integration features so that it becomes a distinct service. This would mean that a single application and database instance of this service would be able to service multiple applications, decoupling the two. To further pursue the ASP model, a single application it will be able to service many domains, simulating distinct instances of an application. The security model will need to support this as well.
Because this will be a separate service, it may or may not be on the same server as the actual application. In order to support redundancy and scalability features, an application also needs to be able to switch to a different instance of the service in production.
This distributed architecture requires versatile configuration options as well as robust transaction management.
For configurability, a deployment descriptor will not suffice since configuration will need to be managed on an instance by instance basis (one deployment descriptor will not suffice, and multiple deployment descriptors will be a pain for a single application.) Additionally configuration needs to be modifiable in the live production environment. This configurability will definitely be accessed by a server administrator, but may also become part of an automated process to ensure application reliability.
Transactions may need to span EJBs across JBoss instances. If the security service happens to be on a different instance, the calling beans will not know because this will be configurable.
JBoss specific questions include:
1> How can we achieve transactions across multiple JBoss instances?
2> How can we achieve such dynamic configurability. Deployment descriptors are undesirable, and I do not want to use a database, because I am trying to configure the way different components access each other, and this should include how the database is accessed. If we view the configurability as a service, it should permit applications to define configurations, like the way we add keys to the Windows registry. Any application accessing that instance should then be able to access the configuration.
In other words, this is not configuration that the container would actually use, although I can see this becoming a standard, and then it might.
3> Davidjencks, you mentioned MBeans. Do you think the role-based security or dynamic configurability can best be achieved with Mbeans? I haven't looked much into JAAS, but it appears to be too tightly coupled with EJB concepts to give the developer absolute freedom when defining privilege mappings, and may not support the ASP model. If these assumptions are right, then this may be worth turning into an Mbean. I would be willing to make it to open-source.
Thanks for your help,
1. The Tyrex transaction manager gives you distributed transactions across multiple jboss instances. Whether slowing everything down with these distributed transactions is a good idea is another question;-)
Also check the clustering implementation in jboss 3.
2.and 3. I'm not entirely sure what you are suggesting. It looks to me as if it related to Scott Starks ideas about security domains and virtual hosts. He discussed these a bit on the jboss-dev mailing list a few weeks back. You might try posting your ideas on that list, it may receive more attention. I'm not that familiar with JAAS, but I think it is not that coupled with ejbs. I think deployment descriptors describing mbean configuration, that can then be modified as necessary at runtime, are the answer to every configuration question;-)
To clarify the domain model, it is a way of decoupling the application needs from the security service capacity.
Modules will belong to a single application, except for global modules, which can be used in any context.
Roles, users, role modules and user roles will all belong to a domain. Since modules are tied to applications (many to one), roles will inherently belong to applications as well. However, for a given application, roles can belong to many domains. The same goes for users and intersecting entities of roles.
This permits, for a single application, multiple domains to exist that isolate users and their privileges. By calling them domains, they are decoupled from the application's actual use.
An application can use domains anyway they see fit. They will commonly be related to organizations, and can have a one-to-one, one-to-many or many-to-one relationship. This will be defined by the application according to its needs.
An example of might be a customer service application that you would host for multiple clients. Each client would represent a separate organization. If an organization has a one-to-one relationship with domains, then each client will have a distinct set of users and roles that they can manage. This permits each client to setup their own security configuration to determine how their users can access the application's features. The domains will also be used to isolate business data, so that one organization cannot see another organization's data.
This is just one example. Actual uses can vary. The decoupled design permits countless scenarios.
Can JAAS handle this?
I don't know enough about jaas to judge, however it looks to me as if your goals are very similar to those of Scott's virtual host/security domain ideas. I'd read his discussions on the dev list and ask there.
By reading this web page:
I think I can confidentally say that J2EE was not designed to adequately support the ASP Model described, or at least with enough confidence to decide to complete the requirements without using J2EE/JBoss security features, and then investigate the options again later. Time is an issue now.
JAAS can handle this. The current utilization of JAAS in JBoss cannot. Its on my todo list to add support for ASP model deployments of applications with multi-domain security.
Its not going to happen before spring 2002.
Ok, thanks. I appreciate this. I'll develop a service without it, and then look into adding a JAAS option next year.
> JAAS can handle this. The current utilization of JAAS
> in JBoss cannot. Its on my todo list to add support
> for ASP model deployments of applications with
> multi-domain security.
Where can I found additional information how it's planned to be done?
> Its not going to happen before spring 2002.
Well, actually I need at least a subset of ASP functionality right know. I plan to implement own JAAS-based login mechanism that will pass a client name along with traditional login/password combination. Later, in EJB code I need a way to obtain client name and hardcode multi-domain functionality in ejb (of course, it's bat design, but it's better than nothing :-)
Can you give me some guidelines how this can be done?
I think, the best way is to extend Principal object to return company name [BTW, what limitations should I take on account to let my modified principal be successfully transfered with ejb invocation?]. Then I need to provide client login module and, possible, extend web-server integration part. Almost sure, that JaasSecurityManager will be affected as well. What else?
Any comments and guidelines are welcome.
Tnx in advance [and sorry for my poor English]