0

I have a SOAP web service that is secured with Spring Security using basic authentication.

I've written a Swing application that accesses this web service. When the application starts, a login dialog appears where the user enters its credentials. When the user clicks the Login button, the JAXWS client is created with the given credentials. I also want to give the possibility to the logged user to logout. Spring Security requires to access a URL in order to logout. How does that work in a standalone application? Should this be done through CXF or using a simple HTTP client?

Mickael Marrache
  • 6,367
  • 11
  • 58
  • 109

3 Answers3

1

Avoid sessions altogether and have your JAXClient reauthenticate on every conn request. Configure your secuity.xml with stateless which is available from Spring Security 3.1.

Michael-O
  • 17,130
  • 6
  • 51
  • 108
  • It's clear that it's easier when it's stateless but I would like to limit one connected instance of the application per user (using the concurrency control feature of Spring Security, but this feature is relevant only if the service maintains sessions). I will consider this possibility. Do you know how to configure the client to reauthenticate on every request? – Mickael Marrache Jan 06 '13 at 12:39
  • Then limit the number of started Swing clients on the same host. – Marcel Stör Jan 06 '13 at 12:41
  • @MarcelStör The problem is different. For example, if a user shared its credentials with another user. Each user may run a client instance on his host, both using the same credentials. That's what I want to avoid. – Mickael Marrache Jan 06 '13 at 12:45
  • @MickaelMarrache, first of all you should know that SOAP is unaware of any HTTP sessions. It uses HTTP as a transport only. You shouldn't rely on any sessions. If you want to limit the amount of connections, maybe you should consider a filter within Spring Sec or Tomcat. You do not need to reconfigure the client. Create one instance of the JAXWS client, configure it and reuse it until your Swing app shuts down. – Michael-O Jan 06 '13 at 13:05
  • @Michael-O I don't have any problem not to use HTTP sessions. The problem is I guess that Spring Security relies on HTTP sessions to limit amount of concurrent connections, that's why I'm forced to use HTTP sessions. If you know about another solution, please share. – Mickael Marrache Jan 07 '13 at 08:34
  • @MickaelMarrache, that is true. Spring determines concurrency with sessions only. You might want to open a JIRA ticket for that limitation. There is no valve which realizes what you want. What is the reason why you want to limit that anyway? – Michael-O Jan 07 '13 at 09:20
  • @Michael-O This is a requirement I got from the user. He has an account that may be known by another person, but he does not want that his account will be used concurrently. If you have arguments why not to implement this I'm interested. – Mickael Marrache Jan 07 '13 at 09:37
  • @MickaelMarrache, I found [this](http://stackoverflow.com/a/2752020/696632) ref. Says pretty much the same as I do. If you have all of your services thead-safe there should be a problem with that. Regarding the spilt account. I would try to avoid such things altogher. You will always end in unsyched resources. Are you able to assign distinct accounts with the same permissions? – Michael-O Jan 07 '13 at 09:49
0

It does not matter how do you implement this. The only requirement is to create HTTP GET to logout URL but your request should contain session ID of your session. Otherwise Spring cannot know which session to invalidate. So, I think that the easiest way for you is to use the same client you are currently using.

AlexR
  • 109,181
  • 14
  • 116
  • 194
  • Thanks for your answer. I'm using a JaxWsProxyFactoryBean to create the proxy I use to call my web service methods. Is there a possibility to GET the logout URL through the proxy? – Mickael Marrache Jan 06 '13 at 11:37
  • @MickaelMarrache, are you sure that the JAX client will cache the session cookie? – Michael-O Jan 06 '13 at 15:46
  • @Michael-O I think the JAX client will cache the JSESSIONID cookie since this is the client I use from the login to the logout. Also, I've set the BindingProvider.SESSION_MAINTAIN_PROPERTY property to true. – Mickael Marrache Jan 07 '13 at 08:36
0

Ok, I'm not gonna argue about stateful vs. stateless. If you need to logout from your Swing app just send an HTTP GET request to the configured logout URL sending the session ID along. You don't even need Apache HttpClient for this:

String url = "http://example.com/logout";
String charset = "UTF-8";
String session = ";jsessionid=" + sessionId;
URLConnection connection = new URL(url + session).openConnection();
connection.setRequestProperty("Accept-Charset", charset);
InputStream response = connection.getInputStream();
// ...

See https://stackoverflow.com/a/2793153/131929 (Firing a HTTP GET request) for details.

You can either append to session ID directly to the URL as shown above or send it as a regular cookie header like so:

connection.addRequestProperty("Cookie", "JSESSIONID=" + sessionId);
Community
  • 1
  • 1
Marcel Stör
  • 19,664
  • 12
  • 74
  • 171
  • Thanks for your answer, it is what I'm looking for but the session ID is sent as cookie that I can obtain from the HTTPConduit of CXF but I didn't see the session ID was sent as query parameter. – Mickael Marrache Jan 07 '13 at 09:40
  • It's not a query string parameter (sorry, corrected my code) but a special mechanism for user agents that don't support cookies e.g. if you disable cookies in your browser. See e.g. http://javarevisited.blogspot.ch/2012/08/what-is-jsessionid-in-j2ee-web.html for details. However, I added instructions as for how to set the session ID cookie. – Marcel Stör Jan 07 '13 at 12:13