Home » Modeling » EMF » Permissions on EMF model classes
|
| Re: Permissions on EMF model classes [message #1075297 is a reply to message #1074652] |
Mon, 29 July 2013 03:36   |
Eclipse User |
|
|
|
Mauro,
Comments below.
On 27/07/2013 12:48 PM, Mauro Condarelli wrote:
> Hi,
> I need to implement some kind of security in my model, allowing
> certain users to see, add or otherwise manipulate some parts of the
> models on a selective basis.
>
> I've seen there's some SecurityManager in CDO, but I'm using a plain
> EMF model.
>
> Is there any provision for that? (I was unable to find anything)
No.
> In my requirements I have security attached to single EClass, in the
> form of a set of "classification indexes", if the currently logged-in
> user had "classification clearance" matching (or exceeding) them then
> he is granted access to EClass.
I see.
>
> I know I could hand-modify my eclasses (or a common ancestor) to
> implement a certain security interface (possibly as static methods,
> since "classification indexes" do not depend on instance), but I was
> wondering if there is a "standard way" to implement security checking.
How is the information stored? I.e., is the storage itself secure? Does
this security need to be just in the UI, or does in need this support in
terms of the programmatic API?
>
> Regards
> Mauro
|
|
|
| Re: Permissions on EMF model classes [message #1075423 is a reply to message #1075297] |
Mon, 29 July 2013 07:56 |
| Eclipse User |
|
|
|
Hi Ed,
comments inline.
On 29/07/2013 09:36, Ed Merks wrote:
> Mauro,
>
> Comments below.
>
> On 27/07/2013 12:48 PM, Mauro Condarelli wrote:
>> Hi,
>> I need to implement some kind of security in my model, allowing
>> certain users to see, add or otherwise manipulate some parts of the
>> models on a selective basis.
>>
>> I've seen there's some SecurityManager in CDO, but I'm using a plain
>> EMF model.
>>
>> Is there any provision for that? (I was unable to find anything)
> No.
>> In my requirements I have security attached to single EClass, in the
>> form of a set of "classification indexes", if the currently logged-in
>> user had "classification clearance" matching (or exceeding) them then
>> he is granted access to EClass.
> I see.
>>
>> I know I could hand-modify my eclasses (or a common ancestor) to
>> implement a certain security interface (possibly as static methods,
>> since "classification indexes" do not depend on instance), but I was
>> wondering if there is a "standard way" to implement security checking.
> How is the information stored? I.e., is the storage itself secure? Does
> this security need to be just in the UI, or does in need this support in
> terms of the programmatic API?
I am now testing with a standard XMI backstore (and I don't know how to
store permissions there).
Final backstore will be on some kind of Database, but I am not
interested in that because my Customer will replace current
model.load()/model.store() with his own versions; i.e.: I will deliver
an XMI-based version.
I assume this means it is a UI-only problem, but I would like to handle
it at the lowest possible level and avoid scattering permission checks
beside each widget (I am using JavaFX and Tom's new JFX bindings).
I don't know how to attach some information to model classes (as opposed
to model class instances).
This information (the permission levels) should be changeable and
contained in the XMI file, somehow. Certainly should be part of
save/restore.
Regards
Mauro
|
|
|
| Re: Permissions on EMF model classes [message #1075427 is a reply to message #1075423] |
Mon, 29 July 2013 08:10 |
| Eclipse User |
|
|
|
Mauro,
Comments below.
On 29/07/2013 1:56 PM, Mauro Candarelli wrote:
> Hi Ed,
> comments inline.
>
> On 29/07/2013 09:36, Ed Merks wrote:
>> Mauro,
>>
>> Comments below.
>>
>> On 27/07/2013 12:48 PM, Mauro Condarelli wrote:
>>> Hi,
>>> I need to implement some kind of security in my model, allowing
>>> certain users to see, add or otherwise manipulate some parts of the
>>> models on a selective basis.
>>>
>>> I've seen there's some SecurityManager in CDO, but I'm using a plain
>>> EMF model.
>>>
>>> Is there any provision for that? (I was unable to find anything)
>> No.
>>> In my requirements I have security attached to single EClass, in the
>>> form of a set of "classification indexes", if the currently logged-in
>>> user had "classification clearance" matching (or exceeding) them then
>>> he is granted access to EClass.
>> I see.
>>>
>>> I know I could hand-modify my eclasses (or a common ancestor) to
>>> implement a certain security interface (possibly as static methods,
>>> since "classification indexes" do not depend on instance), but I was
>>> wondering if there is a "standard way" to implement security checking.
>> How is the information stored? I.e., is the storage itself secure? Does
>> this security need to be just in the UI, or does in need this support in
>> terms of the programmatic API?
>
> I am now testing with a standard XMI backstore (and I don't know how
> to store permissions there).
I don't imagine it's part of the data itself so wouldn't be stored with
the instances...
> Final backstore will be on some kind of Database, but I am not
> interested in that because my Customer will replace current
> model.load()/model.store() with his own versions; i.e.: I will deliver
> an XMI-based version.
I see. It's not clean how they'll prevent client code from accessing
only parts of the data...
>
> I assume this means it is a UI-only problem, but I would like to
> handle it at the lowest possible level and avoid scattering permission
> checks beside each widget (I am using JavaFX and Tom's new JFX bindings).
It seems to me it ends up being a UI problem no matter what. I.e.,
which entry fields does the UI show? I don't imagine it should show
visually anything for which there isn't access...
>
> I don't know how to attach some information to model classes (as
> opposed to model class instances).
All EModelElements can have eAnnotations...
> This information (the permission levels) should be changeable and
> contained in the XMI file, somehow. Certainly should be part of
> save/restore.
The Ecore editors support editing of the annotations...
>
>
> Regards
> Mauro
>
>
|
|
|
| Re: Permissions on EMF model classes [message #1075461 is a reply to message #1075427] |
Mon, 29 July 2013 09:13 |
| Eclipse User |
|
|
|
Hi Ed,
comments inline.
On 29/07/2013 14:10, Ed Merks wrote:
> Mauro,
>
> Comments below.
>
>> I am now testing with a standard XMI backstore (and I don't know how
>> to store permissions there).
> I don't imagine it's part of the data itself so wouldn't be stored with
> the instances...
Agreed, at least in this phase, I can have security levels carved in
stone (part of model declaration, as opposed as contained in model
backstore).
I should bear in mind this may change in future (I could need to
dynamically load, somehow, these levels)-
>> Final backstore will be on some kind of Database, but I am not
>> interested in that because my Customer will replace current
>> model.load()/model.store() with his own versions; i.e.: I will deliver
>> an XMI-based version.
> I see. It's not clean how they'll prevent client code from accessing
> only parts of the data...
I don't know.
I know they are not relying on underlying database permissions.
I guess they simply hope users won't to directly manipulate database.
>>
>> I assume this means it is a UI-only problem, but I would like to
>> handle it at the lowest possible level and avoid scattering permission
>> checks beside each widget (I am using JavaFX and Tom's new JFX bindings).
> It seems to me it ends up being a UI problem no matter what. I.e.,
> which entry fields does the UI show? I don't imagine it should show
> visually anything for which there isn't access...
Currently I'm implementing a Master/Detais pattern and preventing
entering the Details page if associated EClass has "permission level"
exceeding user's clearance. Permission levels are currently carved in
stone as static members manually added to EClassImpl.java (I don't like
this)
>>
>> I don't know how to attach some information to model classes (as
>> opposed to model class instances).
> All EModelElements can have eAnnotations...
>> This information (the permission levels) should be changeable and
>> contained in the XMI file, somehow. Certainly should be part of
>> save/restore.
> The Ecore editors support editing of the annotations...
I am currently studying eAnnotations on your book (I have it), but it's
not clear to me just how to use them.
I've seen eclipse ecore editor can add annotations (and I assume I can
access them at runtime, even if I didn't try, yet), but (in case I will
need it) can I dynamically change those values? How?
In general I assume some kind of Security Management would be a welcome
addition to EMF (either as pure code, without strong enforcing, or using
some "privileged backend task" for load/save operations).
Thanks
Mauro
|
|
|
| Re: Permissions on EMF model classes [message #1075490 is a reply to message #1075461] |
Mon, 29 July 2013 10:12 |
| Eclipse User |
|
|
|
Mauro,
Comments below.
On 29/07/2013 3:13 PM, Mauro Candarelli wrote:
> Hi Ed,
> comments inline.
>
> On 29/07/2013 14:10, Ed Merks wrote:
>> Mauro,
>>
>> Comments below.
>>
>>> I am now testing with a standard XMI backstore (and I don't know how
>>> to store permissions there).
>> I don't imagine it's part of the data itself so wouldn't be stored with
>> the instances...
> Agreed, at least in this phase, I can have security levels carved in
> stone (part of model declaration, as opposed as contained in model
> backstore).
The annotations don't need to contain the permissions themselves, just
something that would know where to look for the permissions.
> I should bear in mind this may change in future (I could need to
> dynamically load, somehow, these levels)-
>
>>> Final backstore will be on some kind of Database, but I am not
>>> interested in that because my Customer will replace current
>>> model.load()/model.store() with his own versions; i.e.: I will deliver
>>> an XMI-based version.
>> I see. It's not clean how they'll prevent client code from accessing
>> only parts of the data...
> I don't know.
> I know they are not relying on underlying database permissions.
> I guess they simply hope users won't to directly manipulate database.
That's part of the reason for my questions about whether it's just the
UI or really the programmatic API that needs to be controlled.
>
>>>
>>> I assume this means it is a UI-only problem, but I would like to
>>> handle it at the lowest possible level and avoid scattering permission
>>> checks beside each widget (I am using JavaFX and Tom's new JFX
>>> bindings).
>> It seems to me it ends up being a UI problem no matter what. I.e.,
>> which entry fields does the UI show? I don't imagine it should show
>> visually anything for which there isn't access...
> Currently I'm implementing a Master/Detais pattern and preventing
> entering the Details page if associated EClass has "permission level"
> exceeding user's clearance. Permission levels are currently carved in
> stone as static members manually added to EClassImpl.java (I don't
> like this)
You mean to the generated implementation class? I assume you're not
extending the Ecore model itself.
>
>>>
>>> I don't know how to attach some information to model classes (as
>>> opposed to model class instances).
>> All EModelElements can have eAnnotations...
>>> This information (the permission levels) should be changeable and
>>> contained in the XMI file, somehow. Certainly should be part of
>>> save/restore.
>> The Ecore editors support editing of the annotations...
> I am currently studying eAnnotations on your book (I have it), but
> it's not clear to me just how to use them.
> I've seen eclipse ecore editor can add annotations (and I assume I can
> access them at runtime, even if I didn't try, yet),
Yes.
> but (in case I will need it) can I dynamically change those values? How?
Have the annotation indicate where to look for the permission values.
>
> In general I assume some kind of Security Management would be a
> welcome addition to EMF (either as pure code, without strong
> enforcing, or using some "privileged backend task" for load/save
> operations).
It sounds complicated. Even getters would need to be instrumented, so
not just complicated but performance impacting too...
>
> Thanks
> Mauro
|
|
|
| Re: Permissions on EMF model classes [message #1075507 is a reply to message #1075490] |
Mon, 29 July 2013 10:52 |
| Eclipse User |
|
|
|
Thanks Ed,
comments inline.
On 29/07/2013 16:12, Ed Merks wrote:
> Mauro,
>
> Comments below.
>
> On 29/07/2013 3:13 PM, Mauro Candarelli wrote:
>> Hi Ed,
>> comments inline.
>> In general I assume some kind of Security Management would be a
>> welcome addition to EMF (either as pure code, without strong
>> enforcing, or using some "privileged backend task" for load/save
>> operations).
> It sounds complicated. Even getters would need to be instrumented, so
> not just complicated but performance impacting too...
I was thinking to a "filter type" solution:
- model.load(user) should not create at all EClasses not visible
to the user (or mark them not visible).
- model.load(user) should mark as "non writable" EClasses not
modifiable by user.
- access to marked EClasses should rise SecurityException
(I don't know if this has some impact on performance).
- model.save() should merge back unseen/unchangeable branches
(possibly discarding branches which lost their container).
There are other issues (like checking all references crossing
the /editable/noneditable barrier), but they could be handled
at save-time, which is inherently a slow operation.
Load could substitute a SecurityException-rising variant of
EClass so performance penalty would be small (if any).
Obviously such a model imposes a complete model-reload upon
change of user, but, at least in my use-case, this seems
perfectly acceptable.
Thanks
Mauro
|
|
|
| Re: Permissions on EMF model classes [message #1075519 is a reply to message #1075507] |
Mon, 29 July 2013 11:13 |
| Eclipse User |
|
|
|
Mauro,
Comments below.
On 29/07/2013 4:52 PM, Mauro Candarelli wrote:
> Thanks Ed,
> comments inline.
>
> On 29/07/2013 16:12, Ed Merks wrote:
>> Mauro,
>>
>> Comments below.
>>
>> On 29/07/2013 3:13 PM, Mauro Candarelli wrote:
>>> Hi Ed,
>>> comments inline.
>>> In general I assume some kind of Security Management would be a
>>> welcome addition to EMF (either as pure code, without strong
>>> enforcing, or using some "privileged backend task" for load/save
>>> operations).
>> It sounds complicated. Even getters would need to be instrumented, so
>> not just complicated but performance impacting too...
>
> I was thinking to a "filter type" solution:
>
> - model.load(user) should not create at all EClasses not visible
> to the user (or mark them not visible).
If the information isn't there in the backing store it wouldn't be
created...
> - model.load(user) should mark as "non writable" EClasses not
> modifiable by user.
So some things are read-only...
> - access to marked EClasses should rise SecurityException
> (I don't know if this has some impact on performance).
Again, so much of this depends on if you're trying to control things in
the UI verses trying to do it right in the mode...
> - model.save() should merge back unseen/unchangeable branches
> (possibly discarding branches which lost their container).
I suppose this comes down to how someone is going to write the
persistence layer...
>
> There are other issues (like checking all references crossing
> the /editable/noneditable barrier), but they could be handled
> at save-time, which is inherently a slow operation.
> Load could substitute a SecurityException-rising variant of
> EClass so performance penalty would be small (if any).
I imagine it might be the case that others would want just certain
features to be accessible or inaccessible.
>
> Obviously such a model imposes a complete model-reload upon
> change of user, but, at least in my use-case, this seems
> perfectly acceptable.
A general solution seems to me quite a complex thing...
> Thanks
> Mauro
>
|
|
|
Goto Forum:
Current Time: Tue Jul 08 05:20:07 EDT 2025
Powered by FUDForum. Page generated in 0.32975 seconds |
Home