Spring Security Framework Principles

Transferred from: http://www.blogjava.net/youxia/archive/2008/12/07/244883.html

In the official documentation for Springside 3, the security framework uses Spring Security 2.0. At first glance, I was startled to think that Acegi was eliminated so soon. Search engine A search, found that the original Spring Security 2.0 is Acegi 2.0. The hanging heart was set down. Although the configuration file for Acegi in Springside 3 seemed unfamiliar, everything was relieved after reading the official documents of Acegi 2.0.
First of all to talk about the basic knowledge of acegi, the structure of Acegi is more complex, but I hope my next few words can make it clear. As we all know, if you want to protect the Web resources, the best way is to filter, in order to protect the method calls, the best way is the AOP. Acegi the protection of Web resources is realized by filter. Such as:

In general, our filter is configured in Web. XML, but Acegi is not the same, it is configured in Web. Xml as just a proxy, and the really working filter is configured as a bean in spring. The agents in Web. XML invoke these beans in turn, implementing the protection of the website resources, and the filter is managed by spring as a bean, so implementing AOP is simple, really double benefit.
Acegi provides a lot of filter, there are more than 10, one to learn more complex. But for our web developers, there are a few common ones, such as the ones that are marked in red circles:

From top to bottom, they achieve the function of 1, the establishment must be HTTPS connection, 2, from the session to extract the user's authentication information, 3, log out, 4, login; 5, remember the user; 6. All applications must be configured with this filter.
Generally speaking, we only need to be familiar with these filter to write the Web application, if you do not need HTTPS connection, even the first one is not familiar. But I'm sure someone would like to think, how do these filter relate to my database? Don't worry, these filters do not directly handle the user's authentication, nor do they directly handle the user's authorization, but instead give them to the authentication manager and the decision manager. Such as:

For both of these managers, it is also not necessary for us to write code, ACEGI also provides a ready-made class. Then everyone is strange: it is out of the box, how is it associated with my database? Do not worry, in fact, these two managers do not do their own work, certification manager to the task to provider, and the decision manager to the task to voter, such as:

Now I want to tell you that provider and voter here don't need us to write code. Don't break down and get to the target. Acegi provides multiple implementations of provider, and if we want to use a database to store the user's authentication data, we choose Daoauthenticationprovider. For voter, we generally choose Rolevoter to be sufficient, it will be based on the settings in our configuration file to determine whether to allow a user to access the established Web resources.
Daoauthenticationprovider is also not directly operating the database, it entrusted to the task of userdetailservice, such as:

And what we have to do is to achieve this userdetailservice. The picture is not good, we do not laughed at, but said so much finally leads to our development of the key, that is, we want to achieve their own userdetailservice, it is to connect our database and Acegi bridge. The userdetailservice requirement is also simple, requiring only a loaduserbyusername that returns the Org.springframework.security.userdetails.User object (String UserName) method. So, how to design a database, whether we use a table or two tables or three tables, regardless of whether we are user-authorization, user-role-authorization, or user-user group-role-authorization, these specific things acegi do not care, it only cares about the returned user object, As for how to read data from a database, it's our own business.
In turn, looking at the process above, we found that even though all we had to do was implement our own Userdetailservice class, we had to configure a bunch of beans in spring, including several filter, several manager, Several provider and voter, and these configurations are often repetitive and meaningless. Fortunately, Acegi 2.0 also recognizes this problem, so it has designed a
Is the traditional filter setting in the official article and the correspondence between the
The following code is an example of the implementation of Userdetailservice in Springside 3, in the example of Springside 3, White uses three tables user, Role, authority. But Acegi doesn't care how many tables you use, it only cares about userdetails objects. and determine whether the user can access the specified Web resources, is the Rolevoter class, without any modification it can work very well, the only drawback is that it only recognized role_ prefix, so make white authority look like characters, neither fish nor fowl.

 Packagepersonal.youxia.service.security;Importjava.util.ArrayList;Importjava.util.List;Importorg.springframework.beans.factory.annotation.Required;Importorg.springframework.dao.DataAccessException;Importorg.springframework.security.GrantedAuthority;ImportOrg.springframework.security.GrantedAuthorityImpl;Importorg.springframework.security.userdetails.UserDetails;ImportOrg.springframework.security.userdetails.UserDetailsService;Importorg.springframework.security.userdetails.UsernameNotFoundException;Importpersonal.youxia.entity.user.Authority;ImportPersonal.youxia.entity.user.Role;ImportPersonal.youxia.entity.user.User;ImportPersonal.youxia.service.user.UserManager;/*** Implement Springsecurity Userdetailsservice interface to get user detail information. *@authorCalvin*/ Public classUserdetailserviceimplImplementsUserdetailsservice {PrivateUsermanager Usermanager;  PublicUserdetails loaduserbyusername (String userName)throwsusernamenotfoundexception, dataaccessexception {User User=Usermanager.getuserbyloginname (userName); if(User = =NULL)            Throw NewUsernamenotfoundexception (UserName + "does not exist"); List<GrantedAuthority> authslist =NewArraylist<grantedauthority>();  for(Role role:user.getRoles ()) { for(Authority Authority:role.getAuths ()) {Authslist.add (NewGrantedauthorityimpl (Authority.getname ())); }        }        //There are currently no properties such as enabled, accountnonexpired,credentialsnonexpired, accountnonlocked, etc. in the user class of Multidatabaseexample//all temporarily set to True to add these properties when needed.Org.springframework.security.userdetails.User Userdetail =NewOrg.springframework.security.userdetails.User (User.getloginname (), User.getpassword (),true,true,true,true, Authslist. ToArray (Newgrantedauthority[authslist.size ()]); returnUserdetail; } @Required Public voidSetusermanager (Usermanager usermanager) { This. Usermanager =Usermanager; }}

Finally, to say the question of the name, I authentication and authority these two words more offensive, two reasons, one is because they are too uncommon, two is because they look too much like, clearly one is certification, one is authorized, meaning is far away, the appearance is so similar, It's really annoying. If I choose, I like the word privilege, when I first used MySQL, it is very familiar with it, so in my project, I may use privilege instead of authority. If we only use User-role two-level relationship, using the rolevoter default Role_ prefix of course it does not matter, if it is like white in a three-layer relationship, it is best to change the prefix to avoid confusion.

Spring Security Framework Principles