The system I am currently working on requires some role-based security, which is well catered for in the Java EE stack. The system intends to be a framework for business domain experts to write their code on top of.
However, there is also a requirement for data security. That is, what information is visible to an end user.
This effectively means reducing visibility to rows (and perhaps even columns) in the database.
We are using Hibernate for our persistence. However, we are using our own annotations so as not to expose our persistence choice to the business domain experts.
For row based security this means we could add an annotation such as @Secured at the entity level, which would cause an extra column to be added to the underlying table to constrain our selects?
For column based security, we could perhaps have @Secured to either assist in query generation, or perhaps use an aspect to filter the information returned?
I’m curious to know how this might affect hibernate’s caching mechanisms as well?
I’m sure a lot of others will have had the same issue, and I was wondering how you approached this?
Much appreciated…
Hibernate has a filter mechanism that may work for you. The filters will rewrite the queries hibernate generates to include an additional clause to limit the rows returned. I’m not aware of anything in hibernate to mask/hide columns.
Your database may also have support for this functionality. Oracle, for example, has the Virtual Private Database (VPD) which will rewrite your queries at the database level. This solution has the added benefit that any external program (e.g. reporting tools) that goes against your db will have your security restrictions enforced. VPD also has support to mask restricted columns with NULLs.
Unfortunately, the above solutions have not been adequate to support the security requirements for the types projects I typically work on. There is usually some sort of context that cannot be easily expressed in the above solutions. For example, users can view data that they have created, or that have been been marked as public, or belong to a project which they manage.
We typically create query/finder/DAO objects where we pass in the values required to enforce the security and then create the query accordingly.
I hope this helps