Hi there,

I'm currently evaluating Hibernate to use it as a replacement for entity EJBs with CMP, and there's only one thing that keeps me from doing it.

Whenever I have used entity EJBs, I have used them to implement a domain model for the application, this is, the entities found in the application, with its attributes, relations, and possibly, business behavior. An example: suppose you have an internal purchase system and you have orders in that system. The corresponding EJB would have a create method for sending a new order, several attributes, relation with the lines in the order, and methods so an approver can approve or reject an order.

Where's the problem? A domain model almost always have related security constraints: only a purchaser may create an order, only an approver may approve or reject an order, maybe the order must pass a workflow, so you must check the approver trying to approve or reject the order is really the next in the workflow...

In the EJB world, you have access to the EntityContext, so you can extract information about the user calling the method, the roles that user belongs to, and made decissions based on that.

What are the best practices to do that using Hibernate? Has anyone faced this problem? How have you solved it?

Some possible solutions I'm considering:

Using the session facade pattern, maybe passing information related to user in method call

May JAAS be used here? I don't know that much about it

Use AOP to intercept message calls to methods with security contraints. Is this possible? Should this interfere with Hibernate?

Use an entitlement engine. I only have heard of the one in OpenSymphony. Anyone has used it? Is there any other open source implementation of an entitlement engine?

Any comments on this would be greatly appreciated.

Regards
Jose

If you need method level authorization you can use AOP framework like nanning (or implement proxy configuration yourself) for declarative authorization definitions and use JAAS for authentication.
You can implement custom LoginModule, it can use authenticated user fom EJB context too.
JAAS is used to retrieve roles for current thread. Your "aspect" will use "current roles" and metadata for security checks. You can use "current user" outside "aspect", if you need something like row level authorization too.
If you will implement security this way, you can reuse and test your app without container. JAAS LoginModules are pluggable and you can delegate authentication for container or authenticate user yourself.
I have used this way for security implementation, but it was not very trivial to learn JAAS and implement this stuff. It can be a good candidate for a new open source experiment/framework too :)

baliukas,

Are you actually using Nanning? I checked it out after reading your message, but there's very little documentation. Seems interesting, though. If possible, could you give us a little information about how you are using it? Do you have to create a parallel class hierarchy of nanning proxy objects?

Thanks,
David

Depends on the complexity of your security requirements. If you need really simplisitic security constraints like those provided OOTB with J2EE, then an implementation around the domain model via interceptors itself is probably viable This is the general approach in implementing J2EE security itself (either placed into the generated EJB code or done through AOP).

The other option is to wrap access to your domain objects in a service layer (whether implemented via SessionFacade pattern or POJO). I use this approach in my apps built using Hibernate. Basically, my setup is to utilize JAAS for authorization. My services then utilize a delegation strategy to an implementation of an interface I call UserResolver. Impls of this interface know you to resolve the current user in given contexts (so I have one specific for WebLogic, testing, etc...). The services use the delegation strategy to "lookup" the current user and then call into an entitlement engine to determine whether that user can perform the requested action.

The entitlement engine is something I wrote. I also looked at OSAccess (the one from OpenSymphony). It basically gives you caching of the entitlements, but really gives you no help in terms of how/when that cache gets populated.

HTH

So summing up, the solution involves a mix of all the alternatives I was considering :o)

After taking a look at JAAS I had the following thoughts. Comments are welcome:

First of all, the user may be authenticated using a LoginContext. This LoginContext may simply delegate to the EJB container (if running in an EJB environment) and extract the Principal from there (Is this possible? How to access the context?). It would be desirable to include in the returned Subject after successful authentication the information about roles of the user, as java.security.acl.Group objects. There is only one problem, the current J2EE API doesn't let you get the roles of an user, only check if the user is included in that role. Why is this desirable? In this case, we could write a policy file using groups or roles as principals in every grant, and maybe use class names and method signatures as object and actions of custom permissions, to achieve a per method authorization using JAAS directly. What do you think about this? Am I making any wrong assumption?

Regards
Jose

Take a look at the following two URLs:
http://www.hibernate.org/139.html
http://www.hibernate.org/140.html

They discuss some very cool uses of Hibernate with JAAS.

I have only recently gotten started with JAAS and do not yet understand all the ins and outs. JAAS supports Subjects which is a collection of Principals. Groups in-and-of themselves are just Principals, so theoretically you could assign Groups to the Subject in your LoginModule as one of the Principal.

The problem I always struggle with in these types of setups though is the concept we call "derived groups". For example we have one domain entity named Course; a Course has an attribute called eligibilityLevel which defines for whom the Course is available. Certain groups can always modify all courses, but there are other groups which can edit the course based upon what the eligibility level of it is. And the same rules for all TrainingClasses generated from that Course. In most of these declarative security setups, the only option is to capture the fact that during persistence of a course that the eligibility level of it changed and then to manually update all the permissions for that course (as well as all the training classes for that course, etc). Thats just not really a viable approach.

So basically we partition our entitlement granting into two types:
1) defined declaratively;
2) defined using rules which are java classes which take the user and the use-case they are trying to execute (along with possibly some context information) and determine if they should be granted entitlement to perform the use case.

Very interesting.

I've been searching for more information and I have found this IBM article that explains how to change the default policy so you may use a custom policy source (in this case a XML file) and add custom instance level authorizations. The article shows how to implement permissions based on ownership of an instance and relations between instances. This could be used as the seed of a generic entitlement engine based on JAAS. I'm very interested in this stuff, as I think this could be a perfect addition to a transparent persistence engine like Hibernate (at least, I would love to have something like that out of the box). I think the missing ingredient in this soup may be AOP. The only drawback I see right now is that this forces to change the policy used in the JVM, and this could be conflictive if the application is run on a server that already uses a custom policy.

I'll try to keep working on this and keep you informed of my progress, if you are interested. I would be glad to try to implement those scenarios you are talking about, to test the validity of this approach.

Regards
Jose

You will need to implement Policy, if you are going to store permissions in DB and need to grant them at runtime. I use role based method level authorization with default Policy implementation, I do not use SecurityManager for entity level authorization, I use hardcoded entity level authorization in DAO and JAAS is used to retrieve "current principals" only .
I think it is better to use Stored Procedures for secure system, if you are not going to migrate forn X to Y RDBMS.
Authorization on client is secure if you have single client on DB, but it can be used for trivial systems only.

In my view, you should protect the processes rather than the data.

During analysis you identity the use cases (processes) and the roles. Then you can decide what role has access to which use case.

Security constraints are evaluated in our services methods (would it be session beans or something else), which in turn modify the domain entities. This implies our domain entities do not contain any business logic.

One consequence is we don't need any support from the persistence layer to enforce the access control.

I believe it is bad practice to try to implement the access control at the level of domain entities...

... my little contribution to the thread ...

If you are using all this protected code from just on place (i.e: a controller in a webapp) then I would agree with you. the most common aproach I've seen is using JAAS along with declarative security on the web tier and leaving the domain EJB's without security.

But what about if you have different clients? If you don't have authorization at domain level (like in EJB), you would probably find yourself duplicating this logic for each client that uses your domain objects and

Comments are welcome!

The idea is of course to avoid code duplication - and business logic is certainly one of the best piece of code you shouldn't code twice in your application...

EJB or not EJB is just a technological decision for me. You can architect your application in different logical layers - separating presentation and business (with a set of adapters between the two if needed).

The security constraints would fit just in front of your business layer (the first step inside actually).

If you have multiple clients, I don't see why you cannot reuse the same business layer but with another presentation? It is just a matter of interfacing and passing user identification to the business...



I'm not an expert (yet ;-), but my experience as shown that security is often one of the latest points addressed in software development. As a result, the business has not been thought/developped with this in mind. Often people reduce the security down to simple menu activation/deactivation... therefore security code ends-up in the presentation.
This approach doesn't work anymore when you have requirements for different types of clients on top of the same business...
Moreover, some security scenarios cannot be implemented this way. What if you have constraints like: users in role A can only retrieve information of airports in their country, while others can see all airports in every countries
Would you code this filtering logic in your presentation? Hmm... you will probably have the same constraint for update... Too bad.

As I said, I don't have enough experience yet to discuss this topic into deeper details (and my english isn't good enough), but I remember what someone told me once: a good application is first an application that runs and satisfies the customer ;-) So whatever approach you take, provided it does the job, it is already a good approach...


-bertrand

It is more "interesting" if not all of your clients are JAVA applications ...

Don't see your point. What's more intresting in this case - having security in the web tier or business tier ?

Both are useles for this kind of systems,
there are a few alternatatyves in this case:
1. Move "business tier" to DB as stored procedures.
2. Workaround known as "Bridge"
3. Implement security on client side for all application types and run "trusted" applications only.

But it is not a problem if "system" is a web application connected to Db and this kind of applications uses authorization in both tiers: hide menu in web tier and throw exeption in business tier, I asume entities and data structures are not the "business tier".