shiro-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [10/12] shiro-site git commit: Add Realm Authorization section
Date Thu, 22 Jun 2017 20:11:22 GMT
Add Realm Authorization section

Fixes: #21


Branch: refs/heads/master
Commit: e89c14bda2610af98c5ca0805cb5bf64e37fc9fc
Parents: 45947e1
Author: Gautam Singh <>
Authored: Fri May 26 11:17:48 2017 -0500
Committer: Brian Demers <>
Committed: Thu Jun 22 16:10:45 2017 -0400

---------------------------------------------------------------------- | 30 ++++++++++++++++++++++++++++--
 1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/ b/
index 9ed93d0..32f538f 100644
--- a/
+++ b/
@@ -21,7 +21,8 @@
     *   [Disabling Authentication](#Realm-DisablingAuthentication)
 *   [Realm Authorization](#Realm-RealmAuthorization)
+    *   [Role based Authorization](#Realm-RoleBasedAuthorization)
+    *   [Permission based Authorization](#Realm-PermissionBasedAuthorization)
 A `Realm` is a component that can access application-specific security data such as users,
roles, and permissions. The `Realm` translates this application-specific data into a format
that Shiro understands so Shiro can in turn provide a single easy-to-understand [Subject](subject.html
"Subject") programming API no matter how many data sources exist or how application-specific
your data might be.
 Realms usually have a 1-to-1 correlation with a data source such as a relational database,
LDAP directory, file system, or other similar resource. As such, implementations of the `Realm`
interface use data source-specific APIs to discover authorization data (roles, permissions,
etc), such as JDBC, File IO, Hibernate or JPA, or any other Data Access API.
@@ -234,7 +235,32 @@ Of course at least one configured `Realm` needs to be able to support
 Realm Authorization
+`SecurityManager` delegates the task of `Permission` or `Role` checking to [Authorizer](static/current/apidocs/org/apache/shiro/authz/Authorizer.html),
defaulted to [ModularRealmAuthorizer](static/current/apidocs/org/apache/shiro/authz/ModularRealmAuthorizer.html).

+<a name="Realm-RoleBasedAuthorization"></a>
+#[[#####Role based Authorization]]#
+When one of the overloaded method hasRoles or checkRoles method is called on Subject
+1.	`Subject` delegates to `SecurityManger` for identifying if the given Role is assigned
+2.	`SecurityManger` then delegates to `Authorizer`
+3.	[Authorizer](static/current/apidocs/org/apache/shiro/authz/Authorizer.html) then referrers
to all the Authorizing Realms one by one until it found given role assigned to the subject.
Deny access by returning false if no none of the Realm grants Subject  given Role
+4.	Authorizing Realm [AuthorizationInfo](static/current/apidocs/org/apache/shiro/authz/AuthorizationInfo.html)
getRoles() method to get all Roles assigned to Subject
+5.	Grant access if it found the given Role in list of roles returned from AuthorizationInfo.getRoles
+Permission based Authorization
+When one of the overloaded method isPermitted or checkPermission method is called on Subject
+1.	`Subject` delegates the task to grant or deny Permission to SecurityManger 
+2.	`SecurityManger` then delegates to Authorizer
+3.	Authorizer then referrers to all the Authorizer Realms one by one until it Permission
is granted.
+If Permission is not granted by any of the Authorizing Realm, Subject is denied Permission
+4.	Authorizing Realm does following to identify if Subject is allowed to perform an action
or access a resource based on given Permission
+a.	First it gets identify all Permissions assigned to Subject directly by calling getObjectPermissions()
and getStringPermissions methods on [AuthorizationInfo](static/current/apidocs/org/apache/shiro/authz/AuthorizationInfo.html)
and aggregating the results.
+b.	If a [RolePermissionResolver](static/current/apidocs/org/apache/shiro/authz/permission/RolePermissionResolver.html)
 is registered (explicit role), then to get the aggregated Permission based on all roles assigned
to Subject  RolePermissionResolver resolvePermissionsInRole() method is called for all Subject’s
+c.	For aggregated Permissions from a. and b. implies() method is called to checks if anyone
of these permission implied the given permission. The Permission is granted based on WildcardPermission

View raw message