Apache Shiro Series 3: Shiro structure, apacheshiro
Shiro is designed to simplify application security management. The software is generally designed based on the user. That is to say, we often design related user interfaces based on how users interact with our software. For example, you may say, "If a logged-on user interacts with my software, I will display a button for him to view his account information after clicking it. If the user does not log on, I will display a registration button ".
This example shows that many of our software code is written to meet user needs. Even if the "user" is sometimes not a single person (for example, another software system ).
Shiro's design reflects these ideas, which makes it easier for developers to understand some of Shiro's concepts and make Shiro easier to use.
I. Overview of Shiro Structure
At a high level, there are three main concepts in the Shiro structure: Subject, SecurityManager, and Realms. Demonstrate how these components interact:
- Subject: The "user" of the currently executing program ". Subject has a wider meaning, because users generally refer to people, while Subject can refer to people, processes, scheduled tasks, and daemon processes. To be accurate, Subject refers to "the current thing that interacts with the software ". In most scenarios, You can roughly consider Subject as a user.
The Subject object is bound to a SecurityManager object. When you interact with a Subject, these interactions are translated as subject-specific by the corresponding SecurityManager.
- SecurityManager: SecurityManager is the core of the Shiro structure. It is used to coordinate various internal security components. However, once SecurityManager and its internal security components are configured, the programmer will no longer use it. At this time, the programmer usually deals with the Subject API.
In the subsequent tutorial, We will detail SecurityManager. But before that, you need to know that when we interact with Subject, SecurityManager actually helped us with those operations behind the scenes, as shown in the figure above.
- Realms: Realms is like a bridge or connector that connects Shiro to your application security data. When we use security-related data for interaction, such as user account authentication (LOGIN) and authorization management, Shiro will find relevant data from one or more configured Realms.
From this perspective, Realms is actually a DAO: encapsulates the details of the connection to the data source and enables Shiro to easily read the relevant data. When we configure Shiro, there must be at least one Realms. SecurityManager can be configured by multiple Realms, but at least one Realms is configured.
Shiro provides multiple types of Realms to connect to data sources, such as LDAP, database (JDBC), and text configuration files (such as INI ).
Like other internal components, SecurityManager manages how Realms obtains security data and authenticates data to configure Subject.
Ii. Detailed Structure
Shows the detailed structure of Shiro:
- Subject: as described above.
- SecurityManager: as described above.
- Authenticator (Authenticator) is an internal component responsible for executing user logon and performing corresponding actions. When a user attempts to log on, the logic is that the Authenticator is performing this action. Authenticator knows how to coordinate one or more Realms that store user/account information. The information obtained from Realms is authenticated.
Authentication Strategy indicates whether or not the current logon succeeds if one Realms logon succeeds but other Realms logon fails when multiple Realms logon attempts exist? This is determined by Authentication Stratege.
- Authorizer: Authorizer is a component responsible for permission control. Like Authenticator, Authorizer knows how to coordinate one or more data sources that store roles and licenses. Authorizer uses this information to determine whether a user is allowed to perform an action.
- SessionManager: SessionManager knows how to create and manage a user Session. This feature is not available in other security management frameworks. Shiro can manage sessions locally regardless of the environment, even if there is no web/servlet or EJB container. SessionDAO can manage the data sources used to implement sessions.
- CacheManager (Cache Management): CacheManager creates and manages the Cache object lifecycle. Because Shiro needs to access many underlying data sources for identity authentication, permission management, and Session management operations, the cache is at the lowest level to improve performance. Any open-source cache framework can be integrated into Shiro.
- Cryptography: The Shiro crypro package contains many easy-to-use encryption algorithms.
- Realms: as described above.
III. The SecurityManager
Because Shior encourages programmers to develop applications with Subject as the center, programmers will hardly deal with SecurityManager. Even so, it is necessary to have a deep understanding of SecurityManager.
As described above, SecurityManager processes security operations and manages the status of all users. It includes the following functions in Shiro's default SecurityManager:
- Authentication
- Authoriztion
- Session Managerment
- Cache Managerment
- Realm coordination
- Event propagation (Event propagation)
- "Remember me" Service
- Create Subject
- Logout and so on
All Shiro designs are very modular to simplify configuration and enhance scalability. As described in the preceding detailed structure, Shiro designs these complex tasks into one module after another, not completely completed by SecurityManager.
SecurityManager is also compatible with JavaBeans, which allows you to customize these components through the accessor/mutator (get/set) of JavaBeans and use JavaBeans-style configurations (such as Spring, Guice, and JBoss) it is very easy to configure SecurityManager. We will give a detailed introduction in subsequent tutorials.
