You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@shiro.apache.org by bd...@apache.org on 2017/06/22 20:11:22 UTC
[10/12] shiro-site git commit: Add Realm Authorization section
Add Realm Authorization section
Fixes: #21
Project: http://git-wip-us.apache.org/repos/asf/shiro-site/repo
Commit: http://git-wip-us.apache.org/repos/asf/shiro-site/commit/e89c14bd
Tree: http://git-wip-us.apache.org/repos/asf/shiro-site/tree/e89c14bd
Diff: http://git-wip-us.apache.org/repos/asf/shiro-site/diff/e89c14bd
Branch: refs/heads/master
Commit: e89c14bda2610af98c5ca0805cb5bf64e37fc9fc
Parents: 45947e1
Author: Gautam Singh <gk...@hotmail.com>
Authored: Fri May 26 11:17:48 2017 -0500
Committer: Brian Demers <bd...@apache.org>
Committed: Thu Jun 22 16:10:45 2017 -0400
----------------------------------------------------------------------
realm.md.vtl | 30 ++++++++++++++++++++++++++++--
1 file changed, 28 insertions(+), 2 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/shiro-site/blob/e89c14bd/realm.md.vtl
----------------------------------------------------------------------
diff --git a/realm.md.vtl b/realm.md.vtl
index 9ed93d0..32f538f 100644
--- a/realm.md.vtl
+++ b/realm.md.vtl
@@ -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 Authentica
Realm Authorization
-------------------
-TBD
+`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 call.
+
+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 roles.
+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 rules
+
#lendAHandDoc()