[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] user authentication and user dependent services
|
Hi Scott,
I have a use case, where a client/consumer needs to authenticate at
the server/provider and the actual service implementation on the
server needs the authentication information (at least the username)
when called.
My current solution is to make the username part of the API. eg.
String myService(String username, String otherparameters);
But it would be nice to have access to the actual Authentication
information of the caller to use them.
So that I understand: What you mean by 'authentication information'
is the information passed by the client to the server upon initial
connection, correct?
correct
I have implemented a custom HostContainerSelector which registers a
IConnectHandlerPolicy to handle to authentication. But I have no idea
on how to access them in my service implementation (probably I need
to call some ECF API....)
Do you somehow store/maintain the association between the client (i.e.
the clientID) and the authentication information? If you do, then you
should be able to access this information later (i.e. when the remote
call is made).
currently not, but that might be a way - see my comment below
The use case is access control, eg. depending on your username/login
you can "see" different content. When making the username part of the
API a authenticated client could pretend being someone else by just
calling the service with a different username.
I could imagine a kind of wrapper code on server side which intercept
the service call and "substitutes" the username in the service call
before the actual service is called. This would have the benefit of
decoupling this authentication/user handling stuff from the actual
service implementation. (the service wouldn't need to know anything
about ECF and user management)
If I've understood your use case correctly (above questions), then I
can think of a couple of approaches. One that I've done myself is to
have some other OSGi service for storing/retrieving the association
between the clientID and the username/pw/auth info. Then you could
store that association away upon connect/disconnect (or at some other
point in the protocol...e.g. if you have some other login service),
and then look it up/check it in response to a remote call. There is
a way with existing API to get the clientID/fromID for every remote call.
That might be a way. But then I need some API to get the clientID of the
"current" caller to find the authentication information that got stored
on login....
Another way would be to keep the above association info not as a
separate service but as some state on the host container. Perhaps
not as clean IMHO, but possibly serviceable.
What came to my mind as a cool solution is doing something similar to
what is done with Servlets where you can get stuff injected in your
Servlet Resource Class. eg.
@Context
HttpServletRequest request;
and then use the request(or session or whatever else ...) to get all
kind of information regarding the request and caller.
This saves the implementor from calling an API directly, is loosly
coupled and can be tested more easily.
Bye, Peter
