Spring Security 3.2 - Users, Roles, Permissions - Part 5

This post builds on the code from part 4 of this series,Spring Security 3.2 - Users, Roles, Permissions - Part 4.  In this post, we will create a new package and move the exception/exception handling classes to this package in order to more easily accommodate unit testing with JUnit.  The revised directory structure and refactored class names are shown in the image below.

1. We will first create a new package, com.dtr.oas.exception.  We will then move all of the exception classes from com.dtr.oas.dao to this new package as shown in the image above.


2. Next, we will move the AccessDeniedExceptionHandler from com.dtr.oas.controller to com.dtr.oas.exception as shown in the image above.


3. The import statement in the SecurityConfig file should be updated to refer to the AccessDeniedExceptionHandler in the new package.


4. Now we will rename com.dtr.oas.DatabaseConfig to com.dtr.oas.RootConfig.


5. The import statement in the Initializer file should be updated to refer to the RootConfig file rather than the DatabaseConfig file.


6. Lastly, the component scan entry in the RootConfig file should be updated to the following.

...
import com.dtr.oas.exception.AccessDeniedExceptionHandler;

@Configuration
@EnableTransactionManagement
@ComponentScan(basePackages = {"com.dtr.oas.dao", "com.dtr.oas.model", "com.dtr.oas.service", "com.dtr.oas.util"})
@PropertySource("classpath:database.properties")
public class RootConfig {

private static final String PROPERTY_NAME_DATABASE_DRIVER   = "db.driver";
...

In the WebAppConfig.java file, all packages under "com.dtr.oas" are scanned, while in the RootConfig.java file, all packages except the "com.dtr.oas.controller" package are scanned.  The RootConfig file is used to prepare the environment for JUnit and we are not running any controller tests at this time (so we need to exclude controllers from this environment prep).  Much of this package and config reorg was to enable unit testing of the service and DTO layers.


7. At this time we should now be able to run the application and test the security configuration.  The HttpSecurity line in the SecurityConfig will keep all users not in the ADMIN role from being able to access the Strategy pages.  To test that the method level authorization is functional on the Strategy pages, we can check the database to review the pemissionname and associated id.

In the screen shot above, we can see that ID number 3 corresponds to the permissionname "CTRL_STRATEGY_EDIT_GET".  This is the permission that we want to reassign.

Now we can modify the ROLE_ID field in role_permissions table as shown in the screenshot below.

Rather than having the permission id number 3 associated with the ADMIN role, we will reassign this permission to the TRADER role.

To confirm this authorization change, log in as the admin user, go to the strategy list page and try to edit a strategy.  If the authorization update is working, the admin user should receive our custom 403 page when they try to edit a strategy.  All other strategy functionality should be working for the admin user.  After the confirmation, change the role id value back to ADMIN for our edit permission.

In the next posts, we will add CRUD functionality to our User, Role, and Permission entities.

Code at GitHub: https://github.com/dtr-trading/spring-ex14-auth