|Security and Remote Services [message #619807]
||Tue, 04 December 2007 17:10
| Shawn Hampton
Registered: July 2009
I am currently looking into using the ECF RemoteServices API. I have a |
test client/server application up and running. Both using OSGi and
Eclipse RCP and using the latest version of ECF from the Europa
I am now looking at adding security to the application. I have simple
user/password authentication working using an IConnectHandlerPolicy on
the server and an IConnectContext on the client.
Once the client calls .connect(), he/she is authenticated and connected
for a session. What I need now is for the remote service to be able to
access this connection information e.g. I need the username associated
with the call.
Can someone give me some insight as to how to handle this? Or at least
a direction in which to look?
Sr. Research Programmer
National Center for Supercomputing Applications
|Re: Security and Remote Services [message #619822 is a reply to message #619820]
||Fri, 14 December 2007 13:50
| Scott Lewis
Registered: July 2009
Christian Campo wrote:
> Hi Scott,
> can a single user specify multiple ECF IDs at the same time ?
Yes, they surely can. Specifically, an authenticated JAAS Subject can
have multiple Principals associated with it upon login/authentication
(via JAAS...this has nothing to do with ECF per se). The ECF ID
interface (org.eclipse.ecf.core.identity.ID) extends
java.security.Principal, meaning that all ECF IDs are also potentially
Principals associated with a JAAS Subject. They would then be available
via methods like subject.getPrincipals() and/or getPrincipals(Class c).
One thing this depends upon is the ability for plugins (like ECF or
others) add Principals to an authenticated Subject during
login....hopefully without writing a separate LoginModule. There is an
Equinox security incubator bug here to that effect:
> would you not rather associate
> a Subject with an ECF ID ?
This is exactly the intention/design...by using the Principal interface
as super interface for IDs, and thereby enabling using
Note also that ECF's Namespace extension point allows plugins to create
their own Namespaces (Namespaces are factories for creating
Principals/IDs of a certain type/types).
> just curious....
> - christian campo
> Scott Lewis schrieb:
>> Hi Shawn,
>> Shawn Hampton wrote:
>>> I am currently looking into using the ECF RemoteServices API. I have
>>> a test client/server application up and running. Both using OSGi and
>>> Eclipse RCP and using the latest version of ECF from the Europa
>>> discovery site.
>> Cool! Would you be able/willing to allow us to try this test client
>> and server application? What does it do?
>>> I am now looking at adding security to the application. I have
>>> simple user/password authentication working using an
>>> IConnectHandlerPolicy on the server and an IConnectContext on the
>>> Once the client calls .connect(), he/she is authenticated and
>>> connected for a session. What I need now is for the remote service
>>> to be able to access this connection information e.g. I need the
>>> username associated with the call.
>>> Can someone give me some insight as to how to handle this? Or at
>>> least a direction in which to look?
>> One way to go is to use JAAS (Java Authentication and Authorization
>> service). You can use the JAAS login process to associate Principals
>> with an authenticated Subject (user). These principals can have
>> permissions associated with them that can be checked at runtime.
>> This will probably be made more easy/natural for Equinox-based
>> applications (e.g. RCP apps, Equinox server apps, etc) in the near
>> future (3.4/Ganymede) because of the Equinox security work:
>> We (ECF) are participating some in this work (at least we're talking
>> with the folks doing the integration). We expect to take advantage of
>> the JAAS integration work in ECF and ECF-based applications...note
>> that ECF IDs implement the java.security.Principal interface.
>> I know this isn't very much at this point (and apologize for that),
>> but the JAAS/Equinox integration will help. Of course any
>> contributions or thoughts that you might have would also be welcome.
Powered by FUDForum
. Page generated in 0.02201 seconds