I am trying to mentally map Java EE 6 security concepts of groups, users and roles to the Apache Shiro‘s concepts of roles, users and permissions and my understanding is that they are incompatible.
Reading through the Java EE 6 security tutorial it seems that the model is too restrictive: groups are configured on a per-server, not per-application, basis which really leaves us with only two flexible concepts to express the authorization mechanism: users and roles, existing in a simple 1-to-N relationship. In contrast Shiro’s model of roles, users and permissions is a lot more dynamic since it enables one to hardcode permissions in the annotated code and modify the mapping of roles to permissions at runtime as things change or as new roles are introduced. I don’t see how one can do the same with container-managed authorization as per the Java EE 6 model.
Is my understanding correct? Cause that would imply that one can’t really go very far with container-managed authorization.
They are not compatible and I think that the designers of the Java EE security got it wrong as the terminology seems to be off with regard to ROLES.
From experience I know that providing access control based on ROLE (which is suggested in their documentation) just causes problems down the road when you want to open a capability to other groups/roles. Permission based access mapped back to roles (or groups) seems to work the best because its a remapping exercise at an abstract level rather than a recode/re-annotate one.
I can see how you’d be confused about the Java EE security model. I’d suggest taking a closer look at Shiro and how it has modeled application level security. Les Hazelwood, the creator of Shiro, wrote a blog about RBAC that makes a lot of sense for applications that need fine grained control even down to the instance level.