Merge remote-tracking branch 'origin/pr-16'
Fixes: #16
diff --git a/architecture.md.vtl b/architecture.md.vtl
index d5c309b..44c3819 100644
--- a/architecture.md.vtl
+++ b/architecture.md.vtl
@@ -96,7 +96,7 @@
While the components actually execute the logic, the `SecurityManager` implementation knows how and when to coordinate the components for the correct behavior.
-The `SecurityManager` implementations and are also JavaBeans compatible, which allows you (or a configuration mechanism) to easily customize the pluggable components via standard JavaBeans accessor/mutator methods (get*/set*). This means the Shiro's architectural modularity can translate into very easy configuration for custom behavior.
+The `SecurityManager` implementations and the components are also JavaBeans compatible, which allows you (or a configuration mechanism) to easily customize the pluggable components via standard JavaBeans accessor/mutator methods (get*/set*). This means the Shiro's architectural modularity can translate into very easy configuration for custom behavior.
#tip('Easy Configuration', 'Because of JavaBeans compatibility, it is very easy to configure the `SecurityManager` with custom components via any mechanism that supports JavaBeans-style configuration, such as <a href="spring.html" title="Spring">Spring</a>, Guice, JBoss, etc.')
diff --git a/authorization-features.md b/authorization-features.md
index cf0eb88..99eac94 100644
--- a/authorization-features.md
+++ b/authorization-features.md
@@ -14,11 +14,11 @@
* **Powerful and intuitive permission syntax** - As an option, Shiro provides an out-of-the-box permission syntax, called Wildcard Permissions, that help you model the fine grained access policies your application may have. By using Shiro's Wildcard Permissions you get an easy-to-process and human readable syntax. Moreoever, you don't have to go through the time-consuming effort and complexity of creating your own method for representing your access policies.
-* **Multiple enforcement options** – Authorization checks in Shiro can be done through in-code checks, JDK 1.5 annotations, AOP, and JSP/GSP Taglibs. Shiro's goal is to give you the choice to use the option you think are best based on your preferences and project needs.
+* **Multiple enforcement options** - Authorization checks in Shiro can be done through in-code checks, JDK 1.5 annotations, AOP, and JSP/GSP Taglibs. Shiro's goal is to give you the choice to use the option you think are best based on your preferences and project needs.
* **Strong caching support** - Any of the modern open-source and/or enterprise caching products can be plugged in to Shiro to provide a fast and efficient user-experience. For authorization, caching is crucial for performance in larger environments or with more complex policies using back-end security data sources.
-* **Pluggable data sources** - Shiro uses pluggable data access objects, referred to as Realms, to connect to security data sources where you keep your access control information, like a LDAP or a relational database. To help you avoid building and maintaining integrations yourself, Shiro provides out-of-the-box realms for popular data sources like LDAP, Active Directory, and JDBC. If needed, you can also create your own realms to support specific functionality not included in the basic realms.
+* **Pluggable data sources** - Shiro uses pluggable data access objects, referred to as Realms, to connect to security data sources where you keep your access control information, like an LDAP server or a relational database. To help you avoid building and maintaining integrations yourself, Shiro provides out-of-the-box realms for popular data sources like LDAP, Active Directory, and JDBC. If needed, you can also create your own realms to support specific functionality not included in the basic realms.
-* **Supports any data model** - Shiro can support any data model for access control-- it doesn't force a model on you. Your realm implementation ultimately decides how your permissions and roles are grouped together and whether to return a "yes" or a "no" answer to Shiro. This feature allows you to architect your application in the manner you chose and Shiro will bend to support you.
+* **Supports any data model** - Shiro can support any data model for access control—it doesn't force a model on you. Your realm implementation ultimately decides how your permissions and roles are grouped together and whether to return a "yes" or a "no" answer to Shiro. This feature allows you to architect your application in the manner you chose and Shiro will bend to support you.
<input type="hidden" id="ghEditPage" value="authorization-features.md"></input>
diff --git a/authorization.md.vtl b/authorization.md.vtl
index 59aeaf1..a0fb898 100644
--- a/authorization.md.vtl
+++ b/authorization.md.vtl
@@ -112,7 +112,7 @@
<p>For example, what if you just want to add or remove a role, or redefine a role''s behavior later? You''ll have to go back into your source code and change all your role checks to reflect the change in your security model, every time such a change is required! Not to mention the operational costs this would incur (re-test, go through QA, shut down the app, upgrade the software with the new role checks, restart the app, etc).</p>
<p>This is probably ok for very simple applications (e.g. maybe there is an ''admin'' role and ''everyone else''). But for more complicated or configurable applications, this can be a major major problem throughout the life of your application and drive a large maintenance cost for your software.</p>')
-* **Excplict Roles**: An explicit role however is essentially a named collection of actual permission statements. In this form, the application (and Shiro) knows _exactly_ what it means to have a particular role or not. Because it is known the _exact_ behavior that can be performed or not, there is no guessing or implying what a particular role can or can not do.
+* **Explicit Roles**: An explicit role however is essentially a named collection of actual permission statements. In this form, the application (and Shiro) knows _exactly_ what it means to have a particular role or not. Because it is known the _exact_ behavior that can be performed or not, there is no guessing or implying what a particular role can or can not do.
The Shiro team advocates using permissions and explicit roles instead of the older implicit approach. You will have much greater control over your application's security experience.
diff --git a/integration.md b/integration.md
index fb5ec3b..fa69b77 100644
--- a/integration.md
+++ b/integration.md
@@ -68,6 +68,13 @@
* **[Freedomotic](http://freedomotic-developer-manual.readthedocs.io/en/latest/plugins/security.html)** from [freedomotic](http://www.freedomotic.com)
An open source, flexible, secure Internet of Things (IoT) development framework in Java, useful to build and manage modern smart spaces.
+* **[FlowLogix Java EE Library](https://github.com/flowlogix/flowlogix/tree/master/flowlogix-jee)** from [Lenny Primak](https://twitter.com/lprimak)
+Integrates Java EE applications with Shiro Security, specifically makes Shiro Annotations work with Java EE.
+
+* **[Bootique Shiro](https://github.com/bootique/bootique-shiro)** from [Bootique](https://github.com/bootique/bootique)
+Bootique is a minimally opinionated platform for modern runnable Java apps.
+
+
## Ports
* **[Turnstile](https://github.com/stormpath/Turnstile)** - Swift
diff --git a/java-authentication-guide.md.vtl b/java-authentication-guide.md.vtl
index 878b187..8dabaa2 100644
--- a/java-authentication-guide.md.vtl
+++ b/java-authentication-guide.md.vtl
@@ -16,7 +16,7 @@
* **Credentials** - secret data that are used to verify identities. Passwords, Biometric data, x509 certificates,
-* **Realms** - Security specific DAO, data access object, software component that talkts to a backend data source. If you have usernames and password in LDAP, then you would have an LDAP Realm that would communicate with LDAP. The idea is that you would use a realm per back-end data source and Shiro would know how to coordinate with these realms together to do what you have to do.
+* **Realms** - Security specific DAO, data access object, software component that talks to a backend data source. If you have usernames and password in LDAP, then you would have an LDAP Realm that would communicate with LDAP. The idea is that you would use a realm per back-end data source and Shiro would know how to coordinate with these realms together to do what you have to do.
<a name="JavaAuthenticationGuide-HowtoAuthenticateinJavawithShiro"></a>
#[[##How to Authenticate in Java with Shiro]]#
diff --git a/permissions.md b/permissions.md
index cb8fe98..ed8071c 100644
--- a/permissions.md
+++ b/permissions.md
@@ -27,9 +27,9 @@
<a name="Permissions-SimpleUsage"></a>
###Simple Usage
-Let's you want to protect access to your company's printers such that some people can print to particular printers, while others can query what jobs are currently in the queue.
+Let's say you want to protect access to your company's printers such that some people can print to particular printers, while others can query what jobs are currently in the queue.
-An extremely simple approach would be to use grant the user a "queryPrinter" permission. Then you could check to see if the user has the queryPrinter permission by calling:
+An extremely simple approach would be to grant the user a "queryPrinter" permission. Then you could check to see if the user has the queryPrinter permission by calling:
``` java
subject.isPermitted("queryPrinter")
diff --git a/realm.md.vtl b/realm.md.vtl
index 9ed93d0..5a5db97 100644
--- a/realm.md.vtl
+++ b/realm.md.vtl
@@ -21,6 +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.
@@ -234,7 +236,36 @@
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.
+
+<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.
+
+ 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()`
+
+ 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()
diff --git a/session-management.md.vtl b/session-management.md.vtl
index 0dacbc3..4ee40b8 100644
--- a/session-management.md.vtl
+++ b/session-management.md.vtl
@@ -87,9 +87,9 @@
session.setAttribute( "someKey", someValue);
```
-The `subject.getSession()` method is a shortcut for calling `currentUser.getSubject(true)`.
+The `currentUser.getSession()` method is a shortcut for calling `currentUser.getSession(true)`.
-For those familiar with `HttpServletRequest` API, the `Suject.getSession(boolean create)` method functions the same way as the `HttpServletRequest.getSession(boolean create)` method:
+For those familiar with `HttpServletRequest` API, the `Subject.getSession(boolean create)` method functions the same way as the `HttpServletRequest.getSession(boolean create)` method:
* If the `Subject` already has a `Session`, the boolean argument is ignored and the `Session` is returned immediately
* If the `Subject` does not yet have a `Session` and the `create` boolean argument is `true`, a new session will be created and returned.
diff --git a/templates/default.vtl b/templates/default.vtl
index 570ac5a..45cd501 100644
--- a/templates/default.vtl
+++ b/templates/default.vtl
@@ -194,7 +194,6 @@
<li><a href="http://www.apache.org/licenses/">License</a></li>
<li><a href="http://www.apache.org/foundation/sponsorship.html">Sponsorship</a></li>
<li><a href="http://www.apache.org/foundation/thanks.html">Thanks</a></li>
- <li><a href="http://www.apache.org/foundation/sponsorship.html">Donate</a></li>
<li><a href="http://www.apache.org/security/">Security</a></li>
</ul>
</li>
diff --git a/web.md.vtl b/web.md.vtl
index db56c64..d9f5f6b 100644
--- a/web.md.vtl
+++ b/web.md.vtl
@@ -840,7 +840,7 @@
``` html
<shiro:hasAnyRoles name="developer, project manager, administrator">
You are either a developer, project manager, or administrator.
-</shiro:lacksRole>
+</shiro:hasAnyRoles>
```
The `hasAnyRole` tag does not currently have a logically opposite tag.
@@ -872,7 +872,7 @@
``` html
<shiro:lacksPermission name="user:delete">
Sorry, you are not allowed to delete user accounts.
-</shiro:hasPermission>
+</shiro:lacksPermission>
```
The `lacksPermission` tag is the logical opposite of the [hasPermission](#Web-haspermissiontag) tag.
