Spring Security Login Verification

Original: http://www.cnblogs.com/hzhuxin/archive/2011/12/14/2287363.html

Springsecurity's login verification is performed by Org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter This filter is done with a AuthenticationManager interface property in the parent class of the class Abstractauthenticationprocessingfilter , The verification work is done primarily through an instance of this AuthenticationManager interface. By default, the Springsecurity framework injects an instance of the Org.springframework.security.authentication.ProviderManager class into that property.

The relevant class diagram for the AuthenticationManager interface is as follows:

The verification process for Usernamepasswordauthenticationfilter is as follows:

1. First the filter will call its own Attemptauthentication method, remove the authentication from the request, authentication is the The Org.springframework.security.web.context.SecurityContextPersistenceFilter filter generates one by capturing the contents of a user-submitted login form Org.springframework.security.core.Authentication Interface instance.

2. After getting the authentication object, the filter invokes the Authenticate method of the Providermanager class and passes in the object

The Authenticate method of the 3.ProviderManager class then calls its own Doauthentication method, which in the Doauthentication method invokes the list< in the class. Authenticationprovider> the authenticate of each Authenticationprovider interface implementation class in the Providers collection (authentication Authentication) method, this shows that the real validation logic is done by each Authenticationprovider interface implementation class, The Daoauthenticationprovider class is a Authenticationprovider interface implementation class that is injected by default

4.AuthenticationProvider interface to obtain user information via Userdetailsservice

The following is a timing diagram:

Article 2:

Work needs, but also to get the authority of management. Although I've known about container-based permission implementations a long time ago, I've always felt that it was too primitive. Later, when using Liferay, it was found that the privilege system did a great job, and it was probably the best place for it. But at that time only to stay in how to use and some of the relationship with its cohesion, and did not understand the bottom, new to the present company, found that this lesson still has to be made up. But surprisingly, there are not many options available, even few, and the most famous are spring security, although well-known, but there is not much information on this, and there are fewer examples of applications. Fortunately there are official Chinese documents and a brief tutorial published by http://www.family168.com/bbs/, so it is not too difficult to learn. Then referring to a downpour wrote the spring security article, so barely familiar with the spring security application development, but basically only stay on the basis of reluctantly used, but also spent a lot of my time in the application of a project, I almost did not get a platform, surprised out a cold sweat. At the time, spring security is a garbage thing, the use is very complex, even if it is a permission system to intercept the path, there are many steps. Now that you are familiar with some of its processes, although it is not known whether such implementation is the most reasonable, but it does have its rationale. Now take advantage of the holiday period, you can calm down to understand some of the things that have been confusing before. Downpour cattle people that article is very good, so that I really took some time to fully familiar with it, at present, I was not familiar with Acegi. Once you get familiar with that article, there are some places that you don't understand, one of which is how spring security accomplishes user role permission validation. The following is a brief introduction to this person's question:

First of all, this article is based on downpour, whose address is:
http://www.iteye.com/topic/319965

The first thing to do is the configuration file, which is the most important entry point for the entire spring security:

XML code    ............   <!--   handling internationalization information  -->        <beans:bean id= "AuthenticationManager"             class= "Org.springframework.security.providers.ProviderManager" >            <beans:property name= "Messagesource"  ref= "MessageSource"  />        </beans:bean>               <beans:bean id= "Messagesource"             class= "Org.springframework.context.support.ReloadableResourceBundleMessageSource" >            <beans:property name= "basename"                 value= "Classpath:org/springframework/security/messages_ ZH_CN " />       </beans:bean>           <authentication-provider user-service-ref= "SecurityManager" >            <password-encoder hash= "MD5"  />        </authentication-provider>      <!-- affirmativebased means that as long as there is a voter through the permission requirements, you can access  -->       <beans:bean id= "Accessdecisionmanager"            class= "org.springframework.security.vote.AffirmativeBased" >            <!--  Whether all voters are allowed to abstain, if false, indicating that if all the voters abstained, No access to  -->           <beans:property name= " Allowifallabstaindecisions "                value= "false"  />           <beans:property name= " Decisionvoters ">               < beans:list>   <!-- rolevoter The default role name will start with Role_, otherwise it will not be counted as permission control, if you want to modify the prefix, you can modify the Roleprefix property  -->                    <beans:bean class= "Org.springframework.security.vote.RoleVoter"  />                   <