Skip to content

Category: Shibboleth

Slacking with Shibboleth

Someone asked how to get Slack SAML SSO working with a Shibboleth IdP. It's pretty straightforward, despite the lack of SP metadata from Slack and the inability of Slack to import IdP metadata.

Slack will attempt an authentication when you save its SAML configuration, so you need to set up the IdP first.

Comments closed

Authentication and Authorization with Shibboleth and LDAP

Previously, I tried setting up a more efficient Shibboleth Attribute Authority - one where I could query for a specific attribute value for a specific attribute for a specific user (e.g. does jane@itlab.stanford.edu have an experimentId attribute with the value 2?). While you can add attribute values to the attribute elements in a SimpleAggregation AttributeResolver query, the IdP rejects the query.

Another Shib-based option would be to develop a plugin that can create attributes from server environment variables (like REMOTE_URI). One could then use the Template and Tranform Attribute Resolvers to create a new NameID attribute for the SimpleAggregation query (something like eppn:https://SERVER_NAME/REMOTE_URI). Then an Attribute Authority could be configured to split the NameID into multiple attributes and use those for a SQL query or LDAP lookup.

That seemed like a bunch of work, so instead I took a look at using Apache’s mod_authnz_ldap on the SP instead. In this scenario, when an unauthenticated user attempts to access a set of experiment results, they are first sent to an IdP (via the embedded discovery service) to authenticate, then mod_authnz_ldap queries a remote LDAP server for attributes (group membership seems to be the easiest model) and determines whether the user has access.

Comments closed

Configuring an SP with Multiple ProviderIDs

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 closed

Configuring a Shibboleth Service Provider

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 closed

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