Grouper Users - Open Discussion List

["Hyzer, Chris" <>]

For our webapps we kill the java session and redirect to the SP logout, with a redirect to let the user globally logout…

 

https://grouper.school.edu/Shibboleth.sso/Logout?return=https://idp.school.edu/logout

 

yeah, I hear you on the shorter than an hour timeout… I think administrative apps have workers at a desk and might be ok with an hour, but yeah, if someone uses it at a public computer and doesn’t log out, that would be bad…

 

From: Bill Thompson <>
Sent: Monday, June 10, 2019 9:59 AM
To: Hyzer, Chris <>
Cc: Mailing List <>
Subject: Re: [grouper-users] Grouper UI default timeout in ITAP container

 

Interesting. When the user hits the log out button in Grouper, what happens to the SP session?

 

OWASP offers this advice regarding inactivity timeouts:

"The most appropriate timeout should be a balance between security (shorter timeout) and usability (longer timeout) and heavily depends on the sensitivity level of the data handled by the application. For example, a 60 minute log out time for a public forum can be acceptable, but such a long time would be too much in a home banking application (where a maximum timeout of 15 minutes is recommended). In any case, any application that does not enforce a timeout-based log out should be considered not secure, unless such behavior is required by a specific functional requirement."

https://www.owasp.org/index.php/Test_Session_Timeout_(OTG-SESS-007)

 

Best,

Bill

 

On Mon, Jun 10, 2019 at 7:06 AM Hyzer, Chris <> wrote:

Yes I think that is a substantial security improvement

 

Chris Hyzer

Application Architect

PennGroups, Two-step, NGSS Security

---

From: Bill Thompson <>
Sent: Sunday, June 9, 2019 6:27:00 PM
To: Hyzer, Chris
Cc: Mailing List
Subject: Re: [grouper-users] Grouper UI default timeout in ITAP container

 

So every http request is checking with the SP even when a user has a valid tomcat application session?

 

On Sun, Jun 9, 2019 at 5:36 PM Hyzer, Chris <> wrote:

Ive been embracing having the shib SP in front of entire UI applications, then only an authenticated (and authorized?) user can hack at the application.  Could be just apache and a proxy_ajp, or an apache reverse proxy in front of an application (e.g. non java).  Check a course grained entitlement to make sure the authenticated user is active at the institution.

 

Anyways, I guess you disagree with the default of 60 minutes, so we need to vote or something…  anyone else feel adamant about 30 min vs 60 min?

 

Thanks

Chris

 

From: Bill Thompson <>
Sent: Saturday, June 08, 2019 10:53 AM
To: Hyzer, Chris <>
Cc: Mailing List <>
Subject: Re: [grouper-users] Grouper UI default timeout in ITAP container

 

For applications that have their our session management, I tend to want to get the Shib SP out of the way as soon as possible to cut down on confusion and keep things simple. In this scenario the Shib SP is simply there to handle the SAML authN Response and hand-off the authenticated subject/netid to tomcat/grouper.  Application session management is then totally in the hands of tomcat/grouper.

 

In this setup, WebSSO session behavior is whatever the institution decides at the Shib IdP/CAS configuration level. Grouper application session management is completely controlled by however tomcat/grouper is configured. A reasonable default would be 30 minutes idle (aka inactivity) time, but folks could set that to whatever they want based on local policy.

 

Best,

Bill

 

On Fri, Jun 7, 2019 at 5:47 PM Hyzer, Chris <> wrote:

There are three timeouts at play in the Grouper UI with the ITAP container:

 

1. The tomcat java session inactivity timeout (current default config is 30 min)
2. The Shib SP timeout inactivity timeout (current default config is 8 hours)

1. The Shib SP session session lifetime (current default config is 8 hours)

3. The SSO IdP timeout (configured at each institution, my gut feeling is this is >= 1 hour generally)

 

Ive had complaints about 30 min sessions being too short.

 

In my mind, the current configuration does not make sense.  If the tomcat session dies in 30 minutes, the shib SP session will start another one (since active for 8 hours).  But whatever the person was working on will be interrupted and a potential CSRF error will occur.  I think the tomcat session should equal the shib SP session.  If the shib/tomcat is 30 minutes, and the typical SSO/Idp session is >= 60 minutes, then again the user is disrupted of their session, they do not need to login, but might experience an error.

 

We discussed this on slack, and I recommend we change the *default* shibSP / tomcat timeout to 60 minutes.  The 8 hour SP session lifetime should not change. In addition we will document how to overlay adjustments to the config. 

 

Also, btw, Matt Black suggested in jira that we change the UI to show a message about session timeout (so you aren’t surprised the next time you click) which I agree with and we can see if we can get something simple to work before too long.

 

Let us know any thoughts about this change.  😊

 

Thanks!