Based on your system type, follow the appropriate steps below to create your service provider's self-signed certificate:

• RPM-based system OR Compile from Source, enter the following:
  cd /etc/shibboleth
  mv sp-cert.pem sp-cert.pem.old
  mv sp-key.pem sp-key.pem.old
  sh keygen.sh -u shibd -g shibd -h hostname -y 10
  

• Windows systems, enter the following:
  cd c:/opt/shibboleth-sp/etc/shibboleth
  ren sp-cert.pem sp-cert.old
  ren sp-key.pem sp-key.old
  keygen.bat -h hostname -y 10
  

Note: In both examples, sp-cert.pem and sp-key.pem are the default certificates. Backup each of these certificates, then replace them with the certificates you generated above.  Your hostname typically reflects your service's actual hostname (CNAME or ANAME).  The -y 10 specifies the lifetime of the certificate to be created.

Most of the configuration for a Shibboleth service provider is in the /etc/shibboleth/shibboleth2.xml file. Note the following:

Linux systems:

• Copy the cmu-linux-25-shibboleth2.xml file that you downloaded in Set Up and Install: Step 2 to the new location and filename /etc/shibboleth/shibboleth2.xml
• Copy the incommon.pem file that you downloaded in Set Up and Install: Step 2 to the new location: /etc/shibboleth/

Windows systems:

• Copy the cmu-windows-25-shibboleth2.xml file that you downloaded in Set Up and Install: Step 2 to the new location and filename C:/opt/shibboleth-sp/etc/shibboleth/shibboleth2.xml

• Copy the incommon.pem file that you downloaded in Set Up and Install: Step 2 to the new location: C:/opt/shibboleth-sp/etc/shibboleth/

Edit the /etc/shibboleth/shibboleth2.xml File

1. UPDATE 'name' and 'host name' TO REFLECT YOUR HOSTNAME

   ONLY COMPLETE IF ON WINDOWS OS, OTHERWISE MOVE TO STEP 2

   Remember to use the same hostname that was used with your certificate generation.

   <Site id="1" name="sp.example.org"/> and 

   <Host name="sp.example.org">

   Note: Makes sure the above Site id matches the Site Id specified in IIS

2. UPDATE THE ENTITYID TO REFLECT YOUR HOSTNAME
   Remember to use the same hostname that was used with your certificate generation.
   <ApplicationDefaults entityID="https://sp.example.org/shibboleth" REMOTE_USER="eppn persistent-id targeted-id">
3. UPDATE THE SUPPORT CONTACT INFORMATION
   The email address provided will be used when displaying error message pages or the logout page.
   <Errors supportContact="root@localhost" logoLocation="/shibboleth-sp/logo.jpg" styleSheet="/shibboleth-sp/main.css"/>
4. ENABLE FETCHING: InCOMMON METADATA
   Metadata is the information used to locate and establish trust between service provider and identity providers that use shibboleth. Carnegie Mellon identity and service providers are part of the InCommon Federation. To fetch the metadata from the InCommon Federation, one of the XML configuration blocks in shibboleth2.xml must be uncommented. Do one of the following:
   • If your service is within SII, uncomment the following block: 
     <MetadataProvider type="XML" uri="http://md.incommon.org/InCommon/InCommon-metadata-idp-only.xml" backingFilePath="incommon-metadata.xml" reloadInterval="7200">
     <MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
     <MetadataFilter type="Signature" certificate="incommon.pem"/>
     <TransportOption provider="CURL" option="10004">proxy.andrew.cmu.edu:3128</TransportOption>
     </MetadataProvider>
   • If your service provider is directly on the Internet, uncomment the following block:
     <MetadataProvider type="XML" uri="http://md.incommon.org/InCommon/InCommon-metadata-idp-only.xml" backingFilePath="incommon-metadata.xml" reloadInterval="7200">
     <MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
     <MetadataFilter type="Signature" certificate="incommon.pem"/>
     </MetadataProvider>
     
     The InCommon metadata will be periodically fetched, its signature verified, and your service provider's metadata configuration will be updated automatically.
5. SELECT THE DISCOVERY SERVICE OR A SINGLE IDENTITY PROVIDER
   Shibboleth allows the use of a discovery service, which permits a user to select which identity provider they will use for authentication. Alternatively, the service provider may configure one static identity provider to use. Do one of the following:
   • To use only the Carnegie Mellon identity provider:
     • Uncomment the following block: <SSO entityID="https://login.cmu.edu/idp/shibboleth"<https://login.cmu.edu/idp/shibboleth>> SAML2 SAML1 </SSO>
     • InCommon registration will allow individuals from other institutions to authenticate to your service. If you want to limit your web server to only Carnegie Mellon, you must configure your web server/application to verify that the userid is @andrew.cmu.edu. See step 3 for detailed instructions.
   • To use the InCommon Discovery Service:
     • Uncomment the following block: <SSOdiscoveryProtocol="SAMLDS" discoveryURL="https://wayf.incommonfederation.org/DS/WAYF"<https://wayf.incommonfederation.org/DS/WAYF>> SAML2 SAML1 </SSO>

Follow these steps to restrict access to only Carnegie Mellon (andrew.cmu.edu) users:

Apache Servers

1. In your .htaccess file or shib.conf configuration file, do the following:
   replace require valid-user with require eppn ~ .*@andrew.cmu.edu$

2. Edit shibboleth2.xml

3. Add an additional MetadataFilter tag below <MetadataProvider>:

   <MetadataFilter type="Whitelist">
   <Include>https://login.cmu.edu/idp/shibboleth</Include>
   </MetadataFilter>

Microsoft IIS Servers

1. Edit shibboleth2.xml, under <RequestMap> <Host.../> or under <RequestMap> <Path .../> include: <AccessControlProvider path="C:\opt\shibboleth-sp\etc\shibboleth\shibboleth2_ACL.xml" type="XML"/>
2. Contents of shibboleth2_ACL.xml:
   <?xml version="1.0" encoding="UTF-8"?>
   <AccessControl xmlns="urn:mace:shibboleth:target:config:1.0"/>
   <RuleRegex require="eppn">@andrew.cmu.edu$</RuleRegex>

3. Add an additional MetadataFilter tag below <MetadataProvider>:

   <MetadataFilter type="Whitelist">
   <Include>https://login.cmu.edu/idp/shibboleth</Include>
   </MetadataFilter>

At this point your system should have a properly configured shibboleth; however, it will NOT work until you Request Web Login Authentication for your server to be formally registered with Web Login.

You will be contacted once the registration is complete; you should allow two business days.

1. Using a web browser on your service provider, visit: https://HOSTNAME/Shibboleth.sso/Status. Information about your service provider should be displayed.
2. Access https://HOSTNAME/secure. This will redirect your browser to either a discovery service or identity provider permitting you to log in.   
   Note: If you do not have a secure directory configured in apache, access will fail.  If you host multiple IP addresses, add the non-default IP address to your /etc/shibboleth/shibboleth2.xml file: <Handler type="Status" Location="/Status" acl="128.2.xxx.xxx ::1"/>