[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
| Re: [ecf-dev] user authentication and user dependent services | 
Hi Peter,
On 6/29/2015 4:11 AM, Peter Hermsdorf wrote:
Hi,
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?
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).
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)
Thanks for any hints and ideas!
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.
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.
There are other ways, but before going further let's make sure I'm 
understanding you correctly.
Thanks,
Scott