Skip to Content.
Sympa Menu

grouper-users - RE: [grouper-users] [Ext] Grouper UI default timeout in ITAP container

Subject: Grouper Users - Open Discussion List

List archive

RE: [grouper-users] [Ext] Grouper UI default timeout in ITAP container

Chronological Thread 
  • From: "Redman, Chad" <>
  • To: "Black, Carey M." <>, Bryan Wooten <>, "Hyzer, Chris" <>, " Mailing List" <>
  • Subject: RE: [grouper-users] [Ext] Grouper UI default timeout in ITAP container
  • Date: Sat, 8 Jun 2019 20:19:51 +0000

On Friday, June 07, 2019 10:21 PM Black, Carey M. wrote:


> It also prevents the “full impersonation of a user” to the application from the IdP. 😊


Hi Carey, did you mean the Shibboleth impersonation in 3.4? This is only enabled for specific relying parties via configuration. So users wouldn't be impersonated in Grouper without it specifically being allowed. And there are also authorization controls for who can impersonate and be impersonated. We certainly wouldn't want a non-wheel user impersonating a wheel :)





From: [mailto:] On Behalf Of Black, Carey M.
Sent: Friday, June 07, 2019 10:21 PM
To: Bryan Wooten <>; Hyzer, Chris <>; Mailing List <>
Subject: RE: [grouper-users] [Ext] Grouper UI default timeout in ITAP container




You added that bit about my Jira just so I would not comment and add to the thread.  Thank you.  😊 

                But you forgot to include the GRP link so others could “up vote” (current count = 0 ) or “comment on it” (current count = 0 ) too. ( So close, but I still get to comment! 😊 )




And a bit of an aside… ( but partially prompted by Bryan’s comments. )


What do you think about extending the Grouper Login process/application processes to support a “MFA step up” logic?

I have been considered the idea of asking for MFA support directly in the Grouper application.

                It also prevents the “full impersonation of a user” to the application from the IdP. 😊

                The notion that a full break of the  IdP could be mitigated by an application that does MFA after the IdP was kicked around internally.


                For some tools (security related, broad reach/range, etc…) that seems like a superior security design to require some Authentication factor in the application itself.

                Basically the app would only do “MFA” auth internally, but still use the IdP for the SSO “first auth”.)

                Grouper could use “local MFA” at login *and* at “important application events” to verify the user is still who they need to be. ( Fight unattended terminal problems and use before crucial changes are made in Grouper. )

                It could add defenses to “Wheel”(or other special groups members actions), and “guard the gates” for approvals, workflows, attestations, template usage, etc…

                Maybe a kind of “SecurityHook” that could be enabled for “standard events”(via config) or coded and extended for any custom logic/events?


                Bonus: ( likely beyond the vail of what anyone else would want to do… But it is an extended idea…)

                                And if one was really paranoid then each app could choose to use their own “local” MFA instead of relying on a shared service (like Duo) too. (Obviously with added service over head/management/maintenance per app.)


Just a thought (kind of) on the topic.



Carey Matthew


From: <> On Behalf Of Bryan Wooten
Sent: Friday, June 7, 2019 5:59 PM
To: Hyzer, Chris <>; Mailing List <>
Subject: Re: [grouper-users] [Ext] Grouper UI default timeout in ITAP container


I agree with Chris 100%.


I think this is an institutional / policy issue.


So many meetings/questions re: timeout. CAS vs. Shib. vs. individual applications (Cloud / Peoplesoft / custom in house). Oh, and let’s add “remember me” and MFA. Sorry, let’s add password change policies to the mix.


Between CAS and Shib we have over 1000 servers and probably 1500+ applications, there is no way I can herd all those cats.


I get confused between my social/entertainment sites, my bank and work… We are all just users that want consistency. Or at least sanity.




From: <> on behalf of Chris Hyzer <>
Reply-To: Chris Hyzer <>
Date: Friday, June 7, 2019 at 3:47 PM
To: "" <>
Subject: [Ext] [grouper-users] Grouper UI default timeout in ITAP container


WARNING: Stop. Think. Read. This is an external email.

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)
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.  😊



Archive powered by MHonArc 2.6.19.

Top of Page