MacInstall

The quasi-supported Mac installation mechanism is 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, either from pre-built cached binaries or from source.

Shibboleth and its dependencies have a set of official Portfiles that enable a fairly simple installation or upgrade of the entire stack on macOS. However, they don't always work because macOS changes frequently these days and the toolchain used is difficult to debug.

Of course, building Shibboleth from source is also possible (and tends to be more reliable).

Install using MacPorts
Build from Source

Upgrades

Upgrading to new releases is handled automatically when the port is used, or in the case of a source build when "make install" is run using the same installation prefix. The system prevents configuration files from being overwritten and skips "initial install" tasks like generating keys. Restart of the relevant services has to be done manually.

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 itself. 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 GettingStarted material. 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. Often, 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) ?>
```
For an IIS deployment, an example ASP.NET script:
```
<% @ Page Language="C#" %>
<%
Response.Write("<h3>Server Variables</h3>");
foreach (string var in Request.ServerVariables)
{
	Response.Write(var + " = " + Request[var] + "<br>");
}
%>
```
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 probably releaseed no attributes. In either case, have a look at the shibd.log and transaction.log files.