Instance Access Control in Apache Shiro

Question

I found a truly flexible Apache Shiro security system. I have successfully authenticated and authorized using Shiro.

One attractive feature of the platform is instance-based security. I just copied the example from the Shiro website.

The following permissions are stored in the database.

printer:query:lp7200 printer:print:epsoncolor 

The following code checks to see if there is a current authenticated user for this printer instance.

 if ( SecurityUtils.getSubject().isPermitted("printer:query:lp7200") { // Return the current jobs on printer lp7200 } 

My question is, "Is this how the permissions are stored in the database?" Is there a better way to store instance-based rights?

Please let me know.

thanks

Answer 1

How you store this information is entirely up to you. Your Realm implementation is responsible for querying any data source that you use and retrieving permission data in the preferred format.

Some people store them as strings directly (for example, those shown in your example), other people store them in a dedicated table (for example, when using an RDBMS) (for example, allow_type, target, actions columns). You can associate permission objects with roles or directly with users or groups that are assigned to users, etc. - however, this makes sense for your application.

Your storage options are completely up to you. You are materializing the data, however you want to provide the Realm.isPermitted(...) operations function as expected.

Instead of using the Realm.isPermitted(...) methods directly, it’s more convenient for many people to subclass the abstract class AuthorizingRealm and override the doGetAuthorizationInfo method and return AuthorizationInfo instances that support permissions.

In this method, you can query your data store, transfer the data returned to the AuthorizationInfo instances, and you will do it (do not forget to enable authorization caching - you will see a big performance benefit).

Overriding Realm isPermitted methods is only necessary if you require special control over requests, etc.