Apache Shiro User's Manual (iii) Shiro authorization

Authorization is access control, which determines whether the user has appropriate access to the resource in the application.

For example, determine whether a user has permission to view the page, edit the data permissions, have permissions for a button, have permission to print, and so on.

I. Three elements of authorization

Authorization has three core elements: permissions, roles, and users.

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.

Permission Declaration and granularity

Shiro a permission declaration is usually a colon-delimited expression. As mentioned earlier, a permission expression can clearly specify the type of resource, the operations allowed, and the data that can be accessed. At the same time, the Shiro permission expression supports simple wildcard characters, which allows for more flexible permission setting.

The following describes the permission expression as an instance.

User data can be queried

User:view

can query or edit user data

User:view,edit

All operations can be performed on user data

user:* or user

Editable user data with ID 123

User:edit:123

Role

Shiro supports two types of role modes:

1, traditional role: a role represents a series of operations, when the need to authorize an operation to verify, only to determine whether the role can be. This kind of role authority is relatively simple, fuzzy, not conducive to expansion.

2. Permissions role: A role that 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.

Second, the authorization to achieve

Shiro supports three ways of enabling the authorization process:

Encoding implementation
Annotation implementation
JSP Taglig Implementation

1. Encoding-based authorization implementation

1.1 implementation based on traditional role authorization

When you need to verify that a user has a role, you can invoke the Hasrole* method validation of the subject instance.

Subject CurrentUser = Securityutils.getsubject (); if (Currentuser.hasrole ("Administrator")) {//show the admin button} else {//don ' t show the button? Grey it out? }

The relevant validation methods are as follows:

Subject Method Description

Hasrole (String roleName) returns True when the user owns the specified role

Hasroles (list<string> rolenames) returns a corresponding array of Boolean values in list order

Hasallroles (collection<string> rolenames) returns True if the user has all the specified roles

Assertion Support

Shiro also supports authorization validation in an assertion manner. The assertion succeeds, does not return any values, the program continues execution, and when the assertion fails, an exception message is thrown. By using assertions, you can make our code more concise.

Subject CurrentUser = Securityutils.getsubject (); Guarantee the current user is a bank teller and//therefore allowed to open the account:currentUser.checkRole ("ban Kteller "); Openbankaccount ();

Related Methods of assertions:

Subject Method Description

Checkrole (String RoleName) asserts whether the user owns the specified role

Checkroles (collection<string> rolenames) asserts whether the user has all the specified roles

Checkroles (String ... rolenames) method overloading of the previous method

1.2 Authorization implementation based on permission role

In contrast to the traditional role pattern, the permissions-based role pattern coupling is lower, it does not change the source code because of the role changes, so the permissions-based role pattern is a better way to access control.

Its code implementation is implemented in the following ways:

1, based on the implementation of the Permission object

Creates an instance of Org.apache.shiro.authz.Permission, passing the instance object as a parameter to subject.ispermitted () for validation.

Permission printpermission = new Printerpermission ("laserjet4400n", "print"); Subject CurrentUser = Securityutils.getsubject (); if (currentuser.ispermitted (printpermission)) {//show the Print button} else {//don ' t show the button? Grey it out? } Permission printpermission = new Printerpermission ("laserjet4400n", "print"); Subject CurrentUser = Securityutils.getsubject (); if (currentuser.ispermitted (printpermission)) {//show the Print button} else {//don ' t show the button? Grey it out? }

The relevant methods are as follows:

Subject Method Description

ispermitted (Permission p) Subject has set permissions, returns Treu

ispermitted (list<permission> perms) returns a Boolean array of corresponding permissions

Ispermittedall (collection<permission> perms) subject has all the set permissions, returns True

2, string-based implementation

String-based implementations are more concise than cumbersome object-based implementations.

Subject CurrentUser = Securityutils.getsubject (); if (currentuser.ispermitted ("printer:print:laserjet4400n")) {//show the Print button} else {//don ' t show the button? Grey it out? }

A colon-delimited permission expression is an implementation of the Org.apache.shiro.authz.permission.WildcardPermission default support.

This represents the resource type: Action: Resource ID

Similar to object-based implementation-related methods, based on the implementation of string-related methods:

Ispermitted (string perm), ispermitted (String ... perms), Ispermittedall (String ... perms)

Assertion implementation based on permission object

Subject CurrentUser = Securityutils.getsubject (); Guarantee the current user is permitted//to open a bank account:permission p = new Accountpermission ("open"); Currentuser.checkpermission (P); Openbankaccount ();

String-based assertion implementations

Subject CurrentUser = Securityutils.getsubject (); Guarantee the current user is permitted//to open a bank account:currentUser.checkPermission ("Account:open"); Openbankaccount ();

Related methods for assertion implementations

Subject Method Description

Checkpermission (Permission P) asserts whether the user has permission to make

Checkpermission (String Perm) asserts whether the user has set permissions

Checkpermissions (collection<permission> perms) asserts whether the user has all specified permissions

Checkpermissions (String ... perms) asserts whether the user has all specified permissions

2. Annotation-based authorization implementation

Shiro Annotations Support AspectJ, Spring, Google-guice, etc., and can be configured differently depending on the application.

Related annotations:

@ requiresauthentication

A user class/attribute/method can be used to indicate that the current user needs to be a certified user.

@RequiresAuthentication public void Updateaccount (account UserAccount) {//this method'll is invoked by a//subject That's guaranteed authenticated ...} @ requiresguest

Indicates that the user needs to be a "guest" user

@ requirespermissions

Current user needs to have permission to set up

@RequiresPermissions ("account:create") public void CreateAccount (account account) {//this method'll is invoked by A Subject//that is permitted to create an account ...} @RequiresRoles

The current user needs to have a role set

@ requiresuser

The current user needs to be a certified user or a remembered user

3. Authorization implementation based on JSP tag

Shiro provides a set of JSP tag libraries to achieve page-level authorization control.

Before using the Shiro tag library, you first need to introduce the Shiro tag in the JSP:

<%@ taglib prefix= "Shiro" uri= "Http://shiro.apache.org/tags"%>

Here are the tags for Shiro:

Guest tag

Verify that the current user is a "guest", that is, a user who is not certified (contains not remembered)

<shiro:guest> Hi there! Please <a href= "login.jsp" >Login</a> or <a href= "signup.jsp" >Signup</a> today! </shiro:guest>

User tag

Certified by or remembered by the user

<shiro:user> Welcome back john! Not John? Click <a href= "login.jsp" >here<a> to login. </shiro:user>

Authenticated label

Authenticated by the user. Does not contain the remembered user, which is the difference from the user tag.

<shiro:authenticated> <a href= "updateaccount.jsp" >update your contact information</a>. </shiro:authenticated> notauthenticated Tags

Unauthenticated through the user, corresponds to the authenticated label. The difference from the guest tag is that the tag contains the remembered user.

<shiro:notAuthenticated> <a href= "login.jsp" >login</a> in order to update your credit card infor Mation. </shiro:notAuthenticated>

Principal label

Output current user information, usually login account information

Hello, <shiro:principal/> How is you today?

Verify that the current user is part of the role

<shiro:hasrole name= "Administrator" > <a href= "admin.jsp" >administer the system</a> </shiro: Hasrole>

Lacksrole Label

In contrast to the Hasrole label logic, validation passes when the user does not belong to the role

<shiro:lacksrole name= "Administrator" > Sorry, you aren't allowed to administer the system. </shiro:lacksRole>

Hasanyrole Label

Verify that the current user is part of any of the following roles.

<shiro:hasanyroles name= "developer, project Manager, Administrator" > You is either a developer, project manager, or Administrator. </shiro:lacksRole>

Haspermission Label

Verify that the current user has set permissions

<shiro:haspermission name= "User:create" > <a href= "createuser.jsp" >create a new user</a> </shiro: Haspermission>

Lackspermission Label

In contrast to the Haspermission label logic, the current user does not have permission to validate the

<shiro:haspermission name= "User:create" > <a href= "createuser.jsp" >create a new user</a> </shiro: Haspermission>

III. internal processing mechanism of Shiro authorization

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

2. An instance of Sbuject 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.

When using more than one realm, different from the authentication policy processing method, the authorization process:

1. When an exception is called to the realm, an exception is thrown immediately, ending authorization validation.

2, as long as there is a realm verification success, then the authorization will be considered successful, return immediately, end the certification.

The above is the Apache Shiro user manual (iii) Shiro authorized content, more relevant content please pay attention to topic.alibabacloud.com (www.php.cn)!

