Automatic login timeout/expiration?

[darknight]

I have a client that has access to jboss/EJB and performs auth via JAAS.
Periodically the client makes remote calls, about every 30 seconds. What
happens is that after some time the login data seems to be lost and the
client needs to re-auth, however the way the login module works makes
this impossible because it will detect that client "A" is already
connected to the system, the result is that the client fails to work
(remote exception).

Is there some config option I can change to avoid this? Isn't the
repeated access to the beans enough to avoid loosing the login
(obviously it's not)?

[_alex]

What happens is that after some time the login data seems to be lost and the client needs to re-auth,

IMHO:
check that the client calls the secured beans in the security domain;
check periodically the contents of the security cahce through JMX console;

however the way the login module works makes this impossible because it will detect that client "A" is already connected to the system, the result is that the client fails to work (remote exception).

are you sure that this behavoiur is really desired from requirements?

Is there some config option I can change to avoid this? Isn't the repeated access to the beans enough to avoid loosing the login (obviously it's not)?

the repeated access to the beans in the security domain _should_ be enough. The default security cache timeout is half of a hour (see jboss-service.xml in conf directory).

in general - more precise information is required about you case - the design, the configuration, may be exceptions stack etc.

Alexander

[darknight]

Thank you for replying.
I have investigated more and I assume that the security cache timeout occurs even if the authed client makes access to one bean while another is inactive, I still have to be sure about this and will try to look in the cache with JMX console.

And yes, the "already logged" behaviour is desired for good reasons that have to do with the client side of the application.

[annegret]

The JAASSecurityManager has a standard cachetimeout. I'm not sure to which values it is set by default. You can change it by adding a value in jboss-service.xml

<!-- JAAS security manager and realm mapping -->
 <mbean code="org.jboss.security.plugins.JaasSecurityManagerService"
 name="jboss.security:service=JaasSecurityManager">
 <attribute name="SecurityManagerClassName">
 com.tenovis.oam.i33.as.security.JaasSecurityManager
 </attribute>
 <attribute name="DefaultCacheTimeout">7200</attribute>
 </mbean>

After this time the ServerLoginModule will be called once more to restore the cache.
Maybe this is Your problem ???

Annegret

[darknight]

Maybe, but unfortunately the times do not coincide. I have set DefaultCacheTimeout to 300 via JMX console and the problem still occurs after 20-30 minutes.
Right now I'm trying to find a different route to solve the problem since I can't track it's root (namely, I'm toying with my custom loginmodule).

[_alex]

Darknight wrote:
I have set DefaultCacheTimeout to 300 via JMX console

I am not sure that this particular modifications, which are done through JMX console, will change the actual timeout of the security cache. Change the timeout in the xml file and restart the server.

Alexander

[darknight]

That worked!
As soon as the cache expires the client is kicked from jboss.
So I have narrowed the problem and will go on trying to fix it.
My question is: why a cache? Or rather, why do you need to re-auth after some time? I think this is related to web sessions and the like and makes little sense in a swing app environment.

[darknight]

I gave up on modifying the loginmodule, I circumvented the problem this way: the client will perform a mandatory post-create initialization which will perform all additional required checks.
It seemed cleaner to me to perform every check in one place but it turned out far too difficult and clumsy.

[starksm64]

A cache prevents lookup against an ldap server, database, etc. becoming a bottleneck in a call path. You can disable caching by setting the DefaultCacheTimeout to 0.