A while ago finished reading Zhang Kaitao “Shiro with me”, this book, feel for the security framework slightly had so a little understanding, the following brief talk about Shiro.

Shiro profile

Shiro is a Java Security framework that is lighter and simpler than Spring Security.

Shiro can be used not only for JavaEE but also for JavaSe, mainly to help us provide the following functions: authentication, authorization, encryption, session management, caching, etc

Note that Shiro does not provide maintenance users/permissions, but lets developers inject and maintain it themselves via Realm.

Internally, Shiro’s architecture is as follows:

​

External applications interact with Subject, which is processed by Security Manager and distributed to corresponding modules (similar to springMVC’s dispatchServlet). The processing module obtains the required data through Realm for verification or CRUD.

Subject

The Subject, the “user” interacting with the application, can be understood as an exposed Client from which to access the application. Basically, all authentication and authorization are completed through the Subject. The default implementation class is DelegatingSubject

In general, the user login is done by subject.login(). Subject.hasrole */isPermitted* Queries whether a role/permission exists

Subject.logout () exits to view the Subject interface.

Normally we can get the subject through Securityutils.getSubject () after binding the SecurityManager

	// Subject is managed by the SecurityManager, so it needs to be bound first
	SecurityUtils.setSecurityManager(securityManager);
  	/ / for the subject
	Subject subject = SecurityUtils.getSubject();
Copy the code

SecurityManager

Shiro’s real portal, controlling all interactions, and managing all subjects, is at the heart of Shiro.

​

Authenticator

The authenticator, used to manage login, is often confused with the following Authrizer. I’m still making distinctions between CA and ZA

The authenticator mainly determines whether the user can enter the application, which is equivalent to seeing whether you are legitimate for the application. Shiro provides a default validation method (ModularRealmAuthenticator), if the need to custom validation strategy, can realize own a AuthenticationStragy, and set to ModularRealmAuthenticator, Called ModularRealmAuthenticator will verify again. The default policy is AtLeastOneSuccessfulStrategy, the function is as follows

The AntuenticationStrategy provided in shiro framework implements:

  • FirstSuccessfulStrategy: Return only the first Realm authenticated successfully if one Realm authenticated successfully.
  • AtleastOneSuccessfulStrategy: as long as there is a Realm authentication is successful, returns all the Realm of the authentication information of success, that is to say, each Realm
  • AllSuccessfulStrategy: Returns successful authentication for all Realms

Custom implementations generally inherit org, apache shiro, authc. PAM. AbstractAuthenticationStrategy can

AbstractAuthenticationStrategy is an interface that contains four methods:

  1. BeforeAllAttempts: Before all validations
  2. BeforeAttempt: Before each authentication
  3. AfterAttempt: After each validation
  4. AfterAllAttempts: After all validations

Order of execution:

  1. subject.login()
  2. securityManager
  3. Authenticator
  4. AntuenticationStrategy(AntuenticationStrategy is a property of Authenticator)

Authrizer

Authorizer, used to manage permissions. There are two types of permission concepts, implicit role (RBAC, role-based) and display role (RBAC new, permission-based). The difference between the two is in granularity, and display role is more detailed

RBAC represents is to control role, namely only controls resources and roles, the relationship between the grain size is refined and in general the resources to the page, but for some required more detailed permissions control (control to the button) cannot satisfy a simple architecture level, at this time would require the programmer to deal with the page, The need for post-processing at the architectural level indicates a lack of design patterns.

What the new RBAC solution represents is that the granularity of resources is more refined than RBAC, and it directly controls any operation that accesses resources

  1. The subject calls the isPermitted* or hasRole interface and delegates to the SecurityManager, which delegates to the corresponding Authorizer. (Similar to login)
  2. Authorizer is a true Authorizer that validates authorization against the calling method
  3. Prior to authorization, the corresponding Realm is called to get the Subject’s corresponding role/permission to match the role/permission passed in
  4. Authorizer determines whether the role/permissions of a Realm match the one passed in. If there are more than one Realm, the Authorizer delegates this loop to the ModularRealmAuthorizer, returning true for matches and false for mismatches

Two more parsers are required during authorization: PermissionResolver and RolePermissionResolver

PermissionResolver – permission parser, set in the authorizer, custom implementation can realize PermissionResolver, the default implementation for WildcardPermissionResolver

RolePermissionResolver – Role resolver, set in authorizer. Custom implementations can implement RolePermissionResolver, shiro does not provide a default implementation

Realm

Realm is Shiro’s data source for users, roles, and permissions. The many-to-many relationship between users and roles and many-to-many relationship between roles and permissions is as follows

Realms can be JDBC implementations, LDAP implementations, or in-memory implementations, and write-off configurations can be provided by the user. The following shows the realm relationships provided by Shiro

As you can see from Realm’s inheritance relationships, Shiro’s separation of functionality is accomplished through Java’s inheritance relationships (again, a bit of nonsense). AuthenticatingRealm class has caching and authentication functions. AuthorizingRealm class inherits AuthenticationgRealm, extends the authorization function, and then makes distinctions according to actual business. Read configured IniRealm and so on

summary

When reading this book, I not only learned Shiro, but also had a better understanding of the design of the framework. I quote a passage from combing :” A good framework should have a very simple and easy to use API from the outside, and the API contract is clear; Internally, it should have an extensible architecture that is very easy to plug in user custom implementations because no framework can meet all requirements.”

Shiro doesn’t offer as many features as popular Spring Security, but it’s a good choice for getting started as a Security framework and reading source code. Lightweight, but not simple, and there’s still a lot to learn.