Apache Shiro - using database to read users, roles and permissions

Question

Currently I've a Swing app and I wan't to integrate Apache Shiro in order to authenticate and delegate permissions to certain roles. I've already managed to read the users from the shiro.ini file that I've created for tests, it looks something like this:

[users]
admin = 123456, Administrator

[role]
Administrator = *:*:*

However this was just for testing, now I need to read the permits from a database so I've stored in a database a table with the info I need and it looks something like this:

users (id,password,username)
userRoles (userId, role)
rolePermission (permissionID,permission,roleID)

I've been trying to understand tutorials that use a JDBC realm, however they use web applications or specials frameworks to manage their connection to the Database like Apache Derby or BoneCP, and they confuse me even more with these examples.

So what I'm asking it's how I need to configure the shiro.ini file if I wanna use a JDBC realm (with an Oracle database) and what classes the shiro.ini needs. Any examples or explanation will be appreciated!

Shantelleshantha

Before I attempt an answer, do you know how to use JDBC and do you understand relational databases? – Prosecute

@BalusC not THEY, I said online examples, yes they are pretty straightforward, whenever you use the .ini file to get the users roles and permits, but no when you want to retrieve this information from a relational database – Shantelleshantha

@SotiriosDelimanolis I'm not an expert, but to my understanding JDBC it's an application programming interface that allows you to execute operations on database from Java language – Shantelleshantha

Answer 1

The Realm interface is a

security component that can access application-specific security entities such as users, roles, and permissions to determine authentication and authorization operations.

You can implement it to interact with any source for finding users and their permissions. If you want to interact with an SQL-based database, you can do that. If you want to interact with a text file, you can do that. If you want to interact with a web service, you can do that, too.

There are two useful (almost necessary) extensions of Realm which are AuthenticatingRealm and AuthorizingRealm. They provide an interface for authentication and authorization services, respectively. AuthorizingRealm extends AuthenticatingRealm. You should extend AuthorizingRealm to implement your own authenticating and authorizing logic.

Take an example: You have a database with a table Accounts as

username | password | role 

a table Permissions as

permission_id | permission_name

and a table Account_Permissions

username | permission_id

In other words, an Account can have one role, but multiple permissions. With JDBC you can very easily query such a database and retrieve usernames, passwords, roles, and permissions. Your implementation of AuthorizingRealm would do just that and construct objects expected by Shiro's API.

Read this document on Shiro's authentication sequence to understand where the AuthenticatingRealm comes in.

As for the INI file, depending on how you implement your Realm, you would need to declare it as

myRealm = com.company.security.shiro.YourDatabaseRealm

possibly settings some properties

myRealm.databaseName = account_database

Shiro provides its own JdbcRealm class which extends AuthorizingRealm. This class makes some assumptions on the structure of your database, but you can customize it.

Prosecute

At the end I had to use BoneCP in order to provide a Data Source to Shiro, I was expecting to manage a connection without having to use any external libraries. Thank you for your patience on explaining it Was very helpful and at the end I managed to implement Shiro, and understand the concepts because of your brief over here. – Shantelleshantha

@nivde92 You're welcome. Note that the above applies regardless of the DataSource you use. There are two different layers we're talking about. – Prosecute

The example tables only reflect user-based permissions, not role-based permissions. Role-based also typically implies that a subject can have multiple roles. – Grigri