Comments Off Several people have asked for the slides (PDF, 5MB) from my COmanage session at the last I2 member meeting. They’re not slidumentation or docu-point, so I’m not sure how useful they’ll really be to others. Contact me if you want the original Keynote slides.
Comments Off We often run multiple applications on a single server; if the apps all need the same set of attributes they can be treated as a single Service Provider (SP). Sometimes the applications need to be separated, and the obvious, easy way to do this, other than running them on separate servers, or to add a separate IP address, SSL certificate and Apache virtual host for each application. However, a Shibboleth SP can be configured with multiple providerIds, using a single certificate.
Comments Off OCLC, like many other providers, use IP subnets for access control – e.g. anyone accessing OCLC from an address in the 171.64.x.y range is considered a Stanford user. Off-campus Stanford users currently access OCLC via an EzProxy server on campus. Users authenticate (using WebAuth) to the EzProxy server, then all traffic between the user’s browser and OCLC passes through the proxy server.
Shibboleth provides a more efficient model: the user clicks on a link to OCLC, just like they do with the current setup, but their browser connects directly to the OCLC server. The user is then presented with a list of institutions, from which they would select Stanford University; their browser would then be redirected to WebAuth where the user would log in; finally the browser is directed back to the OCLC server. From this point on, traffic travels directly between the user’s browser and the OCLC servers.
Try it with this link to OCLC.
Comments Off After you’ve installed the Shibboleth Service Provider (SP) Apache module and daemon, and joined one or more federations, you’ll need to edit /etc/shibboleth/shibboleth.xml. The federation will normally give you configuration instructions, but a basic configuration is available from
shibboleth.xml. The file has entries for Stanford’s test federation (DevFed), Internet2’s test federation (InQueue) and Internet2’s production federation (InCommon).
Comments Off Neither Stanford nor Yahoo! were ready to use Shibboleth when the interface to Yahoo! music was set up in late summer 2005. However, we wanted to migrate to Shibboleth at a later date, so we used Yahoo!’s Campaign Codes as targeted IDs – once we verified that a person was eligible for the music server we redirected them to a Yahoo! registration site with their existing campaign code, or a new one that was allocated if they had not tried the service previously.
This led to the development of a targeted ID database for our IdPs that could continue the mapping of the codes from Yahoo! to users, along with generic targeted IDs constructed from the user’s principal, the remote service’s providerId and a salt value. The database was built with MySQL5 using a few tables and some stored procedures. Initially we were testing with single Shibboleth IdP servers, so the database ran on the same system: the central MySQL servers were still running MySQL v4.x, so had no support for stored procedures.
After load balancing the IdP service over a pair of servers, the database also needed some improvement to handle the failure of a single IdP.
Comments Off Our test IdP is now a pair of load balanced servers (actually, they’re currently two virtual machines on the same physical server, but this is for testing). idp-dev1 and idp-dev2 are running the lbcd service to enable lbnamed failover; the servers are balanced as idp-dev.stanford.edu, which is currently listed in the InQueue and DevFed (our little test federation) metadata.
The load balancing works for Shibboleth’s Browser/POST profile, where a Shibboleth handle is passed from the IdP via a browser redirect to the SP; the SP then queries the IdP using that handle. In the basic configuration, each IdP uses an in-memory map of handles to principals. Since all the IdPs in a load balanced pool need access to the same mapping, there’s a CryptoShibHandle class that creates a handle by encrypting the principal with a key shared by all the IdPs.
Comments Off I’ve “hacked” Shibboleth authentication for administrators and posters, and built a Shibboleth-backed TypeKey for comment authentication. Details on the Shibbolized MT site itself. It’s really more of a REMOTE_USER hack, so it should work with any other authentication system that can populate the REMOTE_USER environment variable.
IT Lab
