NativeSPMacInstall

Mac OS X Installation

The recommended strategy for Mac OS X is now the MacPorts system. MacPorts is a software package similar to the BSD ports facility that uses descriptors called Portfiles to download and install open source packages.

Shibboleth 2.x and its dependencies have a set of Portfiles that enable a fairly simple installation or upgrade of the entire stack on OS X 10.4+. Other versions may also work (and we can make adjustments to the Portfiles if needed).

Of course, building Shibboleth from source is also possible.

Install using MacPorts
Build from Source

At this time, there are no plans to supply official binaries directly. However, an unofficial set has been created by Alan Brenner and is located at http://tid.ithaka.org/software/shibboleth-for-os-x. No official support or documentation is provided, and they may lag or be out of date if security fixes are necessary, so use them at your own risk.

Leopard, Apache, and Intel Macs

On 64-bit Intel machines, the Apache version provided by Apple is a universal binary that includes both 64-bit and 32-bit architecture support. As a result, the default arch used will be x86_64. On OS X versions prior to 10.6 (Snow Leopard), the primary build instructions and portfiles provided for Shibboleth build 32-bit libraries, which cannot be used with a 64-bit Apache process.

There are instructions for building for 64-bit Intel under 10.5, but those instructions are a bit rough. The 64-bit version works with Apple's 64-bit Apache.

To run Apache as a 32-bit process, refer to the these instructions.

As of Snow Leopard, Apple has defaulted builds to 64-bit, so these problems should be gone.

An additional point is that in at least some cases, possibly confined to the server version of OS X, Apple supplies a configuration in which MinSpareServers and MaxSpareServers are both set to "1". This isn't a very typical setup for preforking Apache, particular the maximum. The result of this setup is that the Apache process will frequently spawn and reap its children, which is somewhat heavyweight when the SP is used. Normally a higher maximum, often 5-10, is more efficient.

Initial Testing

You can test to ensure that the SP is running properly and the surrounding environment is correct by accessing https://localhost/Shibboleth.sso/Status from the actual web server machine. You MUST use "localhost" as the hostname or it WILL NOT WORK by default. If this test is successful, then the software is ready for further configuration.

You can also access the Status handler from other clients or using a non-localhost name, but only if you change the acl parameter in the configuration to permit your client address or remove it entirely to open up access to anybody. The ACL is present by default because the Status handler can return some arguably sensitive information about your configuration.

Now you can progress to the Getting Started material, or if you're in the very early stages of evaluation, try a more controlled scenario by using the TestShib IdP. (Note that before using the TestShib IdP, you'll need to complete the first step from Getting Started, setting the entityID attribute in the ApplicationDefaults element of shibboleth2.xml.)

Once you've actually configured the SP with its own settings and metadata from at least one IdP, in order to check that the SP is "working":

Protect a directory by requiring a Shibboleth session. Usually, this is already done by default for the location "/secure".
Next, you typically place a script inside the protected directory that dumps the web server environment. With PHP for example you could in the easiest case just place a script there with the following:
```
<?php print_r($_SERVER) ?>
```
A more advanced version of such a script can be found here.
Make sure that the Shibboleth-supplied variables are present. If there is a non-empty variable called Shib-Application-ID, you successfully authenticated and have a valid session. However, you also should check if there are other non-empty Shibboleth variables defined in the attribute-map.xml file. If there are no variables like mail or givenName or surname, the IdP either releaseed no attributes, or the attribute request failed (the latter usually only applies when using an older IdP). In this case, have a look at the shibd.log file.