[OPENAM-4413] Agent sessions are affected by active session quotas when com.iplanet.am.session.agentSessionIdleTime is used Created: 01/Sep/14  Updated: 20/Nov/16  Resolved: 11/Dec/14

Status: Resolved
Project: OpenAM
Component/s: authentication, session
Affects Version/s: 10.0.0, 11.0.0
Fix Version/s: 10.0.3, 11.0.3, 12.0.1, 13.0.0

Type: Bug Priority: Major
Reporter: Ian Packer [X] (Inactive) Assignee: Peter Major [X] (Inactive)
Resolution: Fixed Votes: 0
Labels: release-notes
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File openam-4413-diff.txt    
Issue Links:
Duplicate
is duplicated by OPENAM-1682 Set session.setType(Session.USER_SESS... Resolved
is duplicated by OPENAM-6059 Agent sessions appear in console Resolved
Support Ticket IDs:

 Description   

If advanced server property 'com.iplanet.am.session.agentSessionIdleTime' is set to something other than 0 (i.e agent sessions will get timed out), OpenAM begins enforcing active session quotas on the agent users.

"2014-08-23 09:25:56"	"Maximum Sessions Limit Reached.|module_instance|Application"	id=WebAgent,ou=agent,dc=openam,dc=forgerock,dc=org	"Not Available"	192.168.56.3	INFO	dc=openam,dc=forgerock,dc=org	"cn=dsameuser,ou=DSAME Users,dc=openam,dc=forgerock,dc=org"	AUTHENTICATION-268	Application	"Not Available"	192.168.56.3

To reproduce:

  • Setup vanilla openam and agent install.
  • Check normal operation, ensure agent uses more than 2 sessions.
  • In OpenAM, set com.iplanet.am.session.agentSessionIdleTime to 120
  • Reboot OpenAM
  • Check normal operation, ensure agent uses more than 2 sessions.
  • Enable Quota Constraints and change to DENY_ACCESS. Set maximum to 2 session (or 1).
  • Observe agent begin to fail due to failed logins.

 Comments   
Comment by Jari Ahonen [ 03/Sep/14 ]

Attached is a patch that fixes this bug.

I'm not sure about the reasoning behind treating all expiring sessions as user sessions in InternalSession.isAppSession() but flagging all sessions as user sessions in LoginState.setSessionProperties() is clearly not right.

Comment by Peter Major [X] (Inactive) [ 03/Sep/14 ]

Jari, the issue with LoginState is tracked under OPENAM-1682.

Comment by Jari Ahonen [ 03/Sep/14 ]

Thanks Peter, looks like the proposed fix in that one is exactly the same as what I came up with.

OPENAM-1682 does not address the problem in InternalSession.isAppSession() though. Do you have any insight why that method looks at the session expiration flag ? That seemed very odd to me.

Comment by Peter Major [X] (Inactive) [ 09/Dec/14 ]

After looking at this a bit further, this issue will also result in enforcing the maximum session limit when the com.iplanet.am.session.agentSessionIdleTime setting is enabled. To test this, simply authenticate 5001 times using module=Application.

Comment by Peter Major [X] (Inactive) [ 09/Dec/14 ]

Jari Ahonen had a look at the logic, and there is no immediate reason to check for the willExpireFlag as well, since it looks like setType(Session.APPLICATION_SESSION) and setExpire(false) is always called together.
Looking at the history:
https://github.com/aldaris/opensso/commit/fcef37f0ec928efc1e3c21baefc337bb4ee34215
This suggests that in the past only willExpireFlag was used to detect if the session quotas apply, and this logic was only added when the agent session timeout has been implemented.

Comment by Jari Ahonen [ 10/Dec/14 ]

Hi,

I have used the patch I attached earlier to get around this problem. It seems to work fine but it has one side-effect: The active session counts reported in the statistics seem to go wrong (the active session counts in amMasterSessionTableStats are (much) lower than what you see in admin console).

No idea why this happens, I tried to track it down but lost interest as finding the problem seemed complicated and it wasn't that important for me.

Comment by Peter Major [X] (Inactive) [ 11/Dec/14 ]

Fixed with R11787 R11788 and R11789

Comment by Peter Major [X] (Inactive) [ 28/Jan/15 ]

Backported with R12241

Generated at Mon Jan 25 04:19:11 UTC 2021 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.