concurrent session with websphere problem

[erl26442]

hello everyone,

i have a problem using spring security 3.0.5 with websphere 7.0.0.13 specifically about concurrent session.

in my application i need to restrict a second user to login into our application using an already logged in username.

this is my session management security configuration

<sec:session-management session-authentication-error-url="/loginWindow.zul?max_open_session=1">
<sec:concurrency-control max-sessions="1" expired-url="/loginWindow.zul" error-if-maximum-exceeded="true"/>
</sec:session-management>

as you can see i'm using the default classes for session management.

and i have HttpSessionEventPublisher in my web.xml.

the problem is, when a user logs in using a username, then session timeout occur, sometimes that user cannot log back in.

it seems the session id is still registered in the SessionRegistry.

i've tried this configuration using tomcat and it works just fine.

any idea why is this happening?

any help would be very appreciated.

thank you in advance.

regards,
Erlangga

[skram]

Maybe the following information may provide some clue:

Adding the listener to web.xml causes an ApplicationEvent to be published to the Spring ApplicationContext every time a HttpSession commences or terminates. This is critical, as it allows the SessionRegistryImpl to be notified when a session ends. Without it, a user will never be able to log back in again once they have exceeded their session allowance, even if they log out of another session or it times out.

Source: http://static.springsource.org/sprin...ted-principals

But you said you've already added the listener in the web.xml and your configuration works perfectly fine in Tomcat but not in WebSphere.

Can you try running it in Jetty? If it does run, then probably a configuration with WebSphere is a culprit. Or a new bug?

[erl26442]

hi skram, thank you for your reply.

yes, i already have the HttpSessionEventPublisher in my web.xml

honestly i'm not familiar with jetty, i've only user tomcat and websphere so far. so it would take time to test it using jetty. i'll see what i can do.

is there any other workaround about this?
should i implement my own SessionRegistry?

[skram]

Did you put the ConcurrentSessionFilter inside the http tag?

The ConcurrentSessionFilter requires two properties, sessionRegistry, which generally points to an instance of SessionRegistryImpl, and expiredUrl, which points to the page to display when a session has expired.

In the example code (from the reference)

<http>
  <custom-filter position="CONCURRENT_SESSION_FILTER" ref="concurrencyFilter" />
 ...

  <session-management session-authentication-strategy-ref="sas"/>
</http>

There's a reference to a session authentication strategy:

<beans:bean id="sas" class=
 "org.springframework.security.web.authentication.session.ConcurrentSessionControlStrategy">
  <beans:constructor-arg name="sessionRegistry" ref="sessionRegistry" />
  <beans:property name="maximumSessions" value="1" />
</beans:bean>

Which has a reference to a sessionRegistry.

Does yours have a reference to a sessionRegistry?

<sec:session-management session-authentication-error-url="/loginWindow.zul?max_open_session=1">
<sec:concurrency-control max-sessions="1" expired-url="/loginWindow.zul" error-if-maximum-exceeded="true"/>
</sec:session-management>

[erl26442]

i don't explicitly reference a SessionRegistry. as i have stated before. i use default configuration, which means the filter, sessionregistry, etc used is spring security default.

The <concurrency-control> Element
Adds support for concurrent session control, allowing limits to be placed on the
number of active sessions a user can have. A ConcurrentSessionFilter will
be created, and a ConcurrentSessionControlStrategy will be used with the
SessionManagementFilter. If a form-login element has been declared, the strategy object
will also be injected into the created authentication filter. An instance of SessionRegistry (a
SessionRegistryImpl instance unless the user wishes to use a custom bean) will be created for
use by the strategy.

i have tried explicitly to reference the session registry to SessionRegistryImpl using the default configuration like in the reference manual. but still some session get locked if a timeout occur.