The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Solaris Installation

Building Shibboleth from source is recommended for production deployments on Solaris systems, but binary Solaris packages are available for some version/architecture combinations:

  • Solaris 8 (sparc)
  • Solaris 10 (i386)

The reason we suggest using a source build is because Solaris environments tend to be very localized and use versions of various packages (such as OpenSSL) that may or may not be up to date. There are few hard and fast guidelines, and you should avoid using Solaris if you aren't familiar with the specifics of your environment.

A note about 64-bit Solaris: while Shibboleth now supports 64-bit builds, Solaris quite logically limits the use of 64-bit code to applications where it provides clear benefits. Apache and Shibboleth are not such a case. The Apache software provided by Sun on new Solaris versions is 32-bit and requires that Shibboleth be 32-bit as well. As a result, the packages provided for Solaris 10 are 32-bit and should work on either 32-or 64-bit Solaris 10.

Build from Source
Install from Packages

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":

  1. Protect a directory by requiring a Shibboleth session. Usually, this is already done by default for the location "/secure".

  2. 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.

  3. 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.
  • No labels