Grouper Users - Open Discussion List

[Chris Hyzer <>]

Are you saying that when you close all your browsers, and go directly to the 
lite UI, that Shib does not prompt you to authenticate?  I think the location 
block only protects the exact URL, and you need LocationMatch instead...   
e.g.

<LocationMatch /grouper.*>
 Authtype shibboleth
 ShibRequireSession On
require valid-user
</LocationMatch>

Thanks,
Chris

-----Original Message-----
From: Richard James 
[mailto:]
 
Sent: Thursday, February 04, 2010 9:53 AM
To: Chris Hyzer; 

Subject: RE: [grouper-users] Lite UI Authentication

Hi Chris,

To protect Grouper with Shib we have the following location block within our 
Shib conf file, so protecting all grouper files.

<Location /grouper>
 Authtype shibboleth
 ShibRequireSession On
require valid-user
</Location>

We also configure our Tomcat server to take the headers from Apache using 
tomcatAuthentication="false" in the AJP (8009) connector in the Tomcat 
server.xml configuration file (we're using mod_proxy to forward requests for 
/grouper to our Tomcat install). 


We're not using lazy session, as you can see in the location block above, 
(i.e. Shib login is required to access any of the Grouper pages).  We have 
our users go directly through to the admin UI once they have created a 
session with Shib, so missing out the grouper application login page. This 
has been successful for us to try and help with the single sign on approach. 
Hopefully if we can configure this to work the same way with the Lite Ui that 
will be great.

Thanks

Richard

>-----Original Message-----
>From: Chris Hyzer 
>[mailto:]
>Sent: 03 February 2010 16:27
>To: Richard James; 
>
>Subject: RE: [grouper-users] Lite UI Authentication
>
>What is your apache configuration that you are using to protect Grouper?
>(using the location directive or location match, or .htaccess?
>
>I haven't done this yet, but will soon.  My plan is to protect the
>entire Grouper application with our single signon apache filter.  I know
>other people like to leave the main page unprotected and have a "login"
>link.  I will do something like this in the httpd.conf that will protect
>all grouper files (regular and lite)
>
><LocationMatch /grouper/.*>
>  WhateverDirectiveMakes theUserLogin
></LocationMatch>
>
>Then when you go to the lite UI apache will make you login.
>
>Let me know if this helps.
>
>Thanks,
>Chris
>
>-----Original Message-----
>From: 
>
> 
>[mailto:]
>Sent: Wednesday, February 03, 2010 10:44 AM
>To: 
>
>Subject: [grouper-users] Lite UI Authentication
>
>Hi All,
>
>First of all just want to say great work on the latest version of
>Grouper, the auditing features and the new Lite UI will be of great
>benefit to us. Also, thanks for the release for the bug fixes as this
>solved an issue we were having when attempting to do an import via the
>GSH xml-import tool :)
>
>We are having one problem regards to the Lite UI, we have successfully
>deployed both the admin UI and the lite UI, and successfully managed to
>log in to both interfaces using Tomcat authentication. Though when we
>turn Tomcat authentication off, and protect the UI's with Shib, we are
>coming across some problems.
>
>If logging into the admin UI via http://<server-name>/grouper, we are
>directed to our Shib login page, once credentials are entered we are
>then directed through to the grouper home page and are presented with
>the root stem.
>
>Though if we attempt to login into the admin UI via https://<server-
>name>/grouper/callLogin.do or the Lite UI via https://<server-
>name>/grouper/grouperUi/appHtml/grouper.html?operation=SimpleMembershipU
>pdate.index we encounter "HTTP Status 403 - Access to the requested
>resource has been denied." I presume this is because these are calling
>the java login functions unlike the
>http://<server-name>/grouper URL which is redirected straight through to
>the home.do page. Looking into the logs there is the following entry;
>
>28-Jan-2010 11:27:39 org.apache.catalina.core.ApplicationDispatcher
>invoke
>SEVERE: Servlet.service() for servlet action threw exception
>java.lang.NullPointerException
>at
>edu.internet2.middleware.grouper.ui.GrouperUiFilter.retrieveSessionNavRe
>sourceBundle(GrouperUiFilter.java:96)
>at
>edu.internet2.middleware.grouper.ui.actions.PopulateErrorAction.execute(
>PopulateErrorAction.java:72)
>at
>org.apache.struts.action.RequestProcessor.processActionPerform(RequestPr
>ocessor.java:424)
>at
>org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:
>226)
>at
>org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
>at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:397)
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>     at
>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
>tionFilterChain.java:290)
>     at
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
>erChain.java:206)
>     at
>org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatc
>her.java:646)
>     at
>org.apache.catalina.core.ApplicationDispatcher.processRequest(Applicatio
>nDispatcher.java:438)
>     at
>org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDisp
>atcher.java:374)
>     at
>org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispat
>cher.java:302)
>     at
>org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java
>:416)
>     at
>org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java
>:343)
>     at
>org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
>:144)
>     at
>org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
>:102)
>     at
>org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
>java:109)
>     at
>org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2
>93)
>     at
>org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
>     at
>org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
>     at
>org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:769)
>     at
>org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:
>698)
>     at
>org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.
>java:891)
>     at
>org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool
>.java:690)
>     at java.lang.Thread.run(Thread.java:619)
>
>Not sure why this is, I guess it maybe something to do with the way the
>LoginCheckFilter works with Grouper. I have looked around the code to
>try and work this out but so far with no success, the only assumption I
>can make is that it is failing to retrieve HTTP session details when
>invoking the retrieveHttpServletRequest method. Does anyone else protect
>Grouper via Shib and has come across this problem? Or anyone have any
>ideas on how we can get round this?
>
>Many Thanks
>
>Richard James
>ISS Middleware Team
>Newcastle University
>
>