Spring Security 3: Full ACL Tutorial (Part 4)

In Part 1 of this tutorial we've completed setting up the ACL and Bulletin databases. In Part 2 we've completed the Spring Security configuration. In Part 3 we've developed the Spring MVC module of the application. In Part 4 we'll be testing and running the application. We'll also cover some of the unexpected issues we've encountered while developing the system.

Part 1: Functional Specs and the Application Database
Part 2: Spring Security Configuration
Part 3: Spring MVC Module
Part 4: Running the Application

Run the Application

We've completed all the necessary elements of the application. It's time to run it and check the results.

The Admin

We'll login first as an admin and check which actions are allowed to us.

Here are the steps:
1. Visit the login page at http://localhost:8080/spring-security-full-acl/krams/auth/login

2. Enter the following username and password:

username: john
password: admin

3. After a successful login, we should see the following:

Notice the current user is john with the following roles: ROLE_ADMIN, ROLE_USER, and ROLE_VISITOR. As an admin, we're allowed to see all posts in the Bulletin application.

4. Now let's try editing a post. Select post #2 and click Edit. We should see the following page:

Notice we're allowed to edit the post. That's because in the ACL database we've declared a permission for AdminPost object with object_identity_id of 2 that corresponds to the primary id of the admin_post table in the Bulletin database.

5. Edit the message then click Save.

We should see a success message.

6. Go back to the main page either by pressing the back button twice in your browser or typing the following url:

http://localhost:8080/spring-security-full-acl/krams/bulletin/view

7. Again on the Admin Posts, click on any of the Add links. We should see the following page:

8. Type a new message. Then click Save.

Notice the new posts has been added successfully.

9. Go back to the main page.

10. Again on the Admin Posts, select the post #1 and click on Delete. The post will be deleted automatically with the following confirmation page:

So far everything works as expected. Now try viewing the main page. You'll notice that we've managed to delete the first post. Edit the second post. But the fourth post we added is nowhere to be found!

Let's check the Bulletin database if the new posts has been added really.

The database shows that the fourth post has been added. But how come it doesn't show on the Bulletin application? That's because we haven't declared it yet in the ACL database. We also haven't configured the permissions for this record. We'll discuss this again in the Unexpected Problems section

11. Now let's check the Personal Post. Try adding, editing, or deleting any of the posts. Notice in all actions you will be denied with the following message:

It works as expected.

12. Now let's check the Public Post. Try adding, editing, or deleting any of the posts. Notice it works exactly the same as with the Admin Post, and also shows the same behavior when adding a new posts.

The User

After logging-in as an admin, we'll login next as a regular user and check which actions are allowed to us.

Here are the steps:
1. Visit the login page at http://localhost:8080/spring-security-full-acl/krams/auth/login

2. Enter the following username and password:

username: jane
password: user

3. After a successful login, we should see the following:

Notice the current user is jane with the following roles: ROLE_USER and ROLE_VISITOR. As a regular user, we're allowed to see all posts, except the Admin Posts, in the Bulletin application.

The Visitor

Lastly we'll login as a visitor and check which actions are allowed to us.

Here are the steps:
1. Visit the login page at http://localhost:8080/spring-security-full-acl/krams/auth/login

2. Enter the following username and password:

username: mike
password: visitor

3. After a successful login, we should see the following:

Notice the current user is mike with the following roles: ROLE_VISITOR. As a visitor, we're allowed to see only the visitor posts in the Bulletin application.

Unexpected Problems

If you'd been following the whole implementations closely, you'll discover the following issues:

Issue #1: Bit mask permission doesn't work as expected
When declaring permissions in the database, we're required to declare permissions as bit masks.

- Bit mask "1" (0001 in binary) is interpreted as "READ" access
- Bit mask "2" (0010 in binary) is interpreted as "WRITE" access.

Naturally declaring bit mask "3" (0011) should be interpreted as READ and WRITE access. But it's not. Why? Because AclImpl compares the values by normal equality comparison instead of performing an actual bitwise comparison!

To solve this issue, we can implement our own AclImpl. We'll cover this in future tutorials.

Issue #2: We're stuck with the default READ and WRITE permissions
When declaring Expression-based access control we're forced with the default READ and WRITE access. What if we would like to declare our own permission like READWRITE?

The reason for this behavior is that the by default the AclPermissionEvaluator relies on the DefaultPermissionFactory which by default uses the BasePermission implementation.

Let's examine the BasePermission class:

public class BasePermission extends AbstractPermission {
    public static final Permission READ = new BasePermission(1 << 0, 'R'); // 1
    public static final Permission WRITE = new BasePermission(1 << 1, 'W'); // 2
    public static final Permission CREATE = new BasePermission(1 << 2, 'C'); // 4
    public static final Permission DELETE = new BasePermission(1 << 3, 'D'); // 8
    public static final Permission ADMINISTRATION = new BasePermission(1 << 4, 'A'); // 16

...
}

Notice by default it declares a READ, WRITE, CREATE, DELETE, ADMINISTRATION permissions.

To solve this issue, we can extend the BasePermission. Again, we'll cover this in future tutorials.

Issue #3: New posts are not shown on the View all page
When we create a new post, the system will only allow us if we have the correct permission. However, we don't see our new posts in the View page. That's because the new post objects weren't recorded in the ACL database. If the objects do not exist, we don't get any permission.

To solve this issue, we need to incorporate the ACL service within the posts services. And again, we'll cover this in future tutorials.

Conclusion

That's it. We've completed our Bulletin application. We've successfully implemented an ACL system using Spring Security 3. We've explored how to apply expression-based access controls and explain in detail all the important elements in the system.

The best way to learn further is to try the actual application.

Download the project
You can access the project site at Google's Project Hosting at http://code.google.com/p/spring-security-acl-expression/

You can download the project as a Maven build. Look for the spring-security-full-acl.zip in the Download sections.

You can run the project directly using an embedded server via Maven.
For Tomcat: mvn tomcat:run
For Jetty: mvn jetty:run

---

Share the joy: blogger tutorials Social Bookmarking Blogger Widget I'm reading: Spring Security 3: Full ACL Tutorial (Part 4) ~

Subscribe by reader Subscribe by email Share