Instead of configuring the ShiroFilter in my web.xml I had the IniShiroFilter configured.
The IniShiroFilter creates a new SecurityManager from the ini file.
This new SecurityManager didn't know about the realm I've added in my EnvironmentLoader, so it didn't have any realms.
I replaced it with the ShiroFilter in my web.xml and all seems to be working now with my CdiEnvironmentLoaderListener.
Shiro support the concept of role inheritance roleA inherits permissions
from roleB
A given realm knows only its roles, but my
application understands the mapping of roles to permissions (or nested
roles). I have a single RolePermissionResolver that ties permissions
to roles
Example:
My security Manager:
https://github.com/sonatype/security/blob/master/security-system/src/main/java/org/sonatype/security/DefaultRealmSecurityManager.java#L63
My RolePermissionResolver
https://github.com/sonatype/security/blob/master/security-realms/security-xml-realm/src/main/java/org/sonatype/security/realms/XmlRolePermissionResolver.java#L47
one option would be to embed the hierarchy of locations in the
permission strings
since you can have any
number of elements separated by colons
Another option would be to create your own Permission instances and
implement the isPermitted() method such that it delegates to
Location.isIn(Location) for permission checks
used
as a base class for JPA/Hibernate persisted permissions that wish to store the parts of the permission string
in separate columns (e.g. 'domain', 'actions' and 'targets' columns)
A Permission represents the ability to perform an action or access a resource. A Permission is the most
granular, or atomic, unit in a system's security policy and is the cornerstone upon which fine-grained security
models are built.
a Permission instance only represents functionality or access - it does not grant it
permissions are immutable and reflect an application's raw functionality
because Permissions represent raw functionality and only change when the application's
source code changes, they are immutable at runtime - they represent 'what' the system can do
by transitive
association, the user 'has' the permissions in their roles
all
Permission checks are relegated to Realm implementations, and only those
implementations really determine how a user 'has' a permission or not
Realm could use the semantics described
here, or it could utilize some other mechanism entirely