Search code examples
javaspring-securityacl

Spring Ssecurity ACL - Domain State Change

We have set up spring security project with role based authentication and role hierarchies for implicit and explicit roles. We have an additional requirement to provide different authorizations based on the status of the domain object. For example:

Order Domain Object:

  • When Order is in Initial status
    • Field 1, 2, 3 are editable by RoleA, and Viewable by RoleB
    • Fields 4, 5, 6 are editable by RoleA and Role B
  • When Order is in QA status
    • Field 1, 2, 3 are viewable by RoleA, and Editable by RoleB
    • Fields 4, 5, 6 are viewable by Role A and RoleB
  • When Order is in Completed status
    • Field 1, 2, 3 are viewable by RoleA, and viewable by RoleB
    • Fields 4, 5, 6 are viewable by RoleA and RoleB

The standard spring security URL level security we have with ant matchers is not sufficient to handle the authorization requirements as the same service URLs are used to view (GET) and save (PUT) the order domain objects if they are in any state. We are also looking to make the process configurable for which fields are in each permission set.

The Spring Domain Object Security looks like it applies to domain objects where the state is fixed or constant – blog entries created by a specific user, etc...
Can this requirement be handled by Spring Domain Object Security, or should this better handled with custom code / configuration?

Solution

  • You are quite correct. The Spring Security permission evaluator and ACL infrastructure works on domain object level, not field level. You could create permissions like EDIT_FIELD1, EDIT_FIELD2, VIEW_FIELD1 and so on, but it feels a litte bit forced. Of course you can use other Spring Security infrastructure with @PreAuthorize annotations etc, and extending with your custom code.

    If you have some faith in the users and are allowed to loose on the security, I would suggest skip field level, and only evaluate on order status and role. You probably want some audit log of who is editing what anyway. Fields can be dimmed in user interface to avoid accidental editing. I have seen workflow applications function this way.