* Name of the class

* Name of the property or method

* Read

* Write

* (Delete - this is only for entries that belong to to the class)

* (Execute - only for methods)

These access rights can be assigned to roles and roles will be assigned to users which would give me the possibility to define access perfectly.

I already looked into your documentation but I am not really sure what is the best way to apply this security scheme. I would prefer an approach where I only need to maintain this at a single place (maybe some kind of a global interceptor?).

Good question. For the properties, you could use either http://drc.ideablade.com/xwiki/bin/view/Documentation/dynamic-interception - dynamic property interceptors  or http://drc.ideablade.com/xwiki/bin/view/Documentation/validation-create-custom-verifier - dynamic verifiers . You can put the setup code for this in the base class of the entities. In the implementation of the interceptors/verifiers, you would refer to your security service that checks for roles on the Thread.CurrentPrincipal, which returns your custom UserBase class that was set up on login.

You will probably also want to drive the UI from the security itself. So your ViewModel might also contain properties that automatically (when bound) make certain controls read-only or non-visible if the user does not have the proper permissions.

For methods, you could call a base class implementation that checks security first. However, you'd probably want the UI to gray out or hide the button before even getting there.

Managing and provisioning such fine grained access control can be quite a lot of work (separate from the code that enforces the policy), so I don't know if there are alternative strategies that may make sense to consider.

Our professional services team is much better equipped to handle architectural questions like this, so if you'd like more help, we can put you in touch with them and they can advise on the implementation.

I think that the dynamic verifiers are not that good for my purpose as they would not be used automatically when the properties are read (so they won't work for read security). I will probably go for the dynamic property interceptors on the server and use some factory method on the client to inject custom attributes/functions into the view model for the properties that I don't want to show (so they won't get data from the server but to hide them I would add something to them).