2

I have a client - server application which uses cxf DOSGi [1]. Now I want to authenticate the clients from the server and create a session for the client. The client will have a cookie which is used to access the service once authenticated. I would like to know what is the best way for the server to access the HTTP session and the best way to store a cookie at the client end once authenticated.

I was thinking of making a custom Session object at application level once authenticated and send a Cookie object to the client. So when the client accesses the service methods, it will pass the cookie as an argument. The client will be validated in every service method. But I dont think this is the best way to handle this since every service method must have a separate argument to pass the Cookie.

I came across this when I was googling [2]. Is it possible to get "WebServiceContext" in the service in DOSGi? Even if I get it, how would I store the cookie at client end and make sure the client sends the cookie in every subsequent web service call?

[1] http://cxf.apache.org/distributed-osgi-greeter-demo-walkthrough.html

[2] How can I manage users' sessions when I use web services?

Any help is highly appreciated. Thanks.

Community
  • 1
  • 1
Jeewantha
  • 965
  • 1
  • 11
  • 28
  • Do you need the session to create a stateful service or do you simply want to maintain the authentication with it? In case it is only authentication why not simply use basic auth for every call? – Christian Schneider Jun 23 '13 at 12:45
  • I dont want a stateful service. The requirement is to authenticate the users and allow only the authorised users to access the service. To use basic auth for every call, the client has to pass a user token every time it accesses the service methods. How do I do that? Is that possible with DOSGi, because AFAIU I cant get webservice request information from OSGi level? – Jeewantha Jun 23 '13 at 15:09

1 Answers1

1

You can use a custom intent to control authentication. Basically an intent is a CXF feature that is applied to the webservice by DOSGi. You create the feature in a separate bundle and then publish it with a special property for its name: See the DOSGi reference guide.

In a project we created a feature that read a threadlocal containing the authentication context and used the credentials stored there to populate the CXF authentication. So you just have to store the credentials once into the threadlocal at the start of you application and all calls work.

Currently there is no simple documenation or example for this case but I plan to create it in the near future as authentication is a common problem. I plan to use shiro as an authentication framework and write a generic adapter for CXF. I will add a comment or another answer as soon as I got it ready. In the meantime you can try to do the same yourself.

Christian Schneider
  • 19,420
  • 2
  • 39
  • 64
  • Thanks for the answer. I have one question. How would the client send its authentication information by means of some token? And how would the server extract that information at authentication phase? – Jeewantha Jun 25 '13 at 09:03
  • In the simplest form you use an intercpetor to set username and password as message properties in CXF for the http transport authentication to pick up. On the server side you will have to install an interceptor that evaluates the credentials and allows or denies access to the service. – Christian Schneider Jun 25 '13 at 09:27
  • @ChristianSchneider Hi Christian, Any reason why you decided to use Shiro and not use JAAS with the [JAASLoginInterceptr](http://cxf.apache.org/docs/security.html#Security-JAASLoginInterceptor)? – Can't Tell Aug 18 '13 at 11:11
  • In our project we used a jaas login interceptor as the customer decided to use single sign on with kerberos. My plan to use Shiro was partly because it has good support for passing the login information when switching threads with e.g. an executor. Additionally it sounded simpler than jaas. On the other hand my first experiments with shiro were ok but not that much simpler than jaas. So I am still a bit unsure which aproach is best. – Christian Schneider Aug 18 '13 at 21:12
  • I got an update. On the karaf mailing list we discussed how to do authentication for karaf commands and OSGi services. We agreed to use JAAS by default. So I will also add this to CXF. See http://karaf.922171.n3.nabble.com/Some-thoughts-around-adding-security-for-Karaf-Shell-Commands-td4029474.html – Christian Schneider Aug 27 '13 at 06:29