Approach Taken:I wrote a custom security manager that implements the SubjectSecurityManager and RealmMapping interfaces. I created a custom server configuration for this security manager to be installed.

I then ran the "tests-security-basic-unit" on this server configuration and cleared many of the failing testcases. I am interested in getting the unit tests working because they anyway incorporate tests of permutations and combinations of secured components.

Issues:I have an issue with the configuration that the security manager will use. My first shot was to use properties files (principal to cred, principal to role and principal to callerprincipal). But this is proving insufficient and complex, because of the rich possibilities with the security domain configuration in xml (via module options passed to the login modules).

I am wondering if there are better ways of doing the configuration for the custom security manager.1) XML based configuration.2) Let the config be based on security domain rather than a seperation of principal/creds/roles etc.

If a security manager is going to plugin transparently it has to deal with the existing configurations. That is not likely, so a test relying on a jaas configuration of the principal mapping is not going to work. We need a security manager metadata abstraction that allows for different implementations to function from a general metadata model rather than implementation specific configurations.

------------------------------------------------------The issue is mapping from one configuration format to metadata model that another implementation will use. What has to be possible is initialize a security manager for a given deployments metadata. I don't see that this is a solvable problem in the short term.

--------------------------------------------------------For the jira issue I would simply create custom tests with the new security manager metadata configuration. The issue was not about how to allow anyone to plugin a security manager that works with existing deployments with jboss security manager metadata.

Rather than creating fresh EJBs, I reused the EJBSpecUnitTestCase(that this testcase extends) that defines a lot of combinations of EJBs with various security settings. Then I added a secured weblayer talking to a secured stateless SB test method, to give this JIRA issue an allround exposure.

I guess at the end, servlets, ejbs, JMS connections, Datasource connections are tested for security settings.

The custom security manager makes use of two property files - custom-users.properties and custom-roles.properties for principal/cred and principal/role mappings.