Apache Shiro cluster Implementation (IV) Shiro authorization (authentication)-access control

Authorization (Authorization), also called access control, is a process of managing access to resources, that is, in the application summary, who has what permissions (what the user can see, what can be done).

In the Itoo project, the first is to consider role-based authorization, when the role of the user changes, not flexible, so in order to better integrate the actual situation of the project, is the use of the method of the string to verify the permissions, of course, for the background of the methods can be used annotated permissions control (can be user class/Properties/methods, Used to indicate that the current user needs to be a certified user).

three elements of authorization

Permissions

A privilege is an atomic unit in a Shiro permission system that explicitly defines a user's behavior, such as what a user can do in a system.

For example: Download a file, access the/user/list link, delete the user, and so on. Permissions are generally based on resources and on resource operations (such as CRUD).

Permissions simply reflect the behavior (the operation of the resource) and do not respond to who executes it. Permissions are assigned to users, or roles, to determine which users have certain permissions.

Resources

All the things in the system that are accessible and operable. For example, links in the system, buttons, methods, and so on.

User

Also called the principal (subjects), the person accessing the app, or something else, such as another application. Users can access the system's resources only if they are authorized.

Permissions

Permissions are the core elements of Apache's Shiro security mechanism. It explicitly declares the permitted behavior and performance in the application. A well-formed permission declaration can clearly express the user's permissions on the resource.

Most resources support typical CRUD operations (create,read,update,delete), but it makes sense for any operation to be based on a specific resource. Therefore, the fundamental idea of a permission statement is to build on resources and operations.

We can only understand what this permission can do in the application through a permission statement, and we cannot determine who owns the permission. As a result, we need to correlate users and permissions in the application. It is common practice to assign permissions to a role and then associate the role with one or more users.

role

1. Traditional roles:

A role represents a series of actions, and when authorization is required for an operation, only the role can be judged. This kind of role authority is relatively simple, fuzzy, not conducive to expansion.

2. Permissions role:

A role has a collection of permissions. When authorizing authentication, you need to determine whether the current role has that permission. This role permission can be used to describe the role in detail, for more complex permissions design.

The authorization implementations for the two role modes are described in detail below.

The authorization implementations for the two role modes are described in detail below.

Shiro supports three ways of enabling the authorization process:

? Encoding implementation

? Annotation implementation

? JSP Taglig Implementation

1. Invoke the authorization authentication method in the application (subject ispermitted* or hasrole*, etc.)

2. An instance of subject is typically an instance object of the Delegatingsubject class (or subclass) that, at the beginning of authentication, delegates the SecurityManager instance set by the application to invoke the appropriate ispermitted* or hasrole* method.

3, next SecurityManager will delegate the built-in Authorizer instance (default is the instance of the Modularrealmauthorizer class, similar to the authentication instance, it also supports one or more realm instance authentication) call the appropriate authorization method.

4. Each realm will check whether the same Authorizer interface is implemented. Then, you will invoke Reaml's own corresponding authorization validation method.

In the authentication, authorization internal implementation mechanism is mentioned, the final processing will be handed over to real for processing. Because in Shiro, it is ultimately through realm to get the user, role, and permission information in the application. Typically, the validation information required by Shiro is obtained directly from our data source in realm. It can be said that realm is a DAO that is dedicated to the security framework.

As mentioned earlier, the Shiro certification process will eventually be handed over to realm, and the realm's Getauthenticationinfo method will be called.

The method mainly performs the following actions:

1. Check the token information submitted for authentication

2. Obtain user information from a data source (typically a database) based on the token information

3, the user information to match authentication.

4. Validation will return a AuthenticationInfo instance that encapsulates the user's information.

5, the validation fails to throw Authenticationexception exception information.

What we want to do in our application is to customize a realm class, inherit the Authorizingrealm abstract class, Overload dogetauthenticationinfo (), and rewrite the method of getting the user information.

Java code

And the authorization implementation is very similar to the authentication implementation, in our custom realm, the overloaded Dogetauthorizationinfo () method, overriding the way to get user permissions.

Java code

Authorization Implementation
REAML implementation
First, the implementation of certification

<span style= "FONT-SIZE:18PX;" ><span style= "FONT-SIZE:18PX;" >1.protected authenticationinfo dogetauthenticationinfo (Authenticationtoken authcToken) throws Authenticationexception {2. Usernamepasswordtoken token = (usernamepasswordtoken) Authctoken; 3. User user = Accountmanager.finduserbyusername (token.getusername ());  4. if (user! = null) {5. return new Simpleauthenticationinfo (User.getusername (), User.getpassword (), GetName ()); 6.} else {7. return null; 8.} 9. } </span></span>

Second, the authorization to achieve

Resolves the appropriate set of permissions based on the role.

<span style= "FONT-SIZE:18PX;" ><span style= "FONT-SIZE:18PX;" >package Com.tgb.itoo.authority.service;import Java.util.iterator;import Java.util.list;import Javax.annotation.resource;import Org.apache.shiro.securityutils;import Org.apache.shiro.authc.authenticationexception;import Org.apache.shiro.authc.authenticationinfo;import Org.apache.shiro.authc.authenticationtoken;import Org.apache.shiro.authc.simpleauthenticationinfo;import Org.apache.shiro.authc.usernamepasswordtoken;import Org.apache.shiro.authz.authorizationinfo;import Org.apache.shiro.authz.simpleauthorizationinfo;import Org.apache.shiro.cache.cache;import Org.apache.shiro.cache.cachemanager;import Org.apache.shiro.cas.casrealm;import org.apache.shiro.session.Session ; Import Org.apache.shiro.subject.principalcollection;import Org.apache.shiro.subject.subject;import Com.tgb.itoo.authority.entity.allusers;public class Shirorealmbean extends Casrealm {//Business interface for obtaining user information and user rights information private Shirobean permissionmgr;//Authorized @overrideprotected authorizationinfo Dogetauthorizationinfo (principalcollection principals) {//permission name string PermissionName; try {//Query user authorization information Simpleauthorizationinfo author = new Simpleauthorizationinfo ();//Find login user name String username = (string) prin Cipals.getprimaryprincipal (); SYSTEM.OUT.PRINTLN (username);//Query the resource list<string> lstpermission = permissionmgr.queryuserpermission for the corresponding role of the user ( username);//iterative query iterator<string> it = Lstpermission.iterator (); while (It.hasnext ()) {permissionname = It.next () . toString ();//Add the resource name to the resource collection that the user is author.addstringpermission (permissionname);} return author;} catch (Exception e) {e.printstacktrace (); return null;}} Public Shirobean Getpermissionmgr () {return permissionmgr;} public void Setpermissionmgr (Shirobean permissionmgr) {this.permissionmgr = Permissionmgr;}} </span></span>

On the JSP page we introduce the Shiro tag

<span style= "FONT-SIZE:18PX;" ><span style= "FONT-SIZE:18PX;" ><%@ taglib prefix= "Shiro" uri= "Http://shiro.apache.org/tags"%></span></span>

Add such a tag to the element you want to control, judging by the string

<span style= "FONT-SIZE:18PX;" ><span style= "FONT-SIZE:18PX;" ><shiro:haspermission name= "Itoo-authority-role-role-add" ><a href= "javascript:void (0)" id= "BtnAdd" class= "Easyui-linkbutton" style= "height:30px; width:60px "iconcls=" Icon-add "plain=" true "onclick=" Addroleui () "> Add </a>      </ shiro:haspermission> <shiro:haspermission name= "Itoo-authority-role-role-edit" ><a href= "javascript: void (0) "id=" Btnedit "class=" Easyui-linkbutton "style=" height:30px; width:60px "iconcls=" Icon-edit "plain=" true "onclick=" Editroleui () "> Edit </a>     </ Shiro:haspermission><shiro:haspermission name= "Itoo-authority-role-role-delete" ><a href= "javascript: void (0) "id=" Btndel "class=" Easyui-linkbutton "style=" height:30px; width:60px "iconcls=" Icon-remove "plain=" true "onclick=" DeleteRole () "> Delete </a>     < /shiro:haspermission></span></span>

The corresponding set of permissions based on role resolution realizes the control of buttons and resources, and then learns to solve the session, sharing, resource cache sharing, and Redis to achieve, first of all we should learn the relevant content under the High availability cluster

 High-availability session solution under distributed cluster System

Apache Shiro cluster Implementation (IV) Shiro authorization (authentication)-access control