Grouper Users - Open Discussion List

[Chris Hyzer <>]

It is really unfortunate that that happened.  Thanks so much for tracking it 
down though.

-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Baron Fujimoto
Sent: Tuesday, December 15, 2015 9:53 PM
To: Grouper Users
Subject: Re: [grouper-users] Grouper 2.2 w/ CAS AuthN logout, CSRF error

I'm not sure if this is a long term solution, but we at least have a
workaround now.

The Tomcat devs hypothesized that the behavior resulted from the following
change for Tomcat 8.0.29:

"Move the functionality that provides redirects for context roots and
directories where a trailing / is added from the Mapper to the
DefaultServlet. This enables such requests to be processed by any
configured Valves and Filters before the redirect is made. This behaviour
is configurable via the mapperContextRootRedirectEnabled and
mapperDirectoryRedirectEnabled attributes of the Context which may be used
to restore the previous behaviour."

And a workaround that restores the previous behavior is to add the
following attributes to ${CATALINA_BASE}/conf/context.xml:

mapperContextRootRedirectEnabled="true"
mapperDirectoryRedirectEnabled="true"

e.g.:

<Context mapperContextRootRedirectEnabled="true"
         mapperDirectoryRedirectEnabled="true">
    [...]
</Context>


On Fri, Dec 11, 2015 at 04:57:30PM -1000, Baron Fujimoto wrote:
>I sort of got taken to task on tomcat-users for assuming the problem
>was with their REST CSRF protection filter (and that it was enabled by
>default). I've been asked though how the [OWASP] CSRF protection
>is adding the token in order to help guide a search through their
>changelog. Can any one fill in the details or provide a reference to
>the information they seek? Else, all I really have to offer is the
>OWASP CSRFGuarf Project page at
>
><https://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project>
>
>and our grouper-ui/conf/Owasp.CsrfGuard.*properties files (I don't
>think there's any sensitive info in there).
>
>If anyone is curious, this thread in the tomcat-users mailing list
>can be followed at
>
><http://tomcat.10.x6.nabble.com/CSRF-errors-after-upgrade-of-tomcat-8-td5043864.html>
>
>-baron
>
>On Fri, Dec 11, 2015 at 10:28:13AM -1000, Baron Fujimoto wrote:
>>Apparently it's on by default, since I didn't do anything to explicitly
>>enable it. Unfortunately, I don't see anything in the documentation on how
>>to disable it. I'll query the tomcat-users mailing list.
>>
>>-baron
>>
>>On Fri, Dec 11, 2015 at 03:43:09PM +0000, Chris Hyzer wrote:
>>>Is it on by default?  Can you disable it?  If Grouper has CSRF protection, 
>>>then I think you don't need anything from the container...  its not as 
>>>simple as just turning it on, it takes a lot of carefully configuration 
>>>about which URLs need protection etc.
>>>
>>>Thanks,
>>>Chris
>>>
>>>-----Original Message-----
>>>From: 
>>>
>>> 
>>>[mailto:]
>>> On Behalf Of Baron Fujimoto
>>>Sent: Thursday, December 10, 2015 9:42 PM
>>>To: Grouper Users
>>>Subject: Re: [grouper-users] Grouper 2.2 w/ CAS AuthN logout, CSRF error
>>>
>>>Unearthed this in the Tomcat Changelogs for 8.0.29, which seems like a
>>>candidate:
>>>
>>>"Add a new RestCsrfPreventionFilter that provides basic CSRF protection
>>>for REST APIs."
>>>
>>>Now trying to make sense of this Tomcat documentation:
>>>
>>><https://tomcat.apache.org/tomcat-8.0-doc/config/filter.html#CSRF_Prevention_Filter_for_REST_APIs>
>>>
>>>I don't yet know if the problem is the result of something I need to do
>>>with Tomcat's new RestCsrfPreventionFilter, or some interaction between
>>>it and Grouper's existing owasp.csrfguard.* stuff (or something else
>>>altogether).
>>>
>>>Presumably there should be an appropriate <Filter> element that goes in
>>>the UI's web.xml. Assuming I can sort out how to correctly update web.xml,
>>>what's the best way to have it incorporated as part of the build process?
>>>Or would you need to update it after the build? The current web.xml
>>>advises, "CHANGE YOUR FILE specified by the build.properties value
>>>[additional.web.xml]. The contents of that file are merged into
>>>${grouper-ui}/webapp/WEB-INF/web.core.xml" However, when I specify the
>>>following in the grouper-ui's build.properties:
>>>additional.web.xml=${basedir}/path/to/additional-web.xml I don't see the
>>>contents of additional-web.xml incorporated anywhere in the resulting
>>>web.xml after the build.
>>>
>>>Aloha,
>>>-baron
>>>
>>>On Thu, Dec 10, 2015 at 02:31:00PM -1000, Baron Fujimoto wrote:
>>>>Thanks for the pointers. Doing a little more due diligence, I realized
>>>>that the Grouper versions weren't the only difference in the environments.
>>>>The 2.2.1 env was running under Tomcat 8.0.24, and the 2.2.2 env was
>>>>running under the latest 8.0.30. I upgraded the 2.2.1 env Tomcat to 8.0.30
>>>>and now see the CSRF errors there as well. Backing out to 8.0.24 restores
>>>>the working behavior, so this seems like a smoking gun. The Tomcat configs
>>>>should be the same between the two instances, so I'll go review the Tomcat
>>>>changelogs for any documented clues to account for the difference between
>>>>these versions.
>>>>
>>>>Aloha,
>>>>-baron
>>>>
>>>>On Thu, Dec 10, 2015 at 09:24:13AM -0500, Waldbieser, Carl wrote:
>>>>>
>>>>>Followup: Looking in my notes, the header in question is "OWASP_CSRF".  
>>>>>We use Nginx, which strips out headers with underscores by default.  the 
>>>>>setting "underscores_in_headers on;" in the "nginx.conf" file allows 
>>>>>that header.
>>>>>
>>>>>Thanks,
>>>>>Carl
>>>>>
>>>>>----- Original Message -----
>>>>>From: "waldbiec" 
>>>>><>
>>>>>To: "Baron Fujimoto" 
>>>>><>
>>>>>Cc: "Grouper Users" 
>>>>><>
>>>>>Sent: Thursday, December 10, 2015 9:18:01 AM
>>>>>Subject: Re: [grouper-users] Grouper 2.2 w/ CAS AuthN logout, CSRF error
>>>>>
>>>>>Baron,
>>>>>
>>>>>Not sure if this helps, but when we first set up Grouper, we ran afoul 
>>>>>of the CSRF checks because our proxy was not handling an HTTP header 
>>>>>correctly.
>>>>>I am not sure how you are using CAS (integrated vs. apache + 
>>>>>mod_auth_cas) or what your deployment architecture is like, so I am not 
>>>>>sure if that helps.
>>>>>
>>>>>Thanks,
>>>>>Carl Waldbieser
>>>>>ITS Systems Programmer
>>>>>Lafayette College
>>>>>
>>>>>----- Original Message -----
>>>>>From: "Baron Fujimoto" 
>>>>><>
>>>>>To: "Grouper Users" 
>>>>><>
>>>>>Sent: Wednesday, December 9, 2015 10:32:26 PM
>>>>>Subject: [grouper-users] Grouper 2.2 w/ CAS AuthN logout, CSRF error
>>>>>
>>>>>While testing our Grouper 2.2 UI deployment which uses CAS for
>>>>>authentication, I encountered the following situation:
>>>>>
>>>>>- Log out
>>>>>
>>>>>This puts me back at the usual page at
>>>>><https://grouper-future.its.hawaii.edu/grouper/logout.do> with the 
>>>>>warning
>>>>>text, "The only way to be sure that you have logged out is to close ALL
>>>>>browser windows."
>>>>>
>>>>>If I then attempt to log back in from this screen, it sends me back to 
>>>>>the
>>>>>CAS login page as expected, but after authenticating with CAS I am
>>>>>redirected back to a Grouper error page which says "You have an anonymous
>>>>>session since you are not logged in, but this section requires you to be
>>>>>logged in. Maybe No username found. Your identity provider might not be
>>>>>sending your username to this application. Either you need to use a
>>>>>different identity provider, or ask your IT department to send your
>>>>>username to this application."
>>>>>
>>>>>In 2.2.1 if I click on the offered option to "Start over" it sends me 
>>>>>back
>>>>>to /grouper and all proceeds as expected (presumably reusing my existing
>>>>>CAS session).
>>>>>
>>>>>With 2.2.2 I am redirected to an error page that says, "Maybe your 
>>>>>session
>>>>>timed out and you need to start again. This should not happen under 
>>>>>normal
>>>>>operation. CSRF error" and the following gets logged:
>>>>>
>>>>>ERROR CsrfGuardLogger.log(47) -  - potential cross-site request forgery 
>>>>>(CSRF) attack thwarted (user:<anonymous>, ip:xxx.xxx.xxx.xxx, 
>>>>>method:GET, uri:/grouper/grouperUi, error:required token is missing from 
>>>>>the request)
>>>>>
>>>>>No matter what I try from this point, including quitting and restarting
>>>>>my browser, using the browser's private browsing features, and even
>>>>>incredibly (to me) restarting the UI webapp won't get me past this when I
>>>>>try to go back to /grouper.
>>>>>
>>>>>Any ideas on why it's not matching the 2.2.1 behaviour?
>>>>>
>>>>>Also, FWIW, whenever one of those error pages is loaded, the following
>>>>>string is also logged with no context or additional information,
>>>>>"Institute of Higher Education". I've tracked this down to
>>>>>
>>>>>grouper.ui/conf/grouperText/grouper.text.en.us.base.properties:
>>>>>institutionName = Institute of Higher Education
>>>>>
>>>>>Where I suppose we could customize it in grouper.text.en.us.properties?
>>>>>However, logging this string as it does currently doesn't seem to serve
>>>>>any useful purpose?

-- 
Baron Fujimoto 
<>
 :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum