I am using NHibernate quite nicely in my (asp.net) application using the Session per request pattern.

Now I am trying to apply some security. I want to be able to check that a user is in a specific role before saving. This works nicely when saving a new object, but when the object is already in session you can just update the object and the changes will be saved when flush is called at the end of the request.

Is there some sort of generally accepted way of applying the kind of security I am talking about? The only thing I can think of is that I will need to kick the object out of session after loading it but that seems pretty clunky.

Thanks,
Derek

Errr. Hrmm. If (userLevel < 2) { Messagebox.Show("You do not have permissions to save this user to the DB");} else { session.SaveOrUpdate(User); }

Well yeah you can do that but I don't want my security to be dependent on the UI implementing it.

My UI calls into another layer to perform save/update and I do peform checks there but when you have an object that is already in session there is nothing stoping you from updating a property and then having that change saved the next time flush is called.
How do you check security in that scenario?

Maybe you indicate that the object shouldn't be flushed by evaluating the user permissions against each object that passes through the FindDirty method in an interceptor?

Not sure it would work, but it's a thought...

Symon.

You need to restrict visibility to the set method of the property (make it protected) and control all access through a set method in which you check security, or check security within the set method of the property.

Instead of checking Context.User to get the user's roles, you can use the PrincipalPermission attribute on all of your setter methods.



With this attribute set, ASP.Net will throw an exception if the calling code isn't in the specified role. If you aren't using Windows authentication, you will also need to either use a Roles Provider or manually set Context.User to a new GenericPrincipal object so that ASP.Net can determine what roles a user is in. Sometimes it's useful, sometimes not as much.

All of our entities (which are generated) implement an interface that defines a Strategy property (Strategy pattern, GoF Design Patterns book). Our entity factory (for new, transient instances) and our NHibernate interceptor (for new, persistent instances) create the appropriate, customizable strategy class if one has been configured for the entity type (or a vanilla base strategy if none has been configured), and attaches it to the entity.

The strategy classes (which live in the BLL) also implement an interface, and one of the methods is Validate(). Our interceptor calls this method in PreFlush() on all entities that are dirty or transient. The developer of the strategy class (where the business logic is) can then raise exceptions (or call other methods that raise exceptions) if the entity is not in a valid state for persisting back to the database (or the user does not have the security permission to do so).

Note that this approach is different than the deprecated ILifecycle interface, since the Validate() method is not on the actual entity. this allows the entities to be plain-old C# objects which can also serve as DTOs (when transferring to another layer that shouldn't have access to the strategy, the entities can be cloned and the Strategy property left null).

Thanks merge_s.rottem and Nels_P_Olsen. This sounds like a pretty good solution that I will try to implement.

@JWLato
I hadn't thought about doing it that way. It's nice in that it is simple, but I am using the Security Application block for this project (it has a nice model for breaking tasks into rules that can then be assigned to roles), and as far as I know you can't use CAS style attributes for it.

Cheers for the help guys.
Derek