Shiro certification process and authorization process _shiro

Certification:

Authentication, that is, in the application who can prove that he is himself. Generally provide some identification information such as their identity ID to indicate that he is himself, such as providing ID card, username/password to prove.
In Shiro, users need to provide principals (identity) and credentials (certification) to Shiro, so that applications can authenticate users:
Principals: Identity, that is, the identity of the main attribute, can be anything, such as user name, mailbox, and so on, the only thing. A subject can have multiple principals, but only one primary principals, typically username/password/cell phone number.
Credentials: proof/voucher, that is, only the subject knows the security value, such as password/digital certificate.
The most common principals and credentials combinations are username/password. Next, start with a basic identity authentication.

The other two related concepts are the subject and realm mentioned earlier, respectively, as the data source of the subject and the authentication principal. Shiro Certification Process

1, first call Subject.login (token) for login, it will be automatically delegated to the security Manager, before the call must pass securityutils. Setsecuritymanager () setting;
2, SecurityManager is responsible for the real authentication logic, it will entrust to authenticator for authentication;
3, authenticator is the real authenticator, Shiro API Core identity authentication entry point, here can be customized to insert their own implementation;
4, authenticator may delegate to the corresponding authenticationstrategy for multiple realm authentication, The default modularrealmauthenticator will invoke Authenticationstrategy for multiple realm authentication;
5, authenticator will be the corresponding token into the realm, from realm to obtain authentication information, if there is no return/throw an exception indicates authentication failed. Multiple realm can be configured here, and will be accessed in the appropriate order and policy. Authorized:

Authorization, also called access control, controls who can access which resources (such as access to page/Edit data/page operations, etc.) in the application. Several key objects to be understood in authorization: principals (Subject), Resources (Resource), Permissions (Permission), roles (role).

Subject

The principal, that is, the user who accesses the application, using subject on behalf of the user in Shiro. The user is authorized to access the appropriate resource only.
Resources
Anything that a user can access in an application, such as accessing a JSP page, viewing/editing some data, accessing a business method, printing text, and so on, are resources. Users can access them only after authorization.
Permissions
The Atomic authorization unit in the security policy, by which we can indicate whether the user has the power to manipulate a resource in the application. The permission means that the user can access a resource in the application, such as:
Access the User List page
View/Add/modify/delete user data (that is, most of the time crud (add to delete) type of permission control)
print documents, etc...

As can be seen, the permissions represent the user has the right to operate a resource, that is reflected in a resource on the operation is not allowed, does not reflect who to perform this operation. So the successor also needs to give the user the right to define which user is allowed to do something on a resource (permissions), Shiro will not do this thing, but by the implementation personnel to provide.

Shiro supports coarse-grained permissions (such as all permissions for a user module) and fine-grained permissions (which manipulate the permissions of a user, i.e. instance-level), as described in the following sections. Shiro Authorization Process

1, first call the subject.ispermitted*/hasrole* interface, it will be entrusted to SecurityManager, and SecurityManager will then be entrusted to Authorizer;
2, Authorizer is the real authorized person, if we call such as ispermitted ("User:view"), it will first through the Permissionresolver to convert the string into the corresponding permission instance;
3, before authorizing, it will call the corresponding realm to obtain subject corresponding Role/permissions to match the incoming roles/permissions;
4, Authorizer will judge realm role/permissions and incoming match, if there are more than realm, will be entrusted to the modularrealmauthorizer for circular judgment, if the match as ispermitted*/hasrole* Returns True, otherwise false indicates authorization failure.

Modularrealmauthorizer for multiple realm matching processes:
1, first check whether the corresponding realm realized the realization of the authorizer;
2, if realizes the Authorizer, then calls its corresponding ispermitted*/hasrole* interface to carry on the match;
3, if there is a realm match then will return true, otherwise return false.

1, if the realm to authorize, should inherit Authorizingrealm, the process is:
(1) If the call hasrole*, then directly obtain Authorizationinfo.getroles () and the incoming role comparison;
(2) First, if the call, such as ispermitted ("User:view"), first converts the permission string to the corresponding permission instance by Permissionresolver. The default is to use Wildcardpermissionresolver, the wildcardpermission that is converted to wildcard characters,
2, through Authorizationinfo.getobjectpermissions () Get permission instance set; Through Authorizationinfo. Getstringpermissions () Gets a collection of strings and resolves them to permission instances through Permissionresolver, and then the user's role. and through the rolepermissionresolver resolution of the role of the appropriate set of permissions (the default is not implemented, you can provide),
3, then invoke Permission. implies (Permission p) to compare with the incoming permissions, Returns true if there is a match, otherwise false.