shiro-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bdem...@apache.org
Subject [08/12] shiro-site git commit: Minor formatting changes for #21
Date Thu, 22 Jun 2017 20:11:20 GMT
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 <bdemers@apache.org>
Authored: Thu Jun 22 16:09:25 2017 -0400
Committer: Brian Demers <bdemers@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()


Mime
View raw message