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:20 UTC
[08/12] shiro-site git commit: Minor formatting changes for #21
Minor formatting changes for #21
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/5a9931e9
Tree: http://git-wip-us.apache.org/repos/asf/shiro-site/tree/5a9931e9
Diff: http://git-wip-us.apache.org/repos/asf/shiro-site/diff/5a9931e9
Branch: refs/heads/master
Commit: 5a9931e92e6eca91da2e4b86c2970bf1cf1aaec5
Parents: 05ac774
Author: Brian Demers <bd...@apache.org>
Authored: Thu Jun 22 16:09:25 2017 -0400
Committer: Brian Demers <bd...@apache.org>
Committed: Thu Jun 22 16:10:45 2017 -0400
----------------------------------------------------------------------
realm.md.vtl | 25 +++++++++++++++----------
1 file changed, 15 insertions(+), 10 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/shiro-site/blob/5a9931e9/realm.md.vtl
----------------------------------------------------------------------
diff --git a/realm.md.vtl b/realm.md.vtl
index 32f538f..5a5db97 100644
--- a/realm.md.vtl
+++ b/realm.md.vtl
@@ -23,6 +23,7 @@
* [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.
@@ -248,18 +249,22 @@ When one of the overloaded method hasRoles or checkRoles method is called on Sub
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
+<a name="Realm-PermissionBasedAuthorization"></a>
+#[[#####Permission based Authorization]]#
+
+When one of the overloaded method `isPermitted()` or `checkPermission()` method are 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 of 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 the following in order to check if a Subject is permitted:
+
+ 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.
-When one of the overloaded method isPermitted or checkPermission method is called on Subject
+ b. If a [RolePermissionResolver](static/current/apidocs/org/apache/shiro/authz/permission/RolePermissionResolver.html) is registered, it is used to retrieve Permissions based on all of the roles assigned to Subject by calling the `RolePermissionResolver.resolvePermissionsInRole()`
-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
+ c. For aggregated Permissions from a. and b. the implies() method is called to check if any of these permission are implied the checked permission. See [WildcardPermission](permissions.html#Permissions-WildcardPermissions)
#lendAHandDoc()