Imagine that you have to do a permission check when a user sets a new price for an item, let's say in an online shopping application. I'd design this security aspect from the bottom up, lowest layer first. - Model layer: Checking UPDATE and INSERT with the lifecycle callbacks is too coarse-grained. Sometimes a user can update an item, but not set a new price. Even if you use programmatic security, e.g. calling Seam Identity.hasPermission() in the Item.setPrice() accessor method, you run into issues with exception handling in the APPLY MODEL VALUES phase. - Controller layer: You can do fine-grained checking on and in the methods of your action/controller components. But you again don't get a chance to intercept Item.setPrice() if this property is bound directly to a JSF widget. Of course, you could check in ItemController.setItemPrice() if the price was modified, and then call Identity.hasPermission(), but that is just too much work: you need to bind the JSF widget to a controller property instead of directly to the entity, and then manually copy the property from and to the entity instance after doing your permission checking. This copying is especially tricky if we are talking about lists of objects and Hibernates collection wrappers (you often have to clear() a collection before re-filling it, causing massive DELETE and INSERT on the SQL level). - View layer: You can of course hide the JSF text input widget that binds to item.price if the user isn't allowed to change the price. That doesn't stop the users from messing with your request parameters. Or am I wrong and there is effectively no way in JSF to sneak in some request parameters that set the price on the model? Even with client-side state saving? So we don't really have a convenient strategy for this quite common scenario, or I missed something. We should work on a solution and document it in the Security chapter. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4029155#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...