URL: http://www.switch.ch/aai/docs/shibboleth/SWITCH/1.3/sp/install-sp-1.3-osx.html Author: Valery Tschopp - SWITCH Author: Lukas Haemmerle - SWITCH $Date: 2008/01/15 14:53:59 $ $Revision: 1.31 $
This guide describes an OS X specific installation of a Shibboleth Service Provider 1.3.1 and its configuration for the SWITCHaai Federation. It covers installation on a Mac OS X 10.4 (Tiger) PowerPC or Intel with the default OS X Apache 1.3 webserver, but the precompiled binaries contain module for Apache 2.2 too.
More extensive information can be found in the Shibboleth Service Provider Deployment Guide from Internet2. It is recommended to familiarize yourself with the Internet2 guide.
Note: If you want to join the AAI-Test Federation instead of the production SWITCHaai Federation, please consult the AAI-Test Reconfiguration Guide after following the instructions on this page.
Note: For a general description of the deployment of Shibboleth within the SWITCHaai Federation, please consult the Deployment section of the SWITCHaai website (http://www.switch.ch/aai/).
The Shibboleth Service Provider (SP) 1.3 is implemented in C/C++ as an Apache authentification module mod_shib and a separate daemon shibd.
As indicated in the title, this guide applies to OS X 10.4 (Tiger) and contains some references to OS X specific tools.
We provide a precompiled version of the Shibboleth Service Provider 1.3 for Mac OS X 10.4 (Universal binary for PowerPC and Intel).
This version was compiled (Universal binary) on a Mac OS X 10.4 computer with the default gcc 4.0 compiler. The default OpenSSL and curl system libraries of OS X are used. Other libraries required by Shibboleth SP 1.3 are included in the package. The SWITCHaai configuration files are also included in the package.
Latest Shibboleth SP 1.3.1 for Mac OS X 10.4 precompiled binaries:
The Shibboleth SP 1.3 must be installed under: /usr/local/shibboleth-1.3
root# curl -L -O http://www.switch.ch/aai/downloads/shibboleth-sp-1.3.1-OSX-10.4.tar.gz ... root# cd /usr/local root# tar xvzf shibboleth-sp-1.3.1-OSX-10.4.tar.gzThe tar file will be decompressed in a shibboleth-1.3 directory.
This section briefly mentions the needed steps to get a server certificate. For a full documentation how to get SWITCHpki certificates, see http://www.switch.ch/aai/certificates/get-switchpki-certificate.html
Generate an unencrypted 2048-bit RSA key in PEM format:
$ openssl genrsa -out www.example.ch.key 2048
Create a Certificate Signing Request (CSR):
$ openssl req -new -key www.example.ch.key -out www.example.ch.csr
Send the CSR to your certification authority (CA) to be signed.
Get your X.509 server certificate (PEM format) signed with the full chain up to to the root CA certificate and save it under www.example.ch.crt.
Create the /etc/shibboleth configuration directory and copy all SWITCHaai configuration files into it:
root# mkdir /etc/shibboleth
root# cp /usr/local/shibboleth-1.3/etc/shibboleth/* /etc/shibboleth
root# ls -l /etc/shibboleth
-rw-r--r-- 1 root wheel 7091 Jan 14 13:55 AAP.switchaai.xml
-rw-r--r-- 1 root wheel 697 Jan 14 13:55 accessError.html
-rw-r--r-- 1 root wheel 993 Jan 14 13:55 metadata.crt
-rw-r--r-- 1 root wheel 241606 Jan 14 13:55 metadata.switchaai.xml
-rw-r--r-- 1 root wheel 1249 Jan 14 13:55 metadataError.html
-rw-r--r-- 1 root wheel 744 Jan 14 13:55 native.logger
-rw-r--r-- 1 root wheel 805 Jan 14 13:55 rmError.html
-rw-r--r-- 1 root wheel 1279 Jan 14 13:55 sessionError.html
-rw-r--r-- 1 root wheel 513 Jan 14 13:55 shibboleth.logger
-rw-r--r-- 1 root wheel 13079 Jan 14 13:55 shibboleth.xml
-rw-r--r-- 1 root wheel 1260 Jan 14 13:55 shibd.logger
-rwxr-xr-x 1 root wheel 2577 Jan 14 13:55 siterefresh.sh
-rw-r--r-- 1 root wheel 865 Jan 14 13:55 sslError.html
Create the /var/log/shibboleth logging directory and grant write access to the web server group (www):
root# mkdir /var/log/shibboleth root# chown root:www /var/log/shibboleth root# chmod g+w /var/log/shibboleth
Copy the private key and certificate to the /etc/shibboleth directory:
root# cp www.example.ch.key /etc/shibboleth root# cp www.example.ch.crt /etc/shibbolethMake sure the permissions are set correctly. Only the user running Apache (www) must be able to read the private key.
Note: If you already have a valid private key and server certificate that you use for your Apache webserver, you can use it for Shibboleth too.
This is the main configuration file for the Service Provider and is already preconfigured for the SWITCHaai federation.
Edit the /etc/shibboleth/shibboleth.xml file and configure your SP 1.3:
<SPConfig xmlns="urn:mace:shibboleth:target:config:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mace:shibboleth:target:config:1.0 shibboleth-targetconfig-1.0.xsd" clockSkew="180" logger="/etc/shibboleth/shibboleth.logger"> <!-- These extensions are "universal", loaded by all Shibboleth-aware processes. --> <Extensions> <Library path="/usr/local/shibboleth-1.3/libexec/xmlproviders.so" fatal="true"/> </Extensions> <!-- The Global section pertains to shared Shibboleth processes like the shibd daemon. --> <Global logger="/etc/shibboleth/shibd.logger"> <!-- Only one listener can be defined. --> <UnixListener address="/var/run/shibd.sock"/> <!-- <TCPListener address="127.0.0.1" port="12345" acl="127.0.0.1"/> --> <!-- See deploy guide for details, but: cacheTimeout - how long before expired sessions are purged from the cache AATimeout - how long to wait for an AA to respond AAConnectTimeout - how long to wait while connecting to an AA defaultLifetime - if attributes come back without guidance, how long should they last? strictValidity - if we have expired attrs, and can't get new ones, keep using them? propagateErrors - suppress errors while getting attrs or let user see them? retryInterval - if propagateErrors is false and query fails, how long to wait before trying again Only one session cache can be defined. --> <MemorySessionCache cleanupInterval="300" cacheTimeout="3600" AATimeout="30" AAConnectTimeout="15" defaultLifetime="1800" retryInterval="300" strictValidity="false" propagateErrors="false"/> </Global> <!-- The Local section pertains to resource-serving processes (often process pools) like web servers. --> <Local logger="/etc/shibboleth/native.logger" localRelayState="true"> <!-- To customize behavior, map hostnames and path components to applicationId and other settings. The following provider types are available with the delivered code: type="edu.internet2.middleware.shibboleth.sp.provider.NativeRequestMapProvider" - Web-server-specific plugin that allows native commands (like Apache's ShibRequireSession) to override or supplement the XML syntax. The Apache version also supplies an htaccess authz plugin for all content. type="edu.internet2.middleware.shibboleth.sp.provider.XMLRequestMapProvider" - portable plugin that does not support the older Apache-specific commands and works the same on all web platforms, this plugin does NOT support htaccess files for authz unless you also place an <htaccess/> element somewhere in the map By default, the "native" plugin (the first one above) is used, since it matches older behavior on both Apache and IIS. --> <RequestMapProvider type="edu.internet2.middleware.shibboleth.sp.provider.NativeRequestMapProvider"> <RequestMap applicationId="default"> <!-- This requires a session for documents in /secure on the containing host with http and https on the default ports. Note that the name and port in the <Host> elements MUST match Apache's ServerName and Port directives or the IIS Site name in the <ISAPI> element below. --> <Host name="www.example.ch"> <Path name="secure" authType="shibboleth" requireSession="true" exportAssertion="true"> <!-- Example shows a subfolder on the SSL port assigned to a separate <Application> --> <Path name="foo-admin" applicationId="foo-admin"/> </Path> </Host> </RequestMap> </RequestMapProvider> <Implementation> <ISAPI normalizeRequest="true"> <!-- Maps IIS Instance ID values to the host scheme/name/port/sslport. The name is required so that the proper <Host> in the request map above is found without having to cover every possible DNS/IP combination the user might enter. The port and scheme can usually be omitted, so the HTTP request's port and scheme will be used. <Alias> elements can specify alternate permissible client-specified server names. If a client request uses such a name, normalized redirects will use it, but the request map processing is still based on the default name attribute for the site. This reduces duplicate data entry in the request map for every legal hostname a site might permit. In the example below, only sp.example.org needs a <Host> element in the map, but spalias.example.org could be used by a client and those requests will map to sp.example.org for configuration settings. --> <Site id="1" name="www.example.ch"> <!-- <Alias>www-alias.example.ch</Alias> --> </Site> </ISAPI> </Implementation> </Local> <!-- The Applications section is where most of Shibboleth's SAML bits are defined. Resource requests are mapped in the Local section into an applicationId that points into to this section. --> <Applications id="default" providerId="https://www.example.ch/shibboleth" homeURL="https://www.example.ch/" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"> <!-- Controls session lifetimes, address checks, cookie handling, and the protocol handlers. You MUST supply an effectively unique handlerURL value for each of your applications. The value can be a relative path, a URL with no hostname (https:///path) or a full URL. The system can compute a relative value based on the virtual host. Using handlerSSL="true" will force the protocol to be https. You should also add a cookieProps setting of "; secure" in that case. Note that if the value of checkAddress is set to "false", this has a slightly negative impact on the security of the SP. This security feature checks the user's IP address at the SP and compares it with the IP address used at the IdP. If they don't match, an error is thrown. This rather strict security feature can cause problems for users behind proxies or for users with IPv6 addresses. Therefore, this setting is deactivated per default. To compensate the slightly reduced security the consistentAddress feature is activated in the default configuration. The consistentAddress feature is available as of version 1.3c for theelement. It defaults to true when not present and ensures that once a session cookie is issued to a client, any further use of that session cookie must be from a client with the same network address. This raises the bar for session hijackers to the level of network address spoofing, which may or may not be simple to do, but is definitely harder than stealing cookies and relies on a different set of attacking skills. On the other hand the consistentAddress may also cause problems for users whose IP changes during the session (e.g. for AOL users or for users behind proxies which have multiple IP addresses). For additional information about the checkAddress and the consistentAddress setting have a look at https://spaces.internet2.edu/display/SHIB/AddressChecking --> <Sessions lifetime="7200" timeout="3600" checkAddress="false" handlerURL="/Shibboleth.sso" handlerSSL="false" idpHistory="true" idpHistoryDays="7"> <!-- SessionInitiators handle session requests and relay them to a WAYF or directly to an IdP, if possible. Automatic session setup will use the default or first element (or requireSessionWith can specify a specific id to use). Lazy sessions can be started with any initiator by redirecting to it. The only Binding supported is the "urn:mace:shibboleth:sp:1.3:SessionInit" lazy session profile using query string parameters: * target the resource to direct back to later (or homeURL will be used) * acsIndex optional index of an ACS to use on the way back in * providerId optional direct invocation of a specific IdP --> <!-- This default directs users to a specific SWITCHaai WAYF service. --> <SessionInitiator id="SWITCHaai" isDefault="true" Location="/WAYF/SWITCHaai" Binding="urn:mace:shibboleth:sp:1.3:SessionInit" wayfURL="https://wayf.switch.ch/SWITCHaai/WAYF" wayfBinding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"/> <!-- md:AssertionConsumerService elements replace the old shireURL function with an explicit handler for particular profiles, such as SAML 1.1 POST or Artifact. The isDefault and index attributes are used when sessions are initiated to determine how to tell the IdP where and how to return the response. --> <md:AssertionConsumerService Location="/SAML/POST" index="1" isDefault="true" Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"/> <md:AssertionConsumerService Location="/SAML/Artifact" index="2" Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"/> <!-- md:SingleLogoutService elements are mostly a placeholder for 2.0, but a simple cookie-clearing option with a ResponseLocation or a return URL parameter is supported via the "urn:mace:shibboleth:sp:1.3:Logout" Binding value. --> <md:SingleLogoutService Location="/Logout" Binding="urn:mace:shibboleth:sp:1.3:Logout"/> </Sessions> <!-- You should customize these pages! You can add attributes with values that can be plugged into your templates. You can remove the access attribute to cause the module to return a standard 403 Forbidden error code if authorization fails, and then customize that condition using your web server. --> <Errors session="/etc/shibboleth/sessionError.html" metadata="/etc/shibboleth/metadataError.html" rm="/etc/shibboleth/rmError.html" access="/etc/shibboleth/accessError.html" supportContact="YOUR_EMAIL_ADDRESS" logoLocation="YOUR_LOGO_LOCATION" styleSheet="YOUR_STYLESHEET_LOCATION"/> <!-- Indicates what credentials to use when communicating --> <CredentialUse TLS="switchaai" Signing="switchaai"> <!-- RelyingParty elements can customize credentials for specific IdPs/sets. --> <!-- <RelyingParty Name="urn:mace:switch.ch:aaitest" TLS="aaitest" Signing="aaitest"/> --> </CredentialUse> <!-- AAP can be inline or in a separate file --> <AAPProvider type="edu.internet2.middleware.shibboleth.aap.provider.XMLAAP" uri="/etc/shibboleth/AAP.switchaai.xml"/> <!-- Operational config consists of metadata and trust providers. Can be external or inline. --> <!-- SWITCHaai federation metadata (production) --> <MetadataProvider type="edu.internet2.middleware.shibboleth.metadata.provider.XMLMetadata" uri="/etc/shibboleth/metadata.switchaai.xml"/> <!-- The standard trust provider supports SAMLv2 metadata with path validation extensions. --> <TrustProvider type="edu.internet2.middleware.shibboleth.common.provider.ShibbolethTrust"/> <!-- Zero or more SAML Audience condition matches (mainly for Shib 1.1 compatibility). If you get "policy mismatch errors, you probably need to supply metadata about your SP to the IdP if it's running 1.2. Adding an element here is only a partial fix. --> <!-- SWITCHaai federation --> <saml:Audience>urn:mace:switch.ch:SWITCHaai</saml:Audience> <!-- You can customize behavior of specific applications here. The default elements inside the outer <Applications> element generally have to be overridden in an all or nothing fashion. That is, if you supply a <Sessions> or <Errors> override, you MUST include all attributes you want to apply, as they will not be inherited. Similarly, if you specify an element such as <MetadataProvider>, it is not additive with the defaults, but replaces them. Note that each application must have a handlerURL that maps uniquely to it and no other application in the <RequestMap>. Otherwise no sessions will reach the application. If each application lives on its own vhost, then a single handler at "/Shibboleth.sso" is sufficient, since the hostname will distinguish the application. The example below shows a special application that requires use of SSL when establishing sessions, restricts the session cookie to SSL and a specific folder, and inherits most other behavior except that it requests only EPPN from the origin instead of asking for all attributes. Note that it will inherit all of the handler endpoints defined for the default application but will append them to the handlerURL defined here. --> <!-- <Application id="foo-admin"> <Sessions lifetime="7200" timeout="3600" checkAddress="true" handlerURL="/secure/foo-admin/Shibboleth.sso" handlerSSL="true" cookieProps="; path=/secure/foo-admin; secure"/> <saml:AttributeDesignator AttributeName="urn:mace:dir:attribute-def:eduPersonPrincipalName" AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"/> </Application> --> </Applications> <!-- Define all the private keys and certificates here that you reference from <CredentialUse>. --> <CredentialsProvider type="edu.internet2.middleware.shibboleth.common.Credentials"> <Credentials xmlns="urn:mace:shibboleth:credentials:1.0"> <FileResolver Id="switchaai"> <Key> <Path>/etc/shibboleth/www.example.ch.key</Path> </Key> <Certificate> <!-- Certificate and the whole chain --> <Path>/etc/shibboleth/www.example.ch.crt</Path> </Certificate> </FileResolver> </Credentials> </CredentialsProvider> </SPConfig>
Download the last SWITCHaai federation metadata file metadata.switchaai.xml and store it as /etc/shibboleth/metadata.switchaai.xml .
The SWITCHaai federation metadata must be periodically updated to keep your resource up-to-date with the actual state of the federation. See the SWITCHaai Federation Metadata page for more information. Tomcat doesn't have to be restarted when the metadata file changes.
Note: The siterefresh.sh wrapper script for Mac OS X is already included in the /etc/shibboleth directory.
The Shibboleth SP 1.3 daemon shibd must start and run in parallel with Apache. On Mac OS X, daemon processes (Apache, ...) are automatically started with startup items.
Copy the provided OS X startup item /usr/local/shibboleth-1.3/etc/StartupItems/Shibboleth-1.3 in the /Library/StartupItems directory:
root# mkdir /Library/StartupItems
root# cp -r /usr/local/shibboleth-1.3/etc/StartupItems/Shibboleth-1.3 \
/Library/StartupItems
root# ls -l /Library/StartupItems/Shibboleth-1.3
total 16
-rwxr-xr-x 1 root wheel 1567 Jul 27 13:23 Shibboleth-1.3
-rw-r--r-- 1 root wheel 123 Jul 4 10:59 StartupParameters.plist
Content of /Library/StartupItems/Shibboleth-1.3/Shibboleth-1.3 script:
#!/bin/sh # ## # Shibboleth 1.3 Daemon Startup Item (Mac OS X) # # Valery Tschopp- 20050614 ## #set -x . /etc/rc.common # # shibboleth sp 1.3 home and config SHIB_HOME=/usr/local/shibboleth-1.3 SHIB_CONF=/etc/shibboleth/shibboleth.xml # # update system library path DYLD_LIBRARY_PATH=$SHIB_HOME/libexec:$SHIB_HOME/lib DYLD_INSERT_LIBRARIES=$SHIB_HOME/lib/libshib-target.dylib:$SHIB_HOME/lib/libshib.dylib export DYLD_LIBRARY_PATH DYLD_INSERT_LIBRARIES # # the path to your PID file PIDFILE=/var/run/shibboleth.pid StartService () { ## # Start up Shibboleth shibd daemon ## if [ "${WEBSERVER:=-NO-}" = "-YES-" ]; then GetPID "shibboleth" > /dev/null if [ "$?" == "1" ] && [ -x ${SHIB_HOME}/sbin/shibd ] && [ -f "$SHIB_CONF" ]; then echo "Starting Shibboleth 1.3 Daemon" ${SHIB_HOME}/sbin/shibd -fc ${SHIB_CONF} 2> /dev/null & #PID=$! echo -n "$!" > $PIDFILE # tell SystemStart about success ConsoleMessage -s "Shibboleth" else echo "Shibboleth 1.3 Daemon already running" fi else echo "WEBSERVER is not enable in /etc/hostconfig" ConsoleMessage -f "Shibboleth" fi } StopService () { GetPID "shibboleth" > /dev/null if [ "$?" == "0" ] ; then echo "Stopping Shibboleth 1.3 Daemon" PID=`cat $PIDFILE` kill $PID 2>/dev/null else echo "Shibboleth Daemon not running" fi } RestartService () { StopService sleep 2 StartService } RunService "$1"
Content of /Library/StartupItems/Shibboleth-1.3/Shibboleth-1.3/StartupParameters.plist:
{ Description = "Shibboleth 1.3 Daemon"; Provides = ("Shibboleth"); Uses = ("Disks", "NFS"); }
Finally, use the OS X SystemStarter tool to start the Shibboleth 1.3 Daemon:
root# SystemStarter start Shibboleth
Starting Shibboleth 1.3 Daemon
The Apache 1.3 webserver must be configured to load the Shibboleth SP 1.3 module. The OS X Apache startup item must be updated to automatically start the Shibboleth daemon.
Note: Although it is possible to use Shibboleth on a web server withouth SSL, for security considerations it is strongly recommended to configure your web server for https.
Please refer to the Apache documentation on how to do that. You can use the same certificate for the web server as you use for Shibboleth. This guide assumes that you have configured your web server for HTTPS.
Copy the Shibboleth module configuration mod_shib.conf and store it in the /etc/httpd/users directory or in the /etc/httpd/sites directory on a Mac OS X 10.4 Server.
OS X 10.4 (Tiger) workstation:
root# cp /usr/local/shibboleth-1.3/etc/apache/mod_shib.conf /etc/httpd/users
OS X 10.4 Server:
root# cp /usr/local/shibboleth-1.3/etc/apache/mod_shib.conf /etc/httpd/sites
Content of mod_shib.conf file:
## # SWITCHaai # # Shibboleth SP 1.3 ## # load Shibboleth 1.3 module LoadModule mod_shib /usr/local/shibboleth-1.3/libexec/mod_shib_13.so # Shibboleth SP 1.3 config ShibConfig /etc/shibboleth/shibboleth.xml ShibSchemaDir /usr/local/shibboleth-1.3/share/xml/shibboleth <Files *.sso> SetHandler shib-handler </Files> ## # example: protect the /aai location with shibboleth # #<Location /aai> # AuthType shibboleth # ShibRequireSession On # require valid-user #</Location>
On Mac OS X, the default Apache 1.3 webserver is started with the /System/Library/StatupItems/Apache startup item and the /usr/sbin/apachectl script. Both scripts must be updated to enable the Shibboleth module and automatically start the Shibboleth daemon when Apache starts.
Edit and update the OS X Apache /usr/sbin/apachectl script to correctly set the DYLD_LIBRARY_PATH and the DYLD_INSERT_LIBRARIES environment variables:
...
#
# |||||||||||||||||||| START CONFIGURATION SECTION ||||||||||||||||||||
# -------------------- --------------------
#
# Shibboleth SP 1.3
SHIB_HOME=/usr/local/shibboleth-1.3
DYLD_LIBRARY_PATH=$SHIB_HOME/libexec:$SHIB_HOME/lib
DYLD_INSERT_LIBRARIES=$SHIB_HOME/lib/libshib-target.dylib:$SHIB_HOME/lib/libshib.dylib
export DYLD_LIBRARY_PATH DYLD_INSERT_LIBRARIES
...
Edit the OS X Apache startup item /System/Library/StatupItems/Apache/StartupParameters.plist configuration and add a Requires directive to automatically start the Shibboleth daemon.
{
Description = "Apache web server";
Provides = ("Web Server");
Uses = ("Disks", "NFS");
Requires = ("Shibboleth");
}
Finally, stop and start your Apache 1.3 webserver. Verify that the Shibboleth daemon is started too:
root# SystemStarter stop "Web Server" Stopping Apache web server /usr/sbin/apachectl stop: httpd stopped root# SystemStarter start "Web Server" Starting Shibboleth 1.3 Daemon Starting Apache web server Processing config directory: /private/etc/httpd/users/*.conf Processing config file: /private/etc/httpd/users/mod_shib.conf /usr/sbin/apachectl start: httpd started
Mac OS X Server uses the Server Admin application to manage the Apache web server. This application is a front end for the servermgrd daemon, which monitor and manage the Apache process.
Backup and modify the default OS X Server servermrgd LaunchDaemon /System/Library/LaunchDaemons/com.apple.servermgrd.plist configuration file and add the key EnvironmentVariables as follow:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>EnvironmentVariables</key>
<dict>
<key>DYLD_INSERT_LIBRARIES</key>
<string>/usr/local/shibboleth-1.3/lib/libshib-target.dylib:/usr/local/shibboleth-1.3/lib/libshib.dylib</string>
<key>DYLD_LIBRARY_PATH</key>
<string>/usr/local/shibboleth-1.3/lib:/usr/local/shibboleth-1.3/libexec</string>
</dict>
<key>Label</key>
<string>com.apple.servermgrd</string>
<key>OnDemand</key>
<false/>
<key>Program</key>
<string>/usr/sbin/servermgrd</string>
<key>ProgramArguments</key>
<array>
<string>servermgrd</string>
<string>-x</string>
</array>
<key>ServiceIPC</key>
<false/>
</dict>
</plist>
In order to release attributes to your Service Provider the Shibboleth Identity Provider (Home Organization) needs to know all Service Providers they can communicate with. Therefore, they have to regularely update their metadata files. There is a tool called 'Resource Registry' (also see the information about the Resource Registry) whose purpose is to have an up-to date list of all Identity Provider and Service Provider in the SWITCHaai Federation.
It is vital that you register your Service Provider in the AAI Resource Registry.
To register a resource, go to the AAI Resource Registry and log in via AAI. After you are logged in, you can 'add a Resource Description'. You have to provide some technical details about your Service Provider (Resource) and then finally submit the Resource Description to the Resource Registry Authority Admin of your Home Organization. This person then has to approve your Resource before it gets active, which means that the Identity Providers receive the metadata of your Service Provider.
Protecting certain directories or pages with Shibboleth can be done via the web server or within an application itself.
Using the web server, e.g. Apache one can define rules like:
AuthType shibboleth ShibRequireSession On ShibRequireAll On require affiliation student require homeOrganization unizh.ch ethz.chin the Apace configuration file or in a .htaccess files.
Within an application you can access all available Shibboleth attributes as environment variables (e.g. for PHP in $_SERVER or for Perl in %ENV). This allows much more flexible authorization of users than with the web server's access rules.
You find more detailed instructions on how to protect a Resource with Shibboleth on our Shibboleth Service Provider Access Rules page.
-- $Id: install-sp-1.3-osx.html,v 1.31 2008/01/15 14:53:59 schnell Exp $