Grouper Users - Open Discussion List

["Hyzer, Chris" <>]

Hmmm, I think we need to survey to see if people want to do a survey…

 

Ok… I expect:

 

1. If someone uses grouper and stopped using grouper for a long period of time, they will need to authenticate again to use it again
2. If someone gets distracted for a little while, and goes back to grouper, they will not need to login
3. If someone has been using grouper continuously, they should have to reauth eventually
4. SSO session hijacking shouldn’t get someone into grouper (unless the user has recently used grouper)
5. It should be difficult for people external to the institution to try to hack grouper

 

So, I would like to do:

 

1. Session inactivity of 60 minutes, then reauth (used to be 8 hours)
2. Max session length of 8 hours, then reauth (not a change)
3. Require reauth set to true (used to be false)
4. /grouper is protected by shib (not a change)

 

All of those things are adjustable with container overlays, and we can document it.

 

Ok?  😊

 

Thanks!

 

From: Bill Thompson <>
Sent: Monday, June 10, 2019 4:24 PM
To: Hyzer, Chris <>
Cc: Gettes, Michael <>; Mailing List <>
Subject: Re: [grouper-users] Grouper UI default timeout in ITAP container

 

Rather than a survey, I'd suggest you just propose what you expect the system behavior to should be from an end-user perspective. Then let that drive the default technical configuration and deployer options. Campuses have different tolerances and approaches for WebSSO and application session behaviors. This will be no different.

 

Best,

Bill

 

 

On Mon, Jun 10, 2019 at 2:43 PM Hyzer, Chris <> wrote:

Does this survey cover it?  Should we get people to weigh in via survey or a better process?  I snuck in a question about require reauth too...

 

Thanks

Chris

 

 

-----Original Message-----
From: <> On Behalf Of Bill Thompson
Sent: Monday, June 10, 2019 10:53 AM
To: Gettes, Michael <>
Cc: Hyzer, Chris <>; Mailing List <>
Subject: Re: [grouper-users] Grouper UI default timeout in ITAP container

 

Yes, deployers should be able to change reasonable default settings.

The issue is that the current ITAP grouper container default settings

are not reasonable. The core proposal from hyzer is "I think the

tomcat [inactivity] session should equal the shib SP [inactivity]

session". I doubt there will be any objections to that. What exactly

the default inactivity timeouts should be for an IAM component is what

is up for debate I suppose.

 

The sub discussion is simply if/why the additional SP session needs to

be involved at all.

 

Best,

Bill

 

On Mon, Jun 10, 2019 at 10:40 AM Gettes, Michael <> wrote:

> 

> I’m a wee bit confused here.  What we are talking about is what the initial or recommended setting would be.  A grouper admin could always change the settings by directly updating the relevant config (which I believe we should be clearly documenting if we haven’t) or overlaying the config if using containers (which of course everyone should be moving towards, IMHO)?  It’s not like we are saying EVERYONE MUST adhere to this config.  People can still do as they wish.  Changing this is really about getting those who choose not to modify anything to maybe complain less to the community/developers?

> 

> Of course, what would be really nice is if grouper-ui doing all its ajax-y stuff could better detect a re-auth “fail” and better handle it but I do appreciate how that can be hard to do.

> 

> /mrg

> 

> > On 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:

> >

> >       • The tomcat java session inactivity timeout (current default config is 30 min)

> >       • The Shib SP timeout inactivity timeout (current default config is 8 hours)

> >               • The Shib SP session session lifetime (current default config is 8 hours)

> >       • 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!

>