Spring security Access Control List Billions of rows

Question

Implementing security solution based on spring security framework particularly its acl modules.
There are millions of domain objects and some hundreds of users in the application.

Using Spring Security Acl module the entry in acl_sid and other related tables grows to 10's of billions which impacts the performance of the application.

Would like to know the best practice for handling such scenarios.

Are there any alternative security framework available which deals with similar situation in efficient way.

Answer 1

There are several frameworks that make access control more manageable.

First of all, ACLs are great and easy to configure but they do not scale well.

Option #1: Role-based Access Control (RBAC)

RBAC is a well-known model having been defined by NIST in 1992. Many applications and frameworks implement an RBAC model. In RBAC, you give users a set of roles and each role has a set of permissions. As a consequence, users inherit those permissions. You can for instance have a manager role with the permission to view all transactions.

Spring Security, Apache Shiro, JAAS, and many other frameworks (open-source, commercial...) implement RBAC.

Option #2: Attribute-based Access Control (ABAC)

Sometimes RBAC is not enough. In particular when you want to use context or relationships. For instance, in RBAC, it is hard to implement roles and permissions that would handle the following:

Managers can view transactions in their own department

To do that you would use ABAC. You would define a role attribute, a user department attribute, and a transaction department attribute. You would then combine the attributes together in a policy:

A user with the role==manager can do the action=='view transaction' if user.department==transaction.department

XACML - an implementation of ABAC

XACML, the eXtensible Access Control Markup Language, is a standard defined by OASIS and increasingly used to implement complex authorization challenges. There are several implementations today:

• Open source
  • SunXACML
  • WSO2
• Commercial
  • Axiomatics.

How do RBAC and ABAC reduce the management burden?

In access control lists, you have a list per item you want to protect and you have to insert user identities in those lists. You may also want to add action data so you end up with:

• Item #1 ACL
  • Alice, read
  • Alice, write
  • Bob, read
  • Carol, read
• Item #2
  • ...

If you have 1 million items and 10,000 users, you have a potential of 1 million x 10k x 3 actions (read, write, delete) = a grand total of 30 billion lines. That equates to a management nightmare but also potentially a performance issue.

Now the idea with RBAC was to streamline that a bit. Instead of assigning users to items in ACLs, we use roles and permissions as a level of indirection. So Alice would be an editor. Bob and Carol would be viewers. Your ACLs are now simpler:

• Item #1
  • Editor, read
  • Editor, edit
  • Viewer, read

The list is growing smaller. Yet RBAC still have several issues. It still has to have an ACL per object. If you have a million objects, you will still have a few million rows (still better than 30 billion though).

With ABAC, you choose to use object attributes e.g. the department or the classification. Objects no longer have ACLs and you end up writing policies that use these attributes. This makes the number of policies smaller (in the hundreds typically).

Thanks to attributes, ABAC scales better.