Hi there,

This is a bit of an general question but..

We have just implemented a clean, transparent domain POJO layer for our application and developed Hibernate DAOs for persistence. Right now our application has no security. No we're not live yet. ;-) We have several kinds of authorization requirements.

1. Service layer authorizations -> Can principal x execute service method y and in context z.

We could handle this easily with traditional security frameworks (Acegi etc) or aspects, or custom security logic in the service.

2. Group or owner based domain object authorizations -> Can principal x with roles y create, read, update, delete domain object z

We can handle this reasonably with some a custom Hibernate access interceptor as in http://www.hibernate.org/140.html. This will let us protect CRUD operations on an object based on the relationship between the principal and the domain object.

But how could we handle...

3. ... Domain object security -> Can principal x change field y on domain object z

ie. Assuming we want to keep our domain objects as transparent as possible (small transparency losses accepted if necessary) how can we protect a domain objects fields from illegal modification or throw some kind of security exception if the hibernate DAO is asked to save a POJO where the client modified a field they didn't have access to modify. This is particular relevant if we have fields for auditing for example (eg. http://www.hibernate.org/195.html)


There is an easier and a harder problem to solve.

a) Assuming a non-distributed environment our problems seems simpler. We can make do with some way to perform access checking on the domain objects in the client layer and we completely control all access to the domain POJOs within our containers.

b) In a future scenario though we may have distributed clients and want to know that clients aren't bypassing our security restrictions when they pass remoted domain POJOs back into our service layer for updating..

Thanks in advance for any hints and tips.. :-)

Regards,
Damon Rand

Probably trigger can solve this problem. It is trivial and more secure than client side authorization, is not it ?
Domain object security -> Can principal x change field y on domain object z ->
Can current_user x change field y on table z.