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:
Implementation of JSP Taglig implementation by coding implementation Annotations 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.
Java code 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 |
Describe |
| Hasrole (String roleName) |
Returns True when the user owns the specified role |
| Hasroles (list<string> rolenames) |
Returns an array of the corresponding 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.
Java code Subject CurrentUser = Securityutils.getsubject (); Guarantee the current user was a bank teller and//therefore allowed to open the Account:currentUser.checkRole ( "Bankteller"); Openbankaccount ();
Related Methods of assertions:
| Subject method |
Describe |
| Checkrole (String roleName) |
Assert whether the user owns the specified role |
| Checkroles (collection<string> rolenames) |
Assert whether the user owns all specified roles |
| Checkroles (String ... rolenames) |
Method overloads for 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.
Java Code 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? }&NBSP;&NBSp
The relevant methods are as follows:
| Subject method |
Describe |
| ispermitted (Permission p) |
Subject returns Treu when having permission to set |
| ispermitted (list<permission> perms) |
Returns a Boolean array of corresponding permissions |
| Ispermittedall (collection<permission> perms) |
Returns True when subject has all the set permissions |
2, string-based implementation
String-based implementations are more concise than cumbersome object-based implementations.
Java code Subject CurrentUser = Securityutils.getsubject (); if (currentuser.ispermitted ("printer:print:laserjet4400n")) {//show the Print button} else {
