More flexible roles?

[kmcclosk]

Our users are placed into groups similiar to the following:

group-subgroup0-editor
-> joe
-> bill
group-subgroup0-admin
-> mike
group-subgroup1-editor
-> joe
group-subgroup1-admin
-> paul

I can't figure out how would you handle this type of grouping with declarative security. With declarative security, I can restrict a user from calling a method unless they are an "admin" or "editor", but I need something more granular that takes into account the subgroups. I don't know the subgroup until the user makes a web request. Further, new subgroups are created on a regular basis.

Can I use wildcards for roles, like group-*-editor? Or do I have to use aspects to provide more programmatic method call security?

Thanks

[niwhsa]

You cannot use wild cards in ejb-jar.xml for declarative security.
Option 1)
However, you can install a security interceptor with your application that can check these roles. The interceptor gets called before the ejb and you can handle all checking there. The interceptor gets access to the principal, roles, ejb and the ejb method that is being invoked. This is enough info for you to program fine grained security

Option 2)
Another way would be to check the users roles in ejb interface methods and not proceed if the user has insufficient roles (throw security exception). However, this logic needs to be impl'ed in every method.

Advantage/Disadvantage

1) Option 1 is clean and simple and your ejb code is not aware of security logic
2) Option 1 is jboss specific and you will have trouble migrating to other app servers that dont allow this flexibility (remember jboss is very very flexible and allows you to do lot more customization than other servers)

3) Option 2 should work on any app server!!

What shud you choose

Choose option (2) if you need portability or choose (1) otherwise