Look at Shiro’s architecture
Shiro’s architecture has three main concepts: Subject, SecurityManager, and Realms. Here’s a high-level overview of how these components interact, and we’ll cover each concept below:
- Subject: As mentioned earlier,SubjectThat means it could be a person, it could be a third-party service, daemon account, cron job, or any type of thing, basically anything that is currently interacting with the software
- SecurityManagerAs mentioned earlier, Shiro is the core of its architecture, coordinating its internal security components
- RealmsMost importantly, Realms serves as a “bridge” between Shiro and application security data, enabling one or more user accounts to be configured when interacting with them to perform authentication and authorization (access control)RealmsIn fact, it is essentially a DAO operation, and then login user authentication authorization,SecurityManagerYou can configure one or moreRealmAt least one is neededRealmsYou can connect to multiple data sources such as JDBC/INI, properties files, etc., or you can customize the data source.
Core architecture
Here are a few components that we haven’t talked about before
- AuthenticatorThe: authenticator is the component responsible for performing and responding to the user’s authentication (login) attempt. This logic is performed by the authenticator when the user tries to log in. Authenticator knows how to coordinate with one or more Realms that store relevant user/account information. Data from these Realms is used to authenticate users to ensure that they are real.
- Authentication Strategy: Authentication policy, if multiple authentication policies are configuredRealmIf one Realm succeeds but the others fail, or must all of them succeed? Or just the first one?
- Authorizer: authorization,AuthorizerIs the component responsible for determining user access control in an application. It is the mechanism that ultimately decides whether the user is allowed to do something. Like Authenticator,AuthenticatorYou also know how to coordinate access roles and permission information with multiple back-end data sources. *Authorizer * uses this information to determine exactly whether a user is allowed to perform a given action.
-
- Our SessionManager:SessionManagerCreate and manage the user session lifecycle to provide a powerful session experience for users in all environments. This is a unique feature in the realm of security frameworks — Shiro’s ability to manage user sessions locally in any environment, even if no Web/Servlet or EJB container is available. By default, Shiro will use existing session mechanisms (such as Servlet Container), but if not, for example in standalone applications or non-Web environments, it will use its built-in enterprise session management to provide the same functionality.SessionDAOClass exists to allow persistent sessions using any data source.
- SessionDAO:SessionDAOPerforms session persistence (CRUD) operations on behalf of the SessionManager
-
- Cryptography*: Used to provide password related operations, Shiro’s Cryptography package contains easy-to-use and understandable Cryptography passwords, hashing (aka digests), and representations of different codec implementations. All the classes in this package have been carefully designed to be very easy to use and understand. Simplifies password encryption.
What is included in the implementation of SecurityManager?
- Authentication: the Authentication
- Authorization Authorization:
- Session Management: Session Management
- Cache Management: Cache Management
- [Realm] coordination: used to manipulate data and authentication operations
- Event Propagation: Events
- “Remember Me” Services: Remember Me
- Subject creation: the Subject
- Logout and more: Logout
conclusion
- This is mainly about Shiro’s architecture, but it mostly revolves aroundSecurityManagerTo coordinate the calls to each component, which will be reflected later when you look at the source code, you can think of each part as a Shiro component, and then the SecurityManager to coordinate the management