Spring Security provides ways to access control various permissions attached to any object. Spring Security Access Control List (ACL) stores a list of permissions associated with a domain object. It also grants these permissions to various entities that need to perform different operations on the domain object. For Spring Security to work, you need to set up four database tables, as shown in the following diagram:
Here is a small explanation of the tables in the preceding diagram:
- ACL_CLASS table: As the name suggests, it stores the domain object's class name.
- ACL_SID table: Security Identity (SID) stores either a username (testuser) or role name (ROLE_ADMIN). The PRINCIPAL column stores either 0 or 1, 0 if the SID is a username and 1 if it is a role name.
- ACL_OBJECT_IDENTITY table: It is entrusted to store object-related information and links other tables.
- ACL_ENTRY table: It stores permission granted to each SID for each OBJECT_IDENTITY.
In order for Spring Security ACL to work, it also requires a cache. One of the easiest ones to integrate with Spring is EhCache.
Spring Security ACL supports the following permissions:
- READ
- WRITE
- CREATE
- DELETE
- ADMINISTRATION
To make it work, we have to enable it using @EnableGlobalMethodSecurity(prePostEnabled = true, securedEnabled = true). We are now ready to put annotations in place to start access controlling domain objects. A code snippet in which Spring ACL is used is as follows:
@PostFilter("hasPermission(filterObject, 'READ')")
List<Record> findRecords();
After querying for records (post-filtering), the result (a list) is scrutinized, and filtering takes place to only return the object to which the user has READ permission. We can also use @PostAuthorize as follows:
@PostAuthorize("hasPermission(returnObject, 'READ')")
After execution of the method (@Post), if the user has READ access on the object, it is returned. Otherwise, it throws an AccessDeniedException exception:
@PreAuthorize("hasPermission(#movie, 'WRITE')")
Movie save(@Param("movie")Movie movie);
Before the method is fired (@Pre), it checks whether the user has the WRITE permission on the object. Here, we use the parameter being passed into the method to check for user permission. If the user has permission to WRITE, it executes the method. Otherwise, it throws an exception.
We can have a fully fledged example of this, but we are already stretched by the number of topics that this book can cover. So I will leave it just here, and I am sure you now have enough information to make a complete implementation.
Some of the common built-in Spring expressions regarding security are as follows:
|
Expression |
Description |
|
hasRole([role_name]) |
If the current user has role_name, it returns true |
|
hasAnyRole([role_name1, role_name2]) |
If the current user has any of the role names in the list, it returns true |
|
hasAuthority([authority]) |
If the current user has specified authority, it returns true |
|
hasAnyAuthority([authority1, authority2]) |
If the current user has any of the authorities in the specified list, it returns true |
|
permitAll |
Always equates to true |
|
denyAll |
Always equates to false |
|
isAnonymous() |
If the current user is anonymous, it returns true |
|
isRememberMe() |
If the current user has set remember-me, it returns true |
|
isAuthenticated() |
If the current user is not anonymous, it returns true |
|
isFullyAuthenticated() |
If the current user is not anonymous or remember-me user, it returns true |
|
hasPermission(Object target, Object permission) |
If the current user has permission to target object, it returns true |
|
hasPermission(Object targetId, Object targetType, Object permission) |
If the current user has permission to target object, it returns true |