Building GridSphere with Shibboleth support
The default behavior of GS assumes that all user management will be performed at the GS instance. This is OK for an isolated install but applications in the UABgrid system environment should be configured to trust the sytem for user and group definitions.
One of the best tools to accomplish this level of integration is Shibboleth. GS doesn't ship with Shibboleth support. The folks at MAMS have developed a Shibboleth support patch for the 3.0.5 release of GS. This is the documentation of our experience applying this patch and the functionality it provides.
- Download Shibbolized GridSphere 3.0.5 from the link above.
- Extract to a folder
- Remove all references to gridsphere in CATALINA_BASE. (This Shibbolized GS is also called gridsphere, so when I installed it without removing from Tomcat, I did not see the Shibboleth login button).
- Follow our regular instructions for installing Gridsphere. These instructions assume that, Tomcat is installed in the usr directory. However, we will be working on the tomcat installed within our home directory. Make the appropriate changes wherever necessary. You may skip the step of applying patch to the build.xml file.
- Go to http://localhost:8080/gridsphere/gridsphere. Once you create the login for the admin account, click the Login link. You should see a button for Login from Shibboleth.
- Note: If you get a 500 error when viewing Shibbolized GridSphere built with Eclipse but do not when using the usual CATALINA_BASE and CATALINA_HOME, then refer to the Readme-from-Alan.txt, which comes in your Shibbolized GridSphere installation. In particular, you may have to do the step involving copying gridsphere-context.xml to CATALINA_HOME/conf/Catalina/localhost. You may also need to copy log4j-<version>.jar and commons-logging-<version>.jar files from the gridsphere/lib directory to TOMCAT_HOME/commons/lib directory.
If you want a pristine copy of GridSphere 3.0.5 you can download it from http://www.gridsphere.org/download/pub/gridsphere/gridsphere-3.0.5-src.tgz .
Here is a link to a Wiki with a link to a MAMS test installation of Shibbolized Gridsphere 3.0.5. It includes a link for creating a test user account to use. http://www.nabble.com/shibbolized-GridSphere-3.0.5-td10193024.html Be sure to change dspace3 to dspace1 - he moved the testbed after posting to the Wiki.
Build Shibbolized GridSphere Project in Eclipse
See the Integrating GridSphere with Eclipse section on the EclipseConfig page for instructions on building a GridSphere project in Eclipse. Build your Shibbolized GridSphere as a project in Eclipse just as you did the original GridSphere. If this new project has a different name from your original GridSphere project, the two can coexist in Eclipse. However, you must remove all references to gridsphere in CATALINA_HOME and CATALINA_BASE before creating the Shibbolized GridSphere project.
If you would like to use Hsqldb Database Manager to view or modify the data in the database, see DatabaseClientConfig.
Configuring Tomcat Authentication
In order to test gridsphere without needing Shibboleth installed, you can have the tomcat container handle authentication. Documentation to follow. Here's a link to OngoingNotes about topics in progress.
One of the key bits to make this work is that you have to remove gridsphere's handling of the 401 error condition from the web.xml file, otherwise your basicauth behavior will look like a blank page rather then being prompted for authentication credentials. What happens is that gridsphere's web.xml describes a page to load for the 401 error handling, that page is missing by default so a 404 (page not found) error happens. That jsp is missing too, so an empty documented is returned to the browser. If you look at the HTTP exchange with LiveHTTPHeaders, you'll see the response indicates that the "unauthorized.jsp" file was missing (the result of the 401 error handling definition pointing to a missing jsp). Simply commenting out the 401 error handling description in web.xml bumps the condition up the the tomcat container which then correctly handles the HTTP auth exchange. The url to protect in web.xml is /gridsphere/login/shib_login. That will cause the Tomcat basic authentication login box to pop up when the GridSphere button for Shibboleth authentication is clicked.
Here's a sample of code added to a web.xml file to protect the /gridsphere/login/shib_login. Only Tomcat users who are members of the tomcat group would be able to authenticate successfully.
<security-constraint>
<web-resource-collection>
<web-resource-name>
gridsphere
</web-resource-name>
<!-- This would protect /gridsphere/login/shib_login -->
<url-pattern> /gridsphere/login/shib_login </url-pattern>
<!-- If you list http methods,
only those methods are protected -->
<http-method> DELETE </http-method>
<http-method> GET </http-method>
<http-method> POST </http-method>
<http-method> PUT </http-method>
</web-resource-collection>
<auth-constraint>
<!-- Roles that have access -->
<role-name> tomcat </role-name>
</auth-constraint>
</security-constraint>
<!-- BASIC authentication -->
<login-config>
<auth-method> BASIC </auth-method>
<realm-name> Gridsphere Basic Authentication </realm-name>
</login-config>
<!-- Define security roles -->
<security-role>
<description> tomcat </description>
<role-name> tomcat </role-name>
</security-role>
Useful Link in understanding authentication with Tomcat: http://www.cafesoft.com/products/cams/tomcat-security.html
Modifications to Shibbolized GridSphere itself for Use With Basic Authentication Instead of Shibboleth
- Edit your webapps/gridsphere/jsp/login/LoginFromShibboleth.jsp so that after the username and password is submitted the user will be redirected to http://localhost:8080/gridsphere/gridsphere/loggedin/login/r/ just as it would be after a successful login from the regular login portlet.
window.location="http://localhost:8080/gridsphere/gridsphere/loggedin/login/r/";
- Now when a user clicks the 'Login from Shibboleth' button, if they put in a valid Tomcat username/password they will be logged into GridSphere just like with the original login procedure. If a GridSphere user does not already exist, one will be created. Since we will not know a firstname, lastname, or email necessarily, comment out these lines in ShibbolethLoginPortlet.java:
if ((firstname == null) || firstname.equals(""))
throw new IllegalArgumentException("Please provide a First Name!");
if ((lastname == null) || lastname.equals(""))
throw new IllegalArgumentException("Please provide a Last Name!");
if ((email == null) || email.equals(""))
throw new IllegalArgumentException("Please provide an Email Address!");
if (!email.contains("@") || (!email.contains(".")))
throw new IllegalArgumentException("Please provide a valid Email Address!");
Also comment this line out of ShibbolethLoginPortlet.java:
username = email;
- Likewise, since after login the Welcome page usually says, "Welcome, <FIRSTNAME> <LASTNAME>", we need to modify returnnav.jsp. The line where the string username is assigned to Firstname + Lastname needs to be changed to
String username = user.getUserID(); %>
Now the welcome will be, "Welcome, <USERID>".
- If we leave the rest of ShibbolethLoginPortlet.java as it is, then every time a user logs into GridSphere through the Login from Shibboleth button, its firstname, lastname, and email address will be set to null. That's because we are not picking up Shibboleth attributes the way the portlet is intended to do. So we need to move one bracket.
try
{
System.out.println("\r\nStarting a database transaction");
User accountRequest = userManagerService.getUserByUserName(username);
if(accountRequest == null)
{
accountRequest = userManagerService.createUser();
accountRequest.setUserName(username);
accountRequest.setEmailAddress(email);
// This is original location of bracket. }
accountRequest.setFirstName(firstname);
accountRequest.setLastName(lastname);
accountRequest.setFullName(lastname + ", " + firstname);
accountRequest.setOrganization(org);
} // Put bracket here instead.
PasswordEditor editor = passwordManagerService.editPassword(accountRequest);
editor.setValue(passwd);
Configuring Logging for GridSphere
When starting tomcat from within Eclipse, error messages may appear such as
log4j:ERROR Could not find value for key log4j.appender.A1 log4j:ERROR Could not instantiate appender named "A1". log4j:WARN No appenders could be found for logger (org.apache.catalina.core.AprLifecycleListener). log4j:WARN Please initialize the log4j system properly.
If that is the case, go to $HOME/apache-tomcat-5.5.25/common/classes/ and edit log4j.properties. Here is an example log4j.properties file. The below log4j.properties produces no errors when Tomcat starts and collects DEBUG and INFO logging information in the console of Eclipse. If the line "log4j.rootCategory=INFO, A1" is changed so that instead of "INFO" you have "DEBUG", you will get much more information in the console. Since GridSphere information is what is of interest to us right now, I changed the root logger level to "INFO" and left the GridSphere and Hibernate logging levels at "DEBUG". Please see this reference for more discussion about Log4j and logging levels: http://logging.apache.org/log4j/1.2/manual.html
log4j.debug=TRUE # To turn more verbose logging on - change "WARN" to "DEBUG" log4j.rootCategory=INFO, A1 # View logs with Chainsaw # Append in rootCategory CHAINSAW_CLIENT and start Chainsaw (standalone or IDE integrated) #log4j.appender.CHAINSAW_CLIENT=org.apache.log4j.net.SocketAppender #log4j.appender.CHAINSAW_CLIENT.RemoteHost=localhost #log4j.appender.CHAINSAW_CLIENT.Port=4445 #log4j.appender.CHAINSAW_CLIENT.LocationInfo=true # A1 is set to be a ConsoleAppender. log4j.appender.A1=org.apache.log4j.ConsoleAppender # A1 uses PatternLayout. log4j.appender.A1.layout=org.apache.log4j.PatternLayout log4j.appender.A1.layout.ConversionPattern=%-4r [%t] (%F:%L) %-5p %c %x - %m%n log4j.appender.console=org.apache.log4j.ConsoleAppender log4j.appender.console.layout=org.apache.log4j.PatternLayout log4j.appender.console.Threshold=DEBUG log4j.appender.console.layout.ConversionPattern=%r:%p:(%F:%M:%L)%n< %m >%n%n log4j.appender.logfile=org.apache.log4j.RollingFileAppender log4j.appender.logfile.layout=org.apache.log4j.PatternLayout log4j.appender.logfile.File=gridsphere.log log4j.appender.logfile.MaxFileSize=40480KB log4j.appender.logfile.MaxBackupIndex=5 log4j.appender.logfile.layout.ConversionPattern=%r:%p:(%F:%M:%L)%n< %m >%n%n # Log all of GS log4j.logger.org.gridsphere=DEBUG # Log GS rendering code #log4j.logger.org.gridsphere.layout=DEBUG # Log GS portlet container and portlet code #log4j.logger.org.gridsphere.portletcontainer=DEBUG # Log portlet services #log4j.logger.org.gridsphere.services=DEBUG # Log GS portlet provider model #log4j.logger.org.gridsphere.provider=DEBUG # HSQLDB logging log4j.logger.org.hsqldb=DEBUG # Log Hibernate and DB access log4j.logger.org.hibernate=DEBUG log4j.logger.org.hibernate.cfg.Binder=DEBUG log4j.logger.org.hibernate.cfg.Environment=DEBUG log4j.logger.org.hibernate.util.DTDEntityResolver=DEBUG
