Grouper Users - Open Discussion List

[Christopher Hubing <>]

On Tue, 11 Dec 2018, Redman, Chad wrote:

> 
> Hi Mark,
> 
>  
> 
> - grouper.ui.url is just used for constructing outgoing emails, so don't 
> need to worry about effects there
> 
>  
> 
> Weird that x-forwarded headers are being set but the (1) error is still 
> showing the request as http. What are the ui logs showing that show 
> x-forwarded-proto is being effective? If you're using a Docker
> container, it comes with its own Tomcat, so I would think something needs 
> to be set there.

When terminating TLS at the LB, there are a couple container tweaks we had 
to do, which I need to document in the README.

In your Apache configuration, add the following:
RemoteIPHeader X-Forwarded-For

Also, to force all constructed URLs to be https, modify the Tomcat 
server.xml and change the Connector stanza for AJP to deal with that by 
deleting add secure=“true” scheme=“https” and then it worked.

You can create a downstream server.xml and do something like the follwing 
in your Dockerfile:
COPY container_files/tomcat/server.xml /opt/tomcat/conf/

Mark, Internet2 has a pretty lively Slack network what has several Grouper 
channels that you might want to join. Would you like an invite?

-c


> 
>  
> 
> The (2) token missing error is weird too. If it's a sticky session issue, I 
> would expect it to be a token mismatch error. You could trace the session 
> with the browser debugger and see what headers are being sent.
> It should be sending the OWASP_CSRFTOKEN header, and the value should be 
> the right one for the form it was launched from.
> 
>  
> 
> Unlikely, but is it possible you have content security policy headers or 
> cookie security flags? CSP should allow inline scripts and eval. If you 
> have cookie security, the httpOnly flag doesn't work with Grouper
> since so much of it is ajax. And the secure flag works fine, but if you 
> access Grouper through non-SSL, you may see CSRF issues as the result of 
> not being able to retain a session without cookies. These options
> could be set by Tomcat, application web.xml, or maybe the proxy is adding 
> CSP or rewriting cookies.
> 
>  
> 
> -Chad
> 
>  
> 
>  
> 
>  
> 
>  
> 
> From: 
> 
>  
> [mailto:]
>  On Behalf Of Mark Day
> Sent: Monday, December 10, 2018 7:40 PM
> To: 
> 
> Subject: [grouper-users] CSRF errors in the Grouper UI
> 
>  
> 
> We're just getting started with a Grouper implementation, and I'm running 
> into problems with CSRF errors that pop up in two areas of the Grouper UI.
> 
>  
> 
> 1. When clicking on "Lite UI" under "Quick Links". The error is: 
> 
> Maybe your session timed out and you need to start again. This should not 
> happen under normal operation. CSRF error.
> 
> The UI logs show:
> 
>  ERROR CsrfGuardLogger.log(47) -  - Referer domain 
> https://<FQDN-redacted>/grouper/grouperUi/appHtml/grouper.html?operation=Misc.index
>  does not match request domain:
> http://<FQDN-redacted>/grouper/grouperExternal/public/OwaspJavaScriptServlet
> 
>  
> 
> 2. In the "+ Assign permission" function for a group, typing in the Action 
> field results in a 'error communicating with server' alert. The UI logs 
> show:
> 
> ERROR CsrfGuardLogger.log(47) -  - potential cross-site request forgery 
> (CSRF) attack thwarted (user:<redacted>, ip:<redacted>, method:GET,
> uri:/grouper/grouperUi/app/UiV2GroupPermission.permissionActionNameFilter, 
> error:required token is missing from the request)
> 
>  
> 
> The two types of CSRF Guard errors potentially have different causes, or 
> are slightly different symptoms of the same problem.
> 
>  
> 
> Specifics of our implementation:
> 
> - We're running Grouper in a container based off the 
> tier/grouper:2.3.0-a109-u47-w12-p21 image from DockerHub.
> 
> - There is an HAproxy-based reverse proxy service that is part of our 
> container orchestration infrastructure that terminates TLS connections from 
> the browser
> 
> - The UI container's logs show that  X-Forwarded-For, X-Forwarded-Proto, 
> and X-Forwarded-Port headers are populated correctly by the proxy.
> 
> - /opt/grouper/conf/grouper.properties sets grouper.ui.url to 
> https://<FQDN>/grouper/ (I've also tried https://<FQDN>/grouper/grouperUi/ 
> with the same results)
> 
>  
> 
> In the mailing list archives, I found a similar description to our 
> permission setting issue, but it looks like that specific problem was fixed 
> in UI patch 7, so I wouldn't expect to run into it with the TIER
> docker image we're using.  It feels like it's most likely associated with 
> our use of the container orchestration reverse proxy, but that's more a 
> hunch than anything else, and I'm not sure where to look next.
> 
>  
> 
> I'm not sure where else to look for a URL setting (apart from 
> grouper.properties) that may be specifying the http:// protocol, assuming 
> that this is in fact a separate problem.
> 
>  
> 
> Thanks for any suggestions you can offer,
> 
> Mark Day
> 
> NERSC / Lawrence Berkeley Lab
> 
>  
> 
> 
>