Gary already has an example of custom Grouper UI authentication, the Yale CAS auth. I configured the grouper UI to work with Penn's single signon , and I thought another example committed to grouper UI cvs would be useful for people (not because you would use Penn's SSO, but because you might integrate with the UI similarly). Here are the steps I used to get it to work:
1. Add a new eclipse project (mine is in the same as UI in contrib, but you will probably keep in your local source control), this will depend on the grouper-ui project. Here is what my dir looks like
2. There is a build.xml which will be linked from the grouper-ui build.xml. I kept things simple by not having any build config params, you might have a build.properties...
3. You need a custom web.something.xml which will merge into the web.core.xml. In my case, it is web.penn.xml, and it again is simplified, I just protect all .do resources (even public ones, Im ok having everything protected I think), but the URL we publish will probably be a protected page (e.g. grouper/home.do), and not the public one (grouper/).
4. That filter we added to the web.xml will do two things, first it will redirect the user to our single signon login screen if there is no detected user. Second, it wraps the HttpSevletRequest object so that any calls to getRemoteUser() (which is what grouper-ui uses to get the logged in user) will get the user from the token passed in from single signon.
5. The request wrapper caches the user identity, but makes sure the token from single signon doesnt change (e.g. if a user logs in after another user didnt log off). If there is a mismatch, it kills the session and cookies which should allow the user to login again. If the identity is in session cache, use it (since it is expensive to decode a token). If not, then decode the token (if there wasnt a token, the user will be redirected to the login page by the filter above). To decode the token, we use our jar which calls a command line program which has the security associated with it. Then cache the result.
6. If you dont have an additional-build.xml file for grouper-ui (used to link additional build steps without editing the build.xml directly), then you can copy and example, and rename to additional-build.xml. Edit the contents to point to your build.xml for your auth mechanism (e.g. build.xml above). Note this build file must have a webapp and resources target.
7. In your build.properties for grouper-ui, specify where this additional-build.xml is, e.g.
#add an additonal build file to incorporate site specific changes additional.build=additional-build.xml
8. For configuration settings, you can either use params in the web.xml (like Gary's example), or a config file (I used media.properties since I dont expect to have to change my settings, but if so I want a way without compiling). Note that my use of media.properties happens before the local.media.properties is considered since the user isnt logged yet, so again, it might not be a good example, up to you. You can look in the request wrapper for my example.
9. Remove the simple auth in the web.core.xml
<security-constraint>
<web-resource-collection>
<web-resource-name>Tomcat login</web-resource-name>
<url-pattern>/login.do</url-pattern>
</web-resource-collection>
<auth-constraint>
<!-- NOTE: This role is not present in the default users file -->
<role-name>grouper_user</role-name>
</auth-constraint>
</security-constraint>
<!-- Define the Login Configuration for this Application -->
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>Grouper Application</realm-name>
</login-config>
<!-- Security roles referenced by this web application -->
<security-role>
<description>
The role that is required to log in to the Manager Application
</description>
<role-name>grouper_user</role-name>
</security-role>