Spring Security System: Acegi Security

xiaoxiao2021-03-06  17

Introduction to ACEGI

ACEGI security system is a security framework for Spring Framework, which is capable of seamlessly integrating with current popular web containers. It uses Spring to provide security and authentication security services, including the use of Bean Context, interceptors, and interface-oriented interface. Therefore, the ACEGI security system can easily apply to complex security requirements. Safety involves two different concepts, certifications, and authorization. The former is about confirming whether the user is indeed the identity they claim. Authorization is to confirm whether the user has allowed to perform a specific operation. In the ACEGI security system, users, systems, or agents that are authenticated are called "Principal". The ACEGI security system is different from other security systems, which does not have the concept of role and user groups.

ACEGI system design

Key components

The ACEGI security system contains the following seven key functional components: l Authentication object, contains authorization information for Principal, Credential, and Principal. At the same time, you can also contain additional information about the client that initiates the authentication request, such as an IP address. 2 ContexTholder objects, using threadlocal to store the AUTHENTICATION object. 3 AuthenticationManager, used to authenticate the Authentication object in ContexThold. 4 AccessDecissionManager for authorizing a specific operation. 5 RunasManager, when performing a specific operation, used to selectively replace the Authentication object. 6 Secure Object interceptors for coordinating AuthenticationManager, AccessDecissionManager, RunasManager, and a specific operation. 7 ObjectDefinitionSource, an authorization definition of a particular action.

The relationship between these seven key functional components is shown in the following figure (the gray portion in the figure is a key component):

Safety management object

The ACEGI security system currently supports two types of security management objects. The first class's security management object manages the MethodInvocation of AOP Alliance, developers to use it to protect business objects in the Spring container. In order to make Spring management beans can be used as MethodInvocation, Bean can manage through ProxyFactoryBean and BeanNameAutoproxyCreator, just like Spring's transaction management. The second category is FilterInvocation. It is created with a filter and simply wrapped the HTTP ServletRequest, ServletResponse, and Filterchain. FilterInvocation can be used to protect HTTP resources. Typically, developers don't need to understand its working mechanism, because they only need to add Filter to Web.xml, the Acegi security system can work.

Security configuration parameters

Each security management object can describe a variety of secure authentication requests. For example, the MethodInVocation object can describe calls with any method of any parameter, while filterinvocation can describe any HTTP URL. The ACEGI security system needs to record secure configuration parameters applied to each authentication request. For example, for the BankManager.GetBalance (int accessNumber) method, the BankManager.AppRovel method, the security configuration of the authentication requests need is very different. In order to save the security configuration of different authentication requests, you need to use the configuration parameters. From the perspective of implementation, the configuration parameters use the Configattribute interface to represent. The ACEGI security system provides an implementation of the Configattribute interface, SecurityConfig, saved the configuration parameters as a string. The ConfigattributeDefinition class is a simple container for the Configattribute object, which saves the collection of Configattributes associated with a specific request. When the security interceptor receives a secure authentication request, you need to decide which configuration parameter applied. In other words, it needs to find the ConfigattributedEfinition object applied to this request. This lookup process is processed by the ObjectDefinitionsource interface. The main method of this interface is public configattributedefinition GetAttributes (Object Object), where the Object parameter is a security management object. Because the security management object contains more information with the authentication request, the implementation class of the ObjectDefinitionsource interface can get the desired details to find the relevant ConfigattributeDefiniton object. How to work with Acegi

To illustrate how the ACEGI security system work, we envisage an example of using Acegi. Typically, a security system needs to work, it must do the following: l First, the system gets Principal and Credential; 2, then system authentication of Principal and Credential information; 3 If the authentication is passed, the system takes out Principal's authorization information Next, the client initiates an operation request; 5 The system checks Principal's authorization for this operation based on pre-configured parameters; 6 If the authorization check is passed, the operation is executed, otherwise it will be rejected.

So, how does the Acegi security system complete these work? First, let's take a look at the certification and authorization of the ACEGI security system:

The green part in the figure is the abstract base class of the safety interceptor, which contains two management classes, AuthenticationManager, and AccessDecisionManager, as shown in the figure. AuthenticationManager is used to authenticate the Authentication object in ContexThold (including Principal, Credential, and Principal's authorization information); AccessDecissionManager is used to authorize a specific action. A look at the following example MethodSecurityInterceptor: true net.sf.acegisecurity.context.BankManager.delete * = ROLE_SUPERVISOR, RUN_AS_SERVER net.sf.acegisecurity.context.BankManager.getBalance = ROLE_TELLER, ROLE_SUPERVISOR, BANKSECURITY_CUSTOMER, RUN_ In the above configuration file, MethodSecurityInterceptor It is an implementation class for AbstractSecurityInterceptor. It contains two managers, AuthenticationManager and AccessDecisionManager. The configuration of both is as follows:

false

Preparation work is ready, now let's take a look at how the Acegi security system implements authentication and authorization. Using the HTTP Basic authentication application as an example, it includes the following steps: 1. User login system, ACEGI gets user login information (including Principal and Credential) from the security interceptor of the AcegiSecurity.ui subsystem (such as BasicProcessingFilter). Put the Authentication object and save it in the ContexTholder object; 2. The security interceptor hands the Authentication object to AuthenticationManager for authentication. If the authentication passes, return an Authentication object with Principal authorization information. At this point, the Authentication object of the ContexTholder object already has details of Principal; 3. After the user is logged in, continue business operations; 4. After receiving the client operation request, the security interceptor is received to be safe. Management object (FilterInvocation or MethodInvocation); 5. Then, read the relevant security configuration parameters in the configuration file (ObjectDefinitionsource) ConfigattributeDefinition; Authentication, and update the Authentication object of ContexThold, the Authentication object, the configattributeDefinition object, and the secure management object (Secure Object), check the operation authorization of Principal; 8. If the authorization check is executed, the client request is executed. Otherwise, I will refuse; AccessDecisionvoter

Note that the ACCESSDecisionManager, which is an AffirmATIVEBASED class, which is the user-authorized voting strategy, as long as it passes one of the authorized votes, it can pass; its allowifallabstainDecision attribute value is false, meaning if all authorized votes are Alkeidation, it is not performed. The ACEGI security system includes several voter-based AccessDecisionManager, the last section Rolevoter is one of the voting strategies implementations, which is a subclass of AccessDecisionvoter. The specific implementation of AccessDecisionvoter is authorized by voting, and AccessDecisionManager is decided by the voting results, or throws AccessDeniedException exceptions. There are three methods AccessDecisionVoter Interface: public int vote (Authentication authentication, Object object, ConfigAttributeDefinition config); public boolean supports (ConfigAttribute attribute); public boolean supports (Class clazz); wherein the vote returns an int return value, which is the AccessDecisionVoter Three static member properties: access_abstain,, access_denied and access_grand, which are waived, veto, and agreement, respectively. In the ACEGI security system, there are three specific implementations of AccessDecisionManager for voting strategies: AffirmATIVeBased, CONSENSUSBASED and UnanimousBased. Their voting strategy is that the AffirmATIVeBased class can pass by a voting approval; the consENSUSBased class requires most voting to pass; and the UnanimousBased class requires all voting to pass. The Rolevoter class is an implementation of an ACEGI security system AccessDecisionvoter interface. If configattribute begins with role_, Rolevoter vote. If the String Return value of the GRANTEDAUTHORITY method matches the Configattribute that starts with Role_, it will vote, otherwise it will not pass. If there is no CONFITTRIBUTE starting with ROLE_, Rolevoter waits. Safety interceptor

Interceptor How to Work MethodInvocation Interceptor FilterInvocation Interceptor

Certification

Authentication request authentication manager Authentication Provider

Authorize

Access Decision Manager Voting Decision Manager Authorized Management Recommended

ContexThold user interface

User Interface Target HTTP Session Certification HTTP Basic Certification

转载请注明原文地址:https://www.9cbs.com/read-44775.html

New Post(0)