Skip to content

Cloud Strategy & Architecture Posts

MySQL Replication

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 closed

Shibboleth IdP Load Balancing

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 closed

Emergency Site Setup Notes

The University Communications group requested an off-site web server for publishing updates during a disaster. Bruce negotiated with colleagues at Duke to get a server there; Stanford will return the favor by hosting a server for Duke. We set up a site for an emergency drill, and made some changes based on that experience.

Comments closed

Connecting WordPress and WebDAV

We've been working on setting up a WordPress blog on a server at Duke to host Stanford's emergency pages. A blog like WordPress makes it easy for staff to update the news site during an emergency. WordPress, like most blog packages, uses its own user database; normally this is a pain to deal with in a single-sign on environment, but it's a handy feature in an emergency system. The Satellite Operations Center also need a place to keep various documents, but a blog is not the best approach. While it's easy enough to add WebDAV support to the server, that would normally mean a separate user database, using either htpasswd or htdigest files. Or, you can use the mod_auth_mysql Apache module and the WordPress database for authentication and authorization.

Comments closed