Home » Modeling » EMF » [CDO] Define fine grained object access with CDO security model ?(By using ObjectFilter, ExpressionFilter and combined expressions ?)
| | |
Re: [CDO] Define fine grained object access with CDO security model ? [message #1143286 is a reply to message #1142741] |
Fri, 18 October 2013 05:05 |
|
Am 17.10.2013 22:42, schrieb Laurent Le Moux:
> Hi Eike,
>
> I see my example wasn't clear enough.
> I just want to restrict access to the actors created by the administrator.
> Users may define, modify and suppress their own ones.
>
> From the security model, I indeed understand that a ClassFilter read access will apply to Actor::application(s) as
> well as Actor::name.
>
> As I need to be more fine grained and apply my control depending on the actor instance (for 'Client' and 'Agent'
> only), I wonder if using an ObjectFilter would be the right way ?
Yes.
>
> I could have my Actor EClass inherit from the ObjectFilter one and implement isApplicable().
Yes, that would be one way of doing it.
You could, as you suggested in your first mail, use an ExpressionFilter. Please note that those are brand new and
totally untested. Feedback is welcome ;-)
An easier solution would be if you store the objects you want to protect in a separate resource and use ResourceFilter
to define the permissions.
> The implementation would - for example - check the object creator.
> Would it be the administrator, I should return true or false depending on the modified feature
That's not how it's designed to work. Permissions (access levels) are determined and assigned at an object granule, not
a feature granule.
> and how's trying to modify it.
You mean *who* ? In ResourceFilterImpl.getMatchers() is an example on how to use PermissionFilterImpl.getUser().
>
> So the question would be : how do I know what feature is about to be modified and by who ?
See above.
> I would probably need to be notified by some kind of event.
These events (logon/authenticate, load revision, commit transaction) arrive internally in the SecurityManager:
org.eclipse.emf.cdo.server.internal.security.SecurityManager.Authenticator.authenticate()
org.eclipse.emf.cdo.server.internal.security.SecurityManager.PermissionManager.getPermission()
org.eclipse.emf.cdo.server.internal.security.SecurityManager.WriteAccessHandler.handleTransactionBeforeCommitting()
You only interface with this framework through PermissionFilter.isApplicable().
>
> Moreover - to be more efficient - it would probably be better not to wait for transaction commit to determine whether
> the modification may be performed or not...
Indeed the commit checking is just like the "last line of defense". When you client loads the objects (more exactly the
CDORevisions) the permissions are already assigned and you can call CDOObject.cdoPermission() to use them locally.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO] Define fine grained object access with CDO security model ? [message #1143634 is a reply to message #1143286] |
Fri, 18 October 2013 10:14 |
Laurent Le Moux Messages: 184 Registered: September 2011 |
Senior Member |
|
|
If I understand well, to get a feature level authorisation for any object, this would imply a combined usage of CDO security model with an evolution on EMF.Edit side ?
We could imagine in .genmodel to have - in the edit part of each feature - a new 'Enable access authorisation' flag.
If true, the EMF.Edit internals would check authorisation based on a public list of permissions containing [Feature, Role, Access, Rule] (OCLRule could even extend Rule...).
Default behavior would be R/W (as today).
On CDO side, the administrator could edit permissions as any other attribute of the selected object.
In my use case, this would mean :
- Add a permission to both 'Client' and 'Agent' where : Feature = Actor.ACTOR__NAME, Role='Restricted Object Access', Access = R and Rule = None.
To be exhaustive, EMF.Edit could offer the same mechanism at object and corresponding EClass levels (with the due priorities).
Regards,
Laurent
|
|
|
Re: [CDO] Define fine grained object access with CDO security model ? [message #1146282 is a reply to message #1143634] |
Sun, 20 October 2013 03:53 |
|
Am 18.10.2013 12:14, schrieb Laurent Le Moux:
> If I understand well, to get a feature level authorisation for any object, this would imply a combined usage of CDO
> security model with an evolution on EMF.Edit side ?
Not sure what you're trying to suggest, but CDO has almost no "feature-level anything", e.g., no feature-level loading,
locking or permission checking. There's no infrastructure for this and I don't think that this infrastructure will
appear anytime soon.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> We could imagine in .genmodel to have - in the edit part of each feature - a new 'Enable access authorisation' flag.
>
> If true, the EMF.Edit internals would check authorisation based on a public list of permissions containing [Feature,
> Role, Access, Rule] (OCLRule could even extend Rule...).
> Default behavior would be R/W (as today).
>
> On CDO side, the administrator could edit permissions as any other attribute of the selected object.
>
> In my use case, this would mean :
> - Add a permission to both 'Client' and 'Agent' where : Feature = Actor.ACTOR__NAME, Role='Restricted Object Access',
> Access = R and Rule = None.
>
> To be exhaustive, EMF.Edit could offer the same mechanism at object and corresponding EClass levels (with the due
> priorities).
>
> Regards,
>
> Laurent
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| | | | | | | | |
Goto Forum:
Current Time: Thu Sep 19 06:00:02 GMT 2024
Powered by FUDForum. Page generated in 0.05219 seconds
|