Grouper Users - Open Discussion List

["Hyzer, Chris" <>]

yes

-----Original Message-----
From: Bill Thompson <> 
Sent: Tuesday, June 11, 2019 9:52 PM
To: Hyzer, Chris <>
Cc: Gettes, Michael <>;  Mailing 
List <>
Subject: Re: [grouper-users] Grouper UI default timeout in ITAP container

This all sounds fine. When you say "reauth", are we talking about a
round trip to the IdP with ForceAuthn set?

On Mon, Jun 10, 2019 at 4:37 PM Hyzer, Chris <> wrote:
>
> Hmmm, I think we need to survey to see if people want to do a survey…
>
>
>
> Ok… I expect:
>
>
>
> If someone uses grouper and stopped using grouper for a long period of 
> time, they will need to authenticate again to use it again
> If someone gets distracted for a little while, and goes back to grouper, 
> they will not need to login
> If someone has been using grouper continuously, they should have to reauth 
> eventually
> SSO session hijacking shouldn’t get someone into grouper (unless the user 
> has recently used grouper)
> It should be difficult for people external to the institution to try to 
> hack grouper
>
>
>
> So, I would like to do:
>
>
>
> Session inactivity of 60 minutes, then reauth (used to be 8 hours)
> Max session length of 8 hours, then reauth (not a change)
> Require reauth set to true (used to be false)
> /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!
>
> >