Shiro's design goal is to make the application's security management simpler and more intuitive.
Software systems are generally designed to be based on user stories. That is, we design the user interface and the service interface based on how a customer interacts with this software system. For example, you might say, "If a user is logged into our system, I'll show them a button and then click on it to view his own account information." If I'm not logged in, I'll show him a registration button. ” The above application is largely written to meet the needs of the user, even if the "user" is not a human being, but rather an additional software system. You are still writing your logic code according to the logic of who is currently interacting with your system. The design of Shiro has taken into account the above concepts of user security.
General overview At the top level, the Shiro architecture has 3 main concepts: Subject, SecurityManager, and realms. Showing the interactions between these components, we'll cover these concepts one by one: #,subject, as we said in the tutorial, Subject actually represents the user who is currently performing the operation, except because "user" generally refers to a person, but a "Subject" can be a person, It can also be any third-party system, service account, or any other third-party software system that is interacting with the current system. all subject instances are bound to a securitymanager, and if you interact with a subject, all of the interactions will be converted to subject and SecurityManager interactions. #,securitymanager. SecurityManager is the core of Shiro, he is mainly used to coordinate Shiro internal security components, but we generally do not care too much about SecurityManager, for application developers, The main use of the subject API is to handle various security validation logic. #,realm, which is a bridge for connecting user data to Shiro and customer systems. Once Shiro really needs access to a variety of security-related data, such as user authentication with user accounts and permission validation, he always reads the data by invoking the various realms configured by the system. Because of this, realm is often seen as a security-field DAO, encapsulating the details of the data source connection, and providing the data in the format required by Shiro to Shiro. When we configure Shiro, we need to configure at least one realm to provide user authentication and permission control data. We may configure multiple realms for SecurityManager, but we need to configure at least one anyway. Shiro provides several out-of-the-box realms to access secure data sources, such as LDAP, relational databases, INI-based security profiles, and so on, and you can write your own custom realm plugin if these realms are not available to meet your needs by default. Like other internal components, SecurityManager determines how realm is used in Shiro to read identity and permissions data, and then assembles it into subject instances.
Detailed ArchitectureDemonstrates the core components of Shiro and outlines the capabilities of each component. #,subject,(
org.apache.shiro.subject.Subject),As described above;#,securitymanager, (Org.apache.shiro.mgt.SecurityManager),As described above;#,authenticator (user authentication manager), (Org.apache.shiro.authc.Authenticator) This component is primarily used to handle user login logic, and he calls the realm's interface to determine the identity of the currently logged-on user. *, user authentication policy,(Org.apache.shiro.authc.pam.AuthenticationStrategy) If you have more than one realm configured, you will need to use Authenticationstrategy to reconcile these realms to determine whether a user's credentials are successful or failed. (for example, if a realm proves successful, but the others fail, is the certification successful?) Or must all realms think that success is a success? Or is the first success even successful? Can be seen, the strategy is quite complex);#, Authorizer (rights Manager)(Org.apache.shiro.authz.Authorizer) This component is primarily used for user access control. In layman's terms, you decide what you can and can't do. Andsimilar to authenticator,Authorizer also knows how to coordinate data from multiple realm data sources, and he has his own set of strategies. #,sessionmanager (Session manager) (Org.apache.shiro.session.mgt.SessionManager) SessionManager knows how to create a session, manage the claims cycle of the user's reply, and provide a robust reply management experience for all running environments. Shiro can manage user sessions locally (even without the Web or EJB container) in any running environment-a unique feat in the framework of security management. Of course, if there is a session management mechanism (such as a servlet container) in the current environment, Shiro will use the session management mechanism for that environment by default. If a standalone application such as a console program does not have a session management mechanism, Shiro will use the internal session manager to provide an all-in-one programming experience for application development. Sessiondao allows users to use any type of data source to store session data. *,sessiondao,(Org.apache.shiro.session.mgt.eis.SessionDAO) Used instead of SessionManager to perform session-related additions and deletions. This interface allows us to introduce any kind of data storage method into the framework of Session management. #,cachemanager(Org.apache.shiro.cache.CacheManager) CacheManager is used to create and maintain some cache instances in other Shiro components to maintain the lifecycle of these cache instances. The cache is used to store data from the backend for user authentication and permission control to improve performance, and the cache is a first-class citizen, always looking from the cache when fetching data, if no further calls to the backend interface are obtained from other data sources. Shiro allows users to use other, more modern, enterprise-class data sources to replace the internal default implementations to provide higher performance and a better user experience. #，Cryptography, encryption technology,(Org.apache.shiro.crypto.*)For an enterprise-level security framework, encryption is inherently a feature. Shiro's crypto package contains a series of easy-to-understand and used cryptographic, hash (aka Digest) helper classes. All the classes in this package are well-designed, and the set of cryptographic components provided by Shiro is simply not much better than the set of anti-human cryptographic components provided by Java itself.
#,realm,(Org.apache.shiro.realm.Realm)As mentioned above, realm is a bridge to connect Shiro and your security data. Whenever Shiro needs to perform login or access control, it needs to invoke the configured realm interface to fetch the data. An application can configure one or more realms (typically a data source configuration).
SecurityManager IntroductionShiro mainly provides subject as the core of some of the column API, a variety of user authentication and access control interface is designed around the subject, so the general user will not need to deal directly with the SecurityManager class. Even so, if we can understand some of the SecurityManager-related principles of work, it's good for us to better use Shiro.
Design As described above, the application's SecurityManager performs security-related operations and manages the state of all users of the app. In the default implementation of the Shiro SecurityManager, these actions and statuses include:#, user authentication; #, authority control; #, reply management; #, cache management; #,realm coordination dispatch; #, event propagation; #, "Remember Me" service; #, create subject; #, sign out; 。。 If you want to implement all of these features within a class, it will be quite complex. But what if we further require that all of these features be flexible enough to be customizable? In order to provide more flexible configurable features, pluggable features, the implementation of Shiro is completely modular, the SecurityManager itself almost does not do anything, he is just a lightweight "container" component, he has all the functions forwarded to the relevant sub-components to complete, The design pattern for this wrapper is shown in the block diagram in the detailed architecture above. SecurityManager is also compatible with JavaBeans so that we can give securitymanager such as some custom components through JavaBean's standard get*/set* method.
Easy to configure : because it is compatible with JavaBean, we can use any JavaBean compatible mechanism to inject some custom components into SecurityManager, such as spring, Guice, JBoss, and so on. In the next section we will describe the configuration)the relevant information. Original address: http://shiro.apache.org/architecture.html
Related to this series:
Apache Shiro Series One: First knowledge
Apache Shiro Series two, basic concept
Apache Shiro Series three: 10 minutes to get started
Apache Shiro Series IV: Shiro architecture
