Grouper Users - Open Discussion List

[Chris Hyzer <>]

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=SimpleMembershipUpdate.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.retrieveSessionNavResourceBundle(GrouperUiFilter.java:96)
at 
edu.internet2.middleware.grouper.ui.actions.PopulateErrorAction.execute(PopulateErrorAction.java:72)
at 
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.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(ApplicationFilterChain.java:290)
     at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
     at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646)
     at 
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:438)
     at 
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374)
     at 
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.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:293)
     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