This describes the test enviroment for the development and prototyping on the project.
Test Machine Overview
This section describes the servers running our test environment, and how to access test pages for the packages we are testing.
WebAuth
The machine foonalagoona.mit.edu hosts the test central login server. For the Webauth package, it runs the WebKDC software.
posteverything.mit.edu (running Apache 2.0) has the Webauth application server test software, available at:
https://posteverything.mit.edu/tests/
This setup currently uses certificates signed by my own test CA, not MIT certificates, so you will get warnings about this if you attempt to visit this site, as well as when you are redirected to the login server.
When you select a test, and you have not yet logged in to the system, you will be redirected to the login server (at foonalagoona). Here you will see a login page displayed, from which you can authenticate either using your Kerberos username and password, or using existing Kerberos tickets (via HTTP/SPNEGO, if you have configured your browser appropriately) or certificates (currently requires a user certificate signed by my test CA, not an MIT cert). When you have authenticated successfully, a confirmation is displayed, with a link to redirect you back to the application server. Once you have logged in, subsequent attempts to access the application server site should take you directly to the confirmation page.
If you authenticate using your existing Kerberos tickets, or certificates, the confirmation page will offer an option to always try that authentication method in the future, instead of displaying the login page.
Another test application server is at:
https://pinkflag.mit.edu/tests/
This server is running Apache 1.3, so is useful for testing the Webauth module ported locally to 1.3.
Shibboleth
foonalagoona.mit.edu runs the Shibboleth IdP. This software is a Java servlet, running under Tomcat 5.5, and Apache 2.0, with the mod_jk connector. Currently the IdP SSO handler is protected by Webauth, so you will be redirected to the test Webauth login page for authentication.
posteverything.mit.edu runs the Shibboleth SP software; this is a C++ Apache module, and the shibd daemon.
These two servers are configured as a "bilateral deployment", i.e. where each server has explicit configuration to talk to the other.
A simple test of Shibboleth-protected content is available at:
https://posteverything.mit.edu/shib-testenv
This will simply dump out the environment, including the HTTP_SHIB_* variables.
Note that when you authenticate on our test Webauth login page, the confirmation page currently links back to foonalagoona, since the authentication was invoked from the IdP there; the IdP will then redirect you back to the original server, posteverything. If you have Javascript enabled in your browser, the latter redirection happens automatically.
As in the Webauth test, this setup currently uses certificates signed by my own test CA, not MIT (or self-signed) certificates, so you will get warnings about this when you visit this site.
Other tests, can be found at http://posteverything.mit.edu/test.html. Note that this a developers test environment and does not use the pilot or produciton IdPs and it may not always be running.
A test application has also been created for the current pilot system and it will be in place when the project reaches its fully operational phase. This test application may be used by the Help Desk and other people to determine if the system is running correctly at any given point in time. It can be found at:
http://touchstone-tester.mit.edu/
Server Configuration
This describes the server configuration performed for the test environment login and application servers, not including building and installing the relevant packages' software.
WebAuth
WebKDC
To configure the webkdc (login server):
(See doc/install-webkdc in the webauth source tree for more information).
In $APACHE_ROOT/conf/httpd.conf, add the following Apache directives:
LoadModule webkdc_module modules/mod_webkdc.so WebKdcServiceTokenLifetime 30d WebKdcKeyring conf/webkdc/keyring WebKdcKeytab conf/webkdc/keytab WebKdcTokenAcl conf/webkdc/token.acl # enable debugging for now... WebKdcDebug on
For our test setup, I requested a "daemon" service ticket for foonalagoona, and installed this in conf/webkdc/keytab; note that this must match the WebAuthWebKdcPrincipal setting in the configuration of Webauth application servers. The keytab should be owned by the Apache user.
In conf.d/ssl.conf, add the following (inside a VirtualHost block that requires SSL to ensure that they are only accessible over SSL):
ScriptAlias /login "webkdc/login.fcgi"
ScriptAlias /login-spnego "webkdc/login.fcgi"
ScriptAlias /login-cert "webkdc/login.fcgi"
ScriptAlias /login-simple "webkdc/login.fcgi"
ScriptAlias /logout "webkdc/logout.fcgi"
Alias /images "webkdc/generic/images/"
Alias /help.html "webkdc/generic/help.html"
<Location /webkdc-service>
SetHandler webkdc
</Location>
<Location "/login-spnego">
AuthType Kerberos
AuthName "Kerberos Login"
Require valid-user
KrbMethodNegotiate on
KrbMethodK5Passwd off
KrbMethodK4Passwd off
Krb5Keytab /etc/httpd/keytab
ErrorDocument 401 /login-simple
</Location>
# Test webauth cert auth
<Location "/login-cert">
SSLVerifyClient require
SSLVerifyDepth 1
SSLUserName SSL_CLIENT_S_DN_Email
ErrorDocument 401 /login-simple
</Location>
The "/login-spnego" and "/login-cert" locations are for supporting REMOTE_USER as set by Apache authentication modules, if present; see doc/install-spnego in the source tree for more information.
SPNEGO is handled by mod_auth_kerb on foonalagoona. Note that its "KrbSaveCredentials on" directive seems to cause the CGI process to segv under Apache 2.0. I debugged this, and came up with the following patch to fix the problem (I have submitted this upstream):
--- mod_auth_kerb.c.orig 2006-02-28 18:01:44.000000000 -0500 +++ mod_auth_kerb.c 2006-11-22 12:12:38.000000000 -0500 @@ -66,7 +66,7 @@ #include <apr_strings.h> #include <apr_base64.h> -#define ap_null_cleanup NULL +#define ap_null_cleanup apr_pool_cleanup_null #define ap_register_cleanup apr_pool_cleanup_register #define ap_pstrdup apr_pstrdup
Note that conf/webkdc/token.acl must be set up, to allow any application servers to talk to the webkdc:
# token.acl -- ACL file for the WebKDC. # This lets anyone with a krb5 webauth/*@ATHENA.MIT.EDU # principal to get an id token (perform basic authentication). # See the mod_webkdc manual for more information. #krb5:webauth/*@ATHENA.MIT.EDU id krb5:daemon/posteverything.mit.edu@ATHENA.MIT.EDU id krb5:daemon/pinkflag.mit.edu@ATHENA.MIT.EDU id
Access to proxied credentials is also controlled here; for example, to allow posteverything to get a ticket for the LDAP server, add an entry like:
krb5:daemon/posteverything.mit.edu@ATHENA.MIT.EDU cred krb5 ldap/ldap.mit.edu@ATHENA.MIT.EDU
The first field here (the service principal of the application web server) can be wildcarded, as with the "id" acl, but not the "cred" (principal for the desired credential) field. Only krb5 credentials are supported.
WebAuth Application Server
Add the following to $APACHE_ROOT/conf/httpd.conf (see INSTALL in the WebAuth source tree, and the mod_webauth manual, for more information):
# For webauth (see INSTALL in webauth source tree) LoadModule webauth_module modules/mod_webauth.so WebAuthKeyringAutoUpdate on WebAuthKeyringKeyLifetime 30d WebAuthLoginURL "https://foonalagoona.mit.edu/login/" WebAuthWebKdcURL "https://foonalagoona.mit.edu/webkdc-service/" WebAuthWebKdcPrincipal daemon/foonalagoona.mit.edu WebAuthKeyring conf/webauth/keyring WebAuthKeytab conf/webauth/keytab WebAuthServiceTokenCache conf/webauth/service_token.cache WebAuthSSLRedirect on# This file holds the cert(s) needed to verify the WebKDC's cert. WebAuthWebKdcSSLCertFile conf/ssl.crt/my-ca.crt # XXX for testing... WebAuthDebug on # for test suite... Include conf/webauth-tests.conf # for proxied credential tests... WebAuthCredCacheDir conf/webauth/credcache # Debug... <Location /webauth-status> SetHandler webauth Order allow,deny Allow from all </Location>
(When building/installing, you must do "make install-tests" to install the test suite.)
Install a keytab in conf/webauth/keytab. For the test setup, I requested a daemon service key (for production, we probably want to create "webauth" keys, or some other distinctive principal). The webauth directory, and the keytab, should be owned by the apache user.
For the test setup, I created a certificate signed by my own test CA. The server and CA certificates should be installed in conf/ssl.crt, and the key in conf/ssl.key/. These should be set in the SSL configuration (ssl.conf in Apache 2.0); for example, on the server posteverything:
SSLCertificateFile /etc/httpd/conf/ssl.crt/posteverything-server.crt SSLCertificateKeyFile /etc/httpd/conf/ssl.key/posteverything-server.key SSLCertificateChainFile /etc/httpd/conf/ssl.crt/my-ca.crt
Shibboleth
IdP
See https://authdev.it.ohio-state.edu/twiki/bin/view/Shibboleth/JKIdPInstall for information on installing the IdP.
For testing, foonalagoona (IdP) and posteverything (SP) are configured as a "bilateral deployment", as described on the Shibboleth wiki, except they use server certificates signed by my test CA instead of self-signed certs.
Initial testing failed mysteriously, resulting in a 404 error (application unavailable) from Tomcat for the IdP SSO handler, though the logs all indicated that the IdP web application was getting initialized correctly. I followed instructions for getting better logging output (requires installing log4j, etc.), but this did not uncover the problem. Finally, careful investigation revealed the problem -- a trailing / in the wayfURL value in the SP's shibboleth.xml (as copied from the Location setting in the SingleSignOnService element in the partner metadata).
The IdP configuration (idp.xml) is here. The partner metadata file is here.
I enabled the eduPersonScopedAffiliation and eduPersonPrincipalName attributes in resolver.xml, and added eduPersonPrincipalName to arp.site.xml. This enables setting REMOTE_USER to the authenticated user name in the SP application. To test getting attributes from the MIT LDAP server, I configured resolver.ldap.xml to do an anonymous bind to the server, and, initially, mapped the eduPersonPrincipalName attribute to the "mail" LDAP attribute, as eduPersonPrincipalName was not part of the schema on ldap.mit.edu at the time; to use this configuration, I changed the resolverConfig setting in idp.xml accordingly. Note that I was unable to bind successfully using GSSAPI in brief testing; the error "No valid credentials provided" was logged in shib-error.log, even when I tried initializing a proper ticket cache before starting tomcat. (The GSSAPI bind had worked in testing WebAuth's mod_webauthldap module).
After the ldap.mit.edu schema was updated to populate additional eduPerson attribute values, I added these and some other common LDAP attributes to arp.site.xml , and reverted the mapping of eduPersonPrincipalName to "mail" in resolver.ldap.xml.
SP
See https://authdev.it.ohio-state.edu/twiki/bin/view/Shibboleth/SPLinuxInstall for information on installing the SP on Linux. For posteverything, I downloaded and installed all of the RPMs from:
http://shibboleth.internet2.edu/downloads/RPMS/i386/RHE/4.3/
The RPM installs a proper shib.conf in $APACHE_ROOT/conf.d. The Shibboleth configuration files are in /etc/shibboleth.
For the shib-testenv page noted above (a CGI script which simply dumps out the environment), I added the following to shib.conf:
ScriptAlias /shib-testenv "/var/www/cgi-bin/testenv.cgi" <Location /shib-testenv> AuthType shibboleth ShibRequireSession On ShibRedirectToSSL 443 require valid-user </Location>
For testing, foonalagoona (IdP) and posteverything (SP) are configured as a "bilateral deployment"; I started with the instructions at:
https://authdev.it.ohio-state.edu/twiki/bin/view/Shibboleth/BilateralDeployment
but changed things to use the server certificates signed by my test CA, instead of using self-signed certs.
The partner metadata file is here. Besides the host/domain names, the significant difference between this and the file resulting from following the wiki instructions is that the test CA certificate is embedded, instead of the IdP cert itself.
The shibboleth.xml file is here.
I modified the distributed AAP.xml to add a Header value for eduPersonNickname, and uncommented the sections defining the eduPerson and common LDAP attributes.
To test against a second IdP (e.g. ProtectNetwork), add a SessionInitiator element for it in shibboleth.xml and add a ShibRequireSessionWith directive to the appropriate Location block in the Apache configuration, e.g.:
ShibRequireSessionWith ProtectNetwork