Since your code is static (meaning you have a static set of resources that can be secured), I do not understand your requirement for adding security roles aside from increasing access granularity. I could see this requirement in a modular environment, where the code is not static, in which case you would need to support the additional security roles declared by later deployments.
That said, I had to implement something similar, a security system that supports:
- adding (declaring) / removing roles without redeployment;
- associating users to those roles.
I'll describe on a high level of abstraction what I did and hopefully it will give you some useful ideas.
First off, implement an @EJB, something like this:
@Singleton
@LocalBean
public class MySecurityDataManager {
public void declareRole(String roleName) {
...
}
public void removeRole(String roleName) {
...
}
/**
* Here, I do not know what your incoming user data looks like such as:
* do they have groups, attributes? In my case I could determine user's groups
* and then assign them to roles based on those. You may have some sort of
* other attribute or just plain username to security role association.
*/
public void associate(Object userAttribute, String roleName) {
...
}
public void disassociate(Object userAttribute, String roleName) {
...
}
/**
* Here basically you inspect whatever persistence method you chose and examine
* your existing associations to build a set of assigned security roles for a
* user based on the given attribute(s).
*/
public Set<String> determineSecurityRoles(Object userAttribute) {
...
}
}
Then you implement a custom javax.security.auth.spi.LoginModule. I'd recommend implementing it from scratch, unless you know the container provided abstract implementation will work for you, it didn't for me. Also, I suggest you get familiar with the following, if you aren't, to better understand what I'm getting to:
public class MyLoginModule implements LoginModule {
private MySecurityDataManager srm;
@Override
public void initialize(Subject subject, CallbackHandler callbackHandler,
Map<String, ?> sharedState, Map<String, ?> options) {
// make sure to save subject, callbackHandler, etc.
try {
InitialContext ctx = new InitialContext();
this.srm = (MySecurityDataManager) ctx.lookup("java:global/${your specific module names go here}/MySecurityDataManager");
} catch (NamingException e) {
// error logic
}
}
@Override
public boolean login() throws LoginException {
// authenticate your user, see links above
}
@Override
public boolean commit() throws LoginException {
// here is where user roles get assigned to the subject
Object userAttribute = yourLogicMethod();
Set<String> roles = srm.determineSecurityRoles(userAttribute);
// implement this, it's easy, just make sure to include proper equals() and hashCode(), or just use the Jboss provided implementation.
Group rolesGroup = new SimpleGroup("Roles", roles);
// assuming you saved the subject
this.subject.getPrincipals().add(rolesGroup);
}
@Override
public boolean abort() throws LoginException {
// see links above
}
@Override
public boolean logout() throws LoginException {
// see links above
}
}
In order to allow dynamic configuration (i.e. declaring roles, associating users), build a UI that uses that same @EJB MySecurityDataManager to CRUD your security settings that the login module will use to determine security roles.
Now, you can package these the way you want, just make sure that the MyLoginModule can look up the MySecurityDataManager and that you deploy them to the container. I worked on JBoss, and you mentioned JBoss, so this should work for you as well. A more robust implementation would include the lookup string in the LoginModule's configuration, which you then can read at runtime from the options map in the initialize() method. Here's an example configuration for JBoss:
<security-domain name="mydomain" cache-type="default">
<authentication>
<login-module flag="required"
code="my.package.MyLoginModule"
module="deployment.${your deployment specific info goes here}">
<module-option name="my.package.MySecurityDataManager"
value="java:global/${your deployment specific info goes here}/MySecurityDataManager"/>
</login-module>
</authentication>
</security-domain>
At this point you can use this security domain mydomain to manage the security of any other deployments in the container.
Here are a couple usage scenarios:
- Deploy a new .war and assign it to the
mydomain security domain. The .war comes with predefined security annotations throughout its code. Your security realm doesn't have them initially, so no user can log in. But after deployment, since the security roles are well documented, you open the mydomains configuration interface you wrote and declare those roles, then assign users to them. Now they can log in.
- After a few months of deployment, you no longer want users to have access to specific par of the war. Remove the security roles pertinent to that portion of the .war from your
mydomain and no one will be able to use it.
The best part, especially about #2 is no redeployment. Also, no editing XML to override the default security settings declared with annotations (That is assuming your interface is better than that).
Cheers!
I'll be happy to provide more specifics, but for now, this should at least tell you if you would need them.
