can cluster Subject sessions natively and never need to worry again about how to cluster sessions based on your container environment
if you configure a cluster-capable SessionDAO, the DAO can interact with a clustering mechanism and Shiro's SessionManager never needs to know about clustering concerns
even if you deploy your application in a Servlet or EJB container, there are still compelling reasons to use Shiro's Session support instead of the container's
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
what happens inside Shiro whenever an authorization call is made.
invokes any of the Subject hasRole*, checkRole*, isPermitted*, or checkPermission*
securityManager implements the org.apache.shiro.authz.Authorizer interface
delegates to the application's SecurityManager by calling the securityManager's nearly identical respective hasRole*, checkRole*, isPermitted*, or checkPermission* method variants
relays/delegates to its internal org.apache.shiro.authz.Authorizer instance by calling the authorizer's respective hasRole*, checkRole*, isPermitted*, or checkPermission* method
Realm's own respective hasRole*, checkRole*, isPermitted*, or checkPermission* method is called
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)
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