| Security [message #49138] |
Mon, 08 August 2005 11:58  |
Eclipse User |
|
|
|
Originally posted by: ruben.hartenstein.gmx.de
Hello guys,
I am a german student and got a research project about user
authentification and authorization within the rich client environment.
Can you give me any further information about this?
For example:
How can I observe the call of a method which is opening a view.
And if the user is not allowed to open this I want to reject him.
What different solutions are possible for solving problems like this with
the rich client plattform?
I read about equinox and its security orientation.
Does somebody know in which eclipse release there will a concrete security
implementation?
Thank you
Ruben
|
|
|
| Re: Security [message #49188 is a reply to message #49138] |
Tue, 09 August 2005 00:07  |
| Eclipse User |
|
|
|
Originally posted by: pascal.ibm.canada
The area you are researching on is also an area of research in
equinox... So any suggestions are welcome :-) Who knows we might
implement the result of your research.
There is no target date for the eclipse platform to reconsumme what is
going on in equinox. It will only depend on the result.
That said the osgi layer is already fully secured and I think some IBM
folks are working on securing the RCP code base and building tools to help.
However I don't think they've done anything in the authorization /
authentication space, nor investigated the creation of eclipse specific
permissions and the implications.
PaScaL
Ruben Hartenstein wrote:
> Hello guys,
>
> I am a german student and got a research project about user
> authentification and authorization within the rich client environment.
>
> Can you give me any further information about this?
>
> For example:
> How can I observe the call of a method which is opening a view. And if
> the user is not allowed to open this I want to reject him.
>
> What different solutions are possible for solving problems like this with
> the rich client plattform?
>
> I read about equinox and its security orientation.
> Does somebody know in which eclipse release there will a concrete
> security implementation?
>
> Thank you
> Ruben
>
|
|
|
| Re: Security [message #49210 is a reply to message #49188] |
Tue, 09 August 2005 13:37 |
| Eclipse User |
|
|
|
Originally posted by: neil.integility.com
Pascal,
I have written a set of plugins that I am planning to release on
Sourceforge, which allows you to do JAAS authentication in the
IPlatformRunnable before workbench creation. It then loads a set of
plugins depending on the user's role. All of this (eg the JAAS
LoginModule, the callback handlers etc) is configurable through extension
points.
This works great for us, because we can cluster business functions into
plugins and then enable or disable the whole plugin based on user role. If
the user doesn't have the right role for a plugin, they don't even see the
functions at all.
Perhaps this isn't granular enough for some applications. I expect that if
method-level authorization was required you would have to install a
SecurityManager and call Subject.doAs(). I'm investigating this at the
moment.
Regards,
Neil Bartlett
|
|
|
| Re: Security [message #49303 is a reply to message #49210] |
Thu, 11 August 2005 03:29 |
| Eclipse User |
|
|
|
Originally posted by: pascal.ibm.canada
Hi Neil,
This is great news. Please keep us updated when you post the code.
Moreover, keep us updated on your progress on the method-level
authorization investigations.
Meanwhile I have a two questions:
- how do you "load the set of plugins"? Are the plugins already here on
disk, or you are obtaining them from somewhere? Which API do use you to
install the plugins?
- do you support changing role on the fly?
- have you tried to enable / disable capabilities based on who is
authenticed?
PaScaL
Neil Bartlett wrote:
> Pascal,
>
> I have written a set of plugins that I am planning to release on
> Sourceforge, which allows you to do JAAS authentication in the
> IPlatformRunnable before workbench creation. It then loads a set of
> plugins depending on the user's role. All of this (eg the JAAS
> LoginModule, the callback handlers etc) is configurable through
> extension points.
>
> This works great for us, because we can cluster business functions into
> plugins and then enable or disable the whole plugin based on user role.
> If the user doesn't have the right role for a plugin, they don't even
> see the functions at all.
>
> Perhaps this isn't granular enough for some applications. I expect that
> if method-level authorization was required you would have to install a
> SecurityManager and call Subject.doAs(). I'm investigating this at the
> moment.
>
> Regards,
> Neil Bartlett
>
|
|
|
| Re: Security [message #49363 is a reply to message #49303] |
Fri, 12 August 2005 13:53 |
| Eclipse User |
|
|
|
Originally posted by: neil.integility.com
Pascal,
- The authorization extension point uses an interface which simply returns
a java.io.InputStream, so the plugins can be on the local file system or
downloaded via HTTP etc.
- The plugins are installed using the OSGi API. I do this for two reasons.
Firstly, I always uninstall when the workbench shuts down, to ensure that
users get locked out of plugins they no longer have rights to if their
role changes. Secondly, I don't know where to begin trying to understand
the update API! At this stage I just needed to get something working,
future plans are to look at either using the update API or to write my own
caching. The application I'm building myself is mostly delivered with JWS,
with additional role-based plugins delivered over HTTP from a server on
our LAN. Those plugins are small enough, and the HTTP server fast enough,
that I don't need to worry immediately about caching to disk.
- No ability to change the role on the fly at the moment, although this
should be easy enough to do. Assuming that the extender providing the
authorization is able to know when the role has changed, then my plugins
can attempt to change the provided plugins at runtime. I wasn't at
EclipseCon but I gather that a presentation there showed that this was
possible, ie if a plugin is dynamically uninstalled then any of the
artifacts of that plugin currently on screen (eg views) will immediately
disappear. Is that in fact the case?
(BTW I think it's far more likely to see dynamic role additions rather
than removals, eg the scenario where you phone up IT Helpdesk and ask for
permission to use a particular feature - they set a flag and, bang, the
plugins show up in your workbench.)
- I haven't really looked much into the capabilities API yet, but it
sounds like it could be useful for authorization purposes. Perhaps when I
get my code up onto SourceForge somebody can help me out. That should
happen next week (day job permitting).
Regards,
Neil Bartlett
Pascal Rapicault wrote:
> Hi Neil,
> This is great news. Please keep us updated when you post the code.
> Moreover, keep us updated on your progress on the method-level
> authorization investigations.
> Meanwhile I have a two questions:
> - how do you "load the set of plugins"? Are the plugins already here on
> disk, or you are obtaining them from somewhere? Which API do use you to
> install the plugins?
> - do you support changing role on the fly?
> - have you tried to enable / disable capabilities based on who is
> authenticed?
> PaScaL
> Neil Bartlett wrote:
>> Pascal,
>>
>> I have written a set of plugins that I am planning to release on
>> Sourceforge, which allows you to do JAAS authentication in the
>> IPlatformRunnable before workbench creation. It then loads a set of
>> plugins depending on the user's role. All of this (eg the JAAS
>> LoginModule, the callback handlers etc) is configurable through
>> extension points.
>>
>> This works great for us, because we can cluster business functions into
>> plugins and then enable or disable the whole plugin based on user role.
>> If the user doesn't have the right role for a plugin, they don't even
>> see the functions at all.
>>
>> Perhaps this isn't granular enough for some applications. I expect that
>> if method-level authorization was required you would have to install a
>> SecurityManager and call Subject.doAs(). I'm investigating this at the
>> moment.
>>
>> Regards,
>> Neil Bartlett
>>
|
|
|
| Re: Security [message #49423 is a reply to message #49363] |
Fri, 19 August 2005 01:09 |
| Eclipse User |
|
|
|
Originally posted by: pascal.ibm.canada
> - The plugins are installed using the OSGi API. I do this for two
> reasons. Firstly, I always uninstall when the workbench shuts down, to
> ensure that users get locked out of plugins they no longer have rights
> to if their role changes. Secondly, I don't know where to begin trying
> to understand the update API! At this stage I just needed to get
> something working, future plans are to look at either using the update
> API or to write my own caching. The application I'm building myself is
> mostly delivered with JWS, with additional role-based plugins delivered
> over HTTP from a server on our LAN. Those plugins are small enough, and
> the HTTP server fast enough, that I don't need to worry immediately
> about caching to disk.
the high level entry point for update is in the plugin
org.eclipse.update.core in the package org.eclipse.update.operation. You
can find an example of how to use it in the rcp newsgroup archive or in
tutorial 26 from eclipsecon (see the website).
>
> - No ability to change the role on the fly at the moment, although this
> should be easy enough to do. Assuming that the extender providing the
> authorization is able to know when the role has changed, then my plugins
> can attempt to change the provided plugins at runtime. I wasn't at
> EclipseCon but I gather that a presentation there showed that this was
> possible, ie if a plugin is dynamically uninstalled then any of the
> artifacts of that plugin currently on screen (eg views) will immediately
> disappear. Is that in fact the case?
Yes it is the case
PaScaL
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03537 seconds
] 
Search
Help
Register
Login
Home
