Shulou(Shulou.com)06/01 Report--

This article mainly explains "how to achieve ultra-fine-grained access control in Spring Security". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how to achieve ultra-fine-grained access control in Spring Security".

1. Preparatory work

First create a Spring Boot project, because we are involved in database operations here, so in addition to Spring Security dependencies, we also need to add database drivers and MyBatis dependencies.

Since there is no starter related to acl, we need to add acl dependencies manually, and acl also depends on ehcache caching, so we also need to add cache dependencies.

The final pom.xml file is as follows:

Org.springframework.boot spring-boot-starter-security org.springframework.boot spring-boot-starter-web org.springframework.security spring-security-acl 5.3.4.RELEASE org.mybatis.spring.boot mybatis-spring-boot-starter 2.1.3 mysql mysql-connector-java net.sf.ehcache ehcache 2.10.4 com.alibaba druid-spring-boot-starter 1.1.23 org.springframework spring-context-support

After the project is created successfully, we can find the database script file in the jar package of acl:

Select the appropriate script to execute according to your own database, and create a total of four tables after execution, as follows:

I will not explain the meaning of the table too much. For those who are not clear, you can refer to the previous article: how to refine the permission granularity in Spring Security?

Finally, configure the database information in the application.properties file of the project, as follows:

Spring.datasource.url=jdbc:mysql:///acls?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghaispring.datasource.username=rootspring.datasource.password=123spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver

At this point, the preparatory work is complete. Next, let's look at the configuration.

2.ACL configuration

The amount of this configuration code is relatively large. I'll put the code up first, and then we'll analyze it one by one:

@ Configuration@EnableGlobalMethodSecurity (prePostEnabled = true, securedEnabled = true) public class AclConfig {@ Autowired DataSource dataSource; @ Bean public AclAuthorizationStrategy aclAuthorizationStrategy () {return new AclAuthorizationStrategyImpl (new SimpleGrantedAuthority ("ROLE_ADMIN"));} @ Bean public PermissionGrantingStrategy permissionGrantingStrategy () {return new DefaultPermissionGrantingStrategy (new ConsoleAuditLogger ());} @ Bean public AclCache aclCache () {return new EhCacheBasedAclCache (aclEhCacheFactoryBean (). GetObject (), permissionGrantingStrategy (), aclAuthorizationStrategy ()) } @ Bean public EhCacheFactoryBean aclEhCacheFactoryBean () {EhCacheFactoryBean ehCacheFactoryBean = new EhCacheFactoryBean (); ehCacheFactoryBean.setCacheManager (aclCacheManager (). GetObject ()); ehCacheFactoryBean.setCacheName ("aclCache"); return ehCacheFactoryBean;} @ Bean public EhCacheManagerFactoryBean aclCacheManager () {return new EhCacheManagerFactoryBean ();} @ Bean public LookupStrategy lookupStrategy () {return new BasicLookupStrategy (dataSource, aclCache (), aclAuthorizationStrategy (), new ConsoleAuditLogger ()) } @ Bean public AclService aclService () {return new JdbcMutableAclService (dataSource, lookupStrategy (), aclCache ());} @ Bean PermissionEvaluator permissionEvaluator () {AclPermissionEvaluator permissionEvaluator = new AclPermissionEvaluator (aclService ()); return permissionEvaluator;}}

The configuration of @ EnableGlobalMethodSecurity annotations means to enable the use of @ PreAuthorize, @ PostAuthorize and @ Secured annotations in the project. We will configure permissions with these annotations later.

Since a complete set of database stuff has been introduced and the database connection information has been configured, you can inject the DataSource instance for later use.

AclAuthorizationStrategy instance is used to determine whether the current authentication principal has the permission to modify Acl. To be exact, there are three permissions: modify the owner; of Acl, modify the audit information of Acl and modify the ACE itself. There is only one implementation class for this interface, which is AclAuthorizationStrategyImpl. When we create an instance, we can pass three parameters corresponding to these three permissions, or we can pass a parameter to indicate that this role can do three things.

The PermissionGrantingStrategy interface provides an isGranted method, which is the final method for real permission comparison. There is only one implementation class DefaultPermissionGrantingStrategy for this interface, and new is fine.

In the ACL system, because the rights comparison always has to query the database, resulting in performance problems, so the introduction of Ehcache cache. AclCache has two implementation classes: SpringCacheBasedAclCache and EhCacheBasedAclCache. We have introduced the ehcache instance earlier, so we can configure the EhCacheBasedAclCache instance here.

LookupStrategy can parse the corresponding Acl through ObjectIdentity. The only implementation class for LookupStrategy is BasicLookupStrategy, which can be directly new.

We have already introduced AclService above, so I won't repeat it here.

PermissionEvaluator provides support for the expression hasPermission. Since annotations such as @ PreAuthorize ("hasPermission (# noticeMessage, 'WRITE')") are used for permission control later in this case, a PermissionEvaluator instance needs to be configured.

At this point, the configuration class here has been introduced to you.

3. Plot setting

Suppose I now have a notification message class NoticeMessage, as follows:

Public class NoticeMessage {private Integer id; private String content; @ Override public String toString () {return "NoticeMessage {" + "id=" + id + ", content='" + content +'\'+'}';} public Integer getId () {return id;} public void setId (Integer id) {this.id = id } public String getContent () {return content;} public void setContent (String content) {this.content = content;}}

Then a data table is created based on this class:

CREATE TABLE `system_ message` (`id` int (11) unsigned NOT NULL AUTO_INCREMENT, `content` varchar (255) COLLATE utf8mb4_unicode_ci DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

Then the next permission control is aimed at this NoticeMessage.

Create a NoticeMessageMapper and add several test methods:

@ Mapperpublic interface NoticeMessageMapper {List findAll (); NoticeMessage findById (Integer id); void save (NoticeMessage noticeMessage); void update (NoticeMessage noticeMessage);}

The NoticeMessageMapper.xml content is as follows:

Select * from system_message; select * from system_message where id=# {id}; insert into system_message (id,content) values (# {id}, # {content}); update system_message set content = # {content} where id=# {id}

These should be easy to understand, there is nothing to say.

Next, create the NoticeMessageService as follows:

@ Servicepublic class NoticeMessageService {@ Autowired NoticeMessageMapper noticeMessageMapper; @ PostFilter ("hasPermission (filterObject, 'READ')") public List findAll () {List all = noticeMessageMapper.findAll (); return all;} @ PostAuthorize ("hasPermission (returnObject,' READ')") public NoticeMessage findById (Integer id) {return noticeMessageMapper.findById (id) } @ PreAuthorize ("hasPermission (# noticeMessage, 'CREATE')") public NoticeMessage save (NoticeMessage noticeMessage) {noticeMessageMapper.save (noticeMessage); return noticeMessage;} @ PreAuthorize ("hasPermission (# noticeMessage,' WRITE')") public void update (NoticeMessage noticeMessage) {noticeMessageMapper.update (noticeMessage);}}

Two new notes are involved, a little bit:

@ PostFilter: filter the returned collection or array after the method is executed (filter out the data for which the current user has READ permission), and returnObject represents the return value of the method. There is a corresponding annotation @ PreFilter, which allows method calls, but parameters must be filtered before entering the method.

PostAuthorize: method calls are allowed, but if the expression evaluates to false, a security exception is thrown, and # noticeMessage corresponds to the parameters of the method.

PreAuthorize: restrict access to the method based on the result of the evaluation of the expression before the method call.

Now that you understand the meaning of the comments, there should be no need to explain the above method.

The configuration is complete, and then we will test it.

4. test

To facilitate testing, we first prepare a few pieces of test data, as follows:

INSERT INTO `acl_ class` (`id`, `class`) VALUES (1memorg.javaboy.acls.model.NoticeMessage`); INSERT INTO `NoticeMessage` (`id`, `classal`, `sid`) VALUES (2meme 1meme management'), (3rem 1rem manage'), (3dome 0rem Rolekeeper EDITOR'); INSERT INTO `LJ message` (`id`, `content`) VALUES (1J 111'), (2penny 222'), (3jue 333')

First you add acl_class, then you add three Sid, two users, one role, and finally three NoticeMessage instances.

Currently, no user / role can access the three pieces of data in system_message. For example, you can't get any data by executing the following code:

@ Test@WithMockUser (roles = "EDITOR") public void test01 () {List all = noticeMessageService.findAll (); System.out.println ("all =" + all);}

> @ WithMockUser (roles = "EDITOR") means access using the EDITOR role. Brother Song, this is for convenience. Friends can also configure users for Spring Security, set relevant interfaces, and then add interfaces to Controller for testing. I won't be so troublesome here.

Now let's configure it.

First of all, I want to set up hr so that the user can read the record with id 1 in the system_message table as follows:

AutowiredNoticeMessageService noticeMessageService;@AutowiredJdbcMutableAclService jdbcMutableAclService;@Test@WithMockUser (username = "javaboy") @ Transactional@Rollback (value = false) public void test02 () {ObjectIdentity objectIdentity = new ObjectIdentityImpl (NoticeMessage.class, 1); Permission p = BasePermission.READ; MutableAcl acl = jdbcMutableAclService.createAcl (objectIdentity); acl.insertAce (acl.getEntries (). Size (), p, new PrincipalSid ("hr"), true); jdbcMutableAclService.updateAcl (acl);}

We set mock user to be javaboy, that is, after the acl is created, its owner is javaboy, but the Sid in our preset data does not have javaboy, so we automatically add a record to the acl_sid table with a value of javaboy.

In this process, records are added to the acl_entry, acl_object_identity and acl_sid tables, so transactions need to be added, and because we are executing in a unit test, in order to ensure that we can see the changes in the data in the database, we need to add the @ Rollback (value = false) annotation so that the transaction does not roll back automatically.

Inside the method, you first create ObjectIdentity and Permission objects, respectively, and then create an acl object, which adds javaboy to the acl_sid table.

Next, call the acl_insertAce method, store the ace in acl, and finally call the updateAcl method to update the acl object.

After the configuration is completed, the method is executed, and after the execution is completed, there will be a corresponding record in the database.

Next, the user can read the record with id 1 using hr. As follows:

@ Test@WithMockUser (username = "hr") public void test03 () {List all = noticeMessageService.findAll (); assertNotNull (all); assertEquals (1, all.size ()); assertEquals (1, all.get (0). GetId ()); NoticeMessage byId = noticeMessageService.findById (1); assertNotNull (byId); assertEquals (1, byId.getId ());}

Brother Song, here are two ways to demonstrate to you. First of all, we call findAll, this method will query all the data, and then the returned results will be automatically filtered, leaving only the data that the hr user has read permission, that is, the data with an id of 1; the other call is the findById method, which is passed in with an argument of 1, which is easy to understand.

If you want to use hr as a user to modify the object at this time, it is not allowed. We can continue to use the above code so that the user hr can modify the record with an id of 1, as follows:

Test@WithMockUser (username = "javaboy") @ Transactional@Rollback (value = false) public void test02 () {ObjectIdentity objectIdentity = new ObjectIdentityImpl (NoticeMessage.class, 1); Permission p = BasePermission.WRITE; MutableAcl acl = (MutableAcl) jdbcMutableAclService.readAclById (objectIdentity); acl.insertAce (acl.getEntries (). Size (), p, new PrincipalSid ("hr"), true); jdbcMutableAclService.updateAcl (acl);}

Notice that the permission is changed to WRITE permission. Since the ObjectIdentity already exists in acl, you can read the existing acl directly through the readAclById method. After the method is executed, we will test the write permission of the hr user:

Test@WithMockUser (username = "hr") public void test04 () {NoticeMessage msg = noticeMessageService.findById (1); assertNotNull (msg); assertEquals (1, msg.getId ()); msg.setContent ("javaboy-1111"); noticeMessageService.update (msg); msg = noticeMessageService.findById (1); assertNotNull (msg); assertEquals ("javaboy-1111", msg.getContent ());}

At this point, hr can use WRITE permissions to modify the object.

Suppose I now want the user manager to create a NoticeMessage with an id of 99. By default, manager does not have this permission. We can now empower him:

Test@WithMockUser (username = "javaboy") @ Transactional@Rollback (value = false) public void test02 () {ObjectIdentity objectIdentity = new ObjectIdentityImpl (NoticeMessage.class, 99); Permission p = BasePermission.CREATE; MutableAcl acl = jdbcMutableAclService.createAcl (objectIdentity); acl.insertAce (acl.getEntries (). Size (), p, new PrincipalSid ("manager"), true); jdbcMutableAclService.updateAcl (acl);}

Note that the permission here is CREATE.

Next, using manager, users can add data:

@ Test@WithMockUser (username = "manager") public void test05 () {NoticeMessage noticeMessage = new NoticeMessage (); noticeMessage.setId (99); noticeMessage.setContent ("999"); noticeMessageService.save (noticeMessage);}

At this point, you can add successfully.

Thank you for your reading, the above is the content of "how to achieve ultra-fine-grained access control in Spring Security". After the study of this article, I believe you have a deeper understanding of how to achieve ultra-fine-grained access control in Spring Security, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.