Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Modeling (top-level project) » security
security [message #380508] Fri, 20 April 2007 19:21 Go to next message
Eclipse UserFriend
Originally posted by: aquaholic.rogers.com

Hi all,

Has anyone looked at adding a security layer to EMF? Something that
restricts access to data and restricts modifications to data as required.
Also going further than that to restrict access to various model elements
depending on the user's credentials (this would only need to be applied when
the model is being interpreted from a UI component that would inform the
user of the model elements).

As we would like to avoid having to subclass EObject/EClass. Any ideas out
there??? If something like the adapters were used in both sets and gets
that would do the trick! The adapters would need to have the chance to
modify the data before it is sent back to the client.

What are your thoughts Ed?

Thanks,
Alex
Re: security [message #380511 is a reply to message #380508] Sat, 21 April 2007 12:03 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 26221
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------090300020807000006000108
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Alex,

Here's now I answered in the EMF newsgroup:

I don't know of anyone who has done this. There is no general
notification or callback support when calling getter. I know this
would be cool and perhaps would be nice as an optional thing, but
changing the general pattern for a getter to be something more than
returning a variable would have a negative general performance
impact. In terms of protecting against modification, I could
imagine attaching a ChangeRecorder that undoes any disallowed
change. For something more general, I could imagine using an
EStore, set the GenModel's Feature Delegation to Reflective and set
Root Extends Class to EStoreEObjectImpl and then manage the security
via access to the store; EStoreEObjectImpl contains a sample
implementation of store, i.e., EStoreImpl. Perhaps simpler would be
to set Feature Delegation to Reflective and then provide a
specialized EObjectImpl in which monitors access to eSettingDelegate
and refuses to return one if access is not permitted.

When posting to multiple newsgroups, try to do so with a single posting
addressed to all the groups rather than with a separate posting to each
group.


asauve wrote:
> Hi all,
>
> Has anyone looked at adding a security layer to EMF? Something that
> restricts access to data and restricts modifications to data as required.
> Also going further than that to restrict access to various model elements
> depending on the user's credentials (this would only need to be applied when
> the model is being interpreted from a UI component that would inform the
> user of the model elements).
>
> As we would like to avoid having to subclass EObject/EClass. Any ideas out
> there??? If something like the adapters were used in both sets and gets
> that would do the trick! The adapters would need to have the chance to
> modify the data before it is sent back to the client.
>
> What are your thoughts Ed?
>
> Thanks,
> Alex
>
>
>
>


--------------090300020807000006000108
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Alex,<br>
<br>
Here's now I answered in the EMF newsgroup:<br>
<blockquote>I don't know of anyone who has done this.&nbsp; There is no
general notification or callback support when calling getter.&nbsp; I know
this would be cool and perhaps would be nice as an optional thing, but
changing the general pattern for a getter to be something more than
returning a variable would have a negative general performance impact.&nbsp;
In terms of protecting against modification, I could imagine attaching
a ChangeRecorder that undoes any disallowed change.&nbsp; For something more
general, I could imagine using an EStore, set the GenModel's Feature
Delegation to Reflective and set Root Extends Class to
EStoreEObjectImpl and then manage the security via access to the store;
EStoreEObjectImpl contains a sample implementation of store, i.e.,
EStoreImpl.&nbsp; Perhaps simpler would be to set Feature Delegation to
Reflective and then provide a specialized EObjectImpl in which monitors
access to eSettingDelegate and refuses to return one if access is not
permitted.
<br>
</blockquote>
When posting to multiple newsgroups, try to do so with a single posting
addressed to all the groups rather than with a separate posting to each
group. <br>
<br>
<br>
asauve wrote:
<blockquote cite="midf0b3sa$l4m$1@build.eclipse.org" type="cite">
<pre wrap="">Hi all,

Has anyone looked at adding a security layer to EMF? Something that
restricts access to data and restricts modifications to data as required.
Also going further than that to restrict access to various model elements
depending on the user's credentials (this would only need to be applied when
the model is being interpreted from a UI component that would inform the
user of the model elements).

As we would like to avoid having to subclass EObject/EClass. Any ideas out
there??? If something like the adapters were used in both sets and gets
that would do the trick! The adapters would need to have the chance to
modify the data before it is sent back to the client.

What are your thoughts Ed?

Thanks,
Alex



</pre>
</blockquote>
<br>
</body>
</html>

--------------090300020807000006000108--
Re: security [message #592372 is a reply to message #380508] Sat, 21 April 2007 12:03 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 26221
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------090300020807000006000108
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Alex,

Here's now I answered in the EMF newsgroup:

I don't know of anyone who has done this. There is no general
notification or callback support when calling getter. I know this
would be cool and perhaps would be nice as an optional thing, but
changing the general pattern for a getter to be something more than
returning a variable would have a negative general performance
impact. In terms of protecting against modification, I could
imagine attaching a ChangeRecorder that undoes any disallowed
change. For something more general, I could imagine using an
EStore, set the GenModel's Feature Delegation to Reflective and set
Root Extends Class to EStoreEObjectImpl and then manage the security
via access to the store; EStoreEObjectImpl contains a sample
implementation of store, i.e., EStoreImpl. Perhaps simpler would be
to set Feature Delegation to Reflective and then provide a
specialized EObjectImpl in which monitors access to eSettingDelegate
and refuses to return one if access is not permitted.

When posting to multiple newsgroups, try to do so with a single posting
addressed to all the groups rather than with a separate posting to each
group.


asauve wrote:
> Hi all,
>
> Has anyone looked at adding a security layer to EMF? Something that
> restricts access to data and restricts modifications to data as required.
> Also going further than that to restrict access to various model elements
> depending on the user's credentials (this would only need to be applied when
> the model is being interpreted from a UI component that would inform the
> user of the model elements).
>
> As we would like to avoid having to subclass EObject/EClass. Any ideas out
> there??? If something like the adapters were used in both sets and gets
> that would do the trick! The adapters would need to have the chance to
> modify the data before it is sent back to the client.
>
> What are your thoughts Ed?
>
> Thanks,
> Alex
>
>
>
>


--------------090300020807000006000108
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Alex,<br>
<br>
Here's now I answered in the EMF newsgroup:<br>
<blockquote>I don't know of anyone who has done this.&nbsp; There is no
general notification or callback support when calling getter.&nbsp; I know
this would be cool and perhaps would be nice as an optional thing, but
changing the general pattern for a getter to be something more than
returning a variable would have a negative general performance impact.&nbsp;
In terms of protecting against modification, I could imagine attaching
a ChangeRecorder that undoes any disallowed change.&nbsp; For something more
general, I could imagine using an EStore, set the GenModel's Feature
Delegation to Reflective and set Root Extends Class to
EStoreEObjectImpl and then manage the security via access to the store;
EStoreEObjectImpl contains a sample implementation of store, i.e.,
EStoreImpl.&nbsp; Perhaps simpler would be to set Feature Delegation to
Reflective and then provide a specialized EObjectImpl in which monitors
access to eSettingDelegate and refuses to return one if access is not
permitted.
<br>
</blockquote>
When posting to multiple newsgroups, try to do so with a single posting
addressed to all the groups rather than with a separate posting to each
group. <br>
<br>
<br>
asauve wrote:
<blockquote cite="midf0b3sa$l4m$1@build.eclipse.org" type="cite">
<pre wrap="">Hi all,

Has anyone looked at adding a security layer to EMF? Something that
restricts access to data and restricts modifications to data as required.
Also going further than that to restrict access to various model elements
depending on the user's credentials (this would only need to be applied when
the model is being interpreted from a UI component that would inform the
user of the model elements).

As we would like to avoid having to subclass EObject/EClass. Any ideas out
there??? If something like the adapters were used in both sets and gets
that would do the trick! The adapters would need to have the chance to
modify the data before it is sent back to the client.

What are your thoughts Ed?

Thanks,
Alex



</pre>
</blockquote>
<br>
</body>
</html>

--------------090300020807000006000108--
Previous Topic:security
Next Topic:code samples
Goto Forum:
  


Current Time: Wed Nov 26 00:47:30 GMT 2014

Powered by FUDForum. Page generated in 0.01638 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software