Changes between Version 9 and Version 10 of SpSetup

Timestamp:

06/19/14 10:04:01 (10 years ago)

Author:

dabantz@…

Comment:

--

SpSetup

@@ -18 +18 @@
   * [[http://download.opensuse.org/repositories/security://shibboleth/|Binary RPMs]]
   * [[http://www.shibboleth.net/downloads/service-provider/latest/SRPMS/|Source RPMs]]
-2. Configure the SP
- 1. Remove and regen the SP keys.
+2. Configure the SP[[br]]
+ 2.1. Remove and regen the SP keys.
   * Linux:
 {{{
@@ -33 +33 @@
 }}}
   * Windows: TBD
- 2. Download and setup the IdP's metadata. Check config for correct syntax.
+ 2.2. Download and setup the IdP's metadata. Check config for correct syntax.
+There are two approaches; either is configured in '''shibboleth2.xml''' configuration file:[[br]]
+ 2.2.1 simply keep an unchanging local copy of the UA IdP metadata[[br]]
+ 2.2.2 use the !InCommon metadata and refresh to maintain current version
+The first option is easier to set up; if the IdP metadata changes, however - in particular if the IdP's certificate is changed and published in new metadata, you will have to be aware of that change and manually update the local copy.  The second option requires importing the !InCommon signing key, and will trigger refreshes of the metadata on a schedule you choose (usually every several hours).  The second method is more general and would allow you to include additional Identity Providers from InCommon should that need arise.[[br]]
+[[br]] Option 1: Manually maintained local copy of IdP metadata:
+
   * Linux:
 {{{
@@ -65 +71 @@
 }}}
   * Windows: TBD
+Option 2: rely on !InCommon metadata:
+
+Comment out the locally maintained metadata section in shibboleth2.xml and include the following:
+{{{
+        <MetadataProvider type="XML" uri="http://md.incommon.org/InCommon/InCommon-metadata.xml" backingFilePath="federation-metadata.xml" reloadInterval="7200">
+            <MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
+            <MetadataFilter type="Signature" certificate="incommon.pem"/>
+            <MetadataFilter type="Whitelist">
+                <Include>urn:mace:incommon:alaska.edu</Include>
+            </MetadataFilter>
+        </MetadataProvider>
+}}}
+This configuration checks the signature of the InCommon metadata, so you need to download and install that long-lived certificate.  The process is detailed below (from https://spaces.internet2.edu/display/InCFederation/Metadata+Signing+Certificate).  Once you have downloaded and verified the fingerprint of that certificate, save it in the same directory as shibboleth2.xml under the name incommon.pem.
+{{{
+Metadata Signing Certificate
+The InCommon metadata signing certificate is a long-lived, self-signed certificate containing the public key corresponding to the private metadata signing key. Important details about the metadata signing certificate are shown on this authoritative web page:
+
+https://ops.incommon.org/inc_md_cert.html
+Note in particular the certificate fingerprints listed at the top of that page. InCommon Operations certifies that these are the actual fingerprints of the metadata signing certificate. Accept no substitute!
+
+Bootstrapping Trust
+To ensure the security of your metadata refresh process, you must verify the XML signature on each and every metadata aggregate you consume. To do that, you need an authentic copy of the metadata signing certificate. The certificate must be obtained securely since all subsequent operations depend on it.
+
+To obtain an authentic copy of the metadata signing certificate, perform the following steps:
+
+Download a copy of the metadata signing certificate via a secure channel
+Compute the SHA-1 and SHA-256 fingerprints of the metadata signing certificate
+Compare the computed fingerprints to the actual fingerprints
+The latter two steps guarantee the integrity of the metadata signing certificate so obtained.
+
+        Check the integrity of the metadata signing certificate!
+To bootstrap your trusted metadata process, you MUST check the integrity of the metadata signing certificate configured into that process. It is not sufficient to fetch the certificate via a TLS-protected HTTPS connection.
+You may check the integrity of the downloaded certificate in a variety of ways. For example, on a GNU/Linux system, you could use curl and openssl to perform the first two steps of the bootstrap process:
+
+# Step 1: Download a copy of the metadata signing certificate via a secure channel
+$ MD_CERT_LOCATION=https://ds.incommon.org/certs/inc-md-cert.pem
+$ MD_CERT_PATH=/path/to/inc-md-cert.pem
+$ /usr/bin/curl --silent $MD_CERT_LOCATION > $MD_CERT_PATH
+ 
+# Step 2: Compute the SHA-1 and SHA-256 fingerprints of the metadata signing certificate
+$ /bin/cat $MD_CERT_PATH | /usr/bin/openssl x509 -sha1 -noout -fingerprint
+SHA1 Fingerprint=7D:B4:BB:28:D3:D5:C8:52:E0:80:B3:62:43:2A:AF:34:B2:A6:0E:DD
+$ /bin/cat $MD_CERT_PATH | /usr/bin/openssl x509 -sha256 -noout -fingerprint
+SHA256 Fingerprint=2F:9D:9A:A1:FE:D1:92:F0:64:A8:C6:31:5D:39:FA:CF:1E:08:84:0D:27:21:F3:31:B1:70:A5:2B:88:81:9F:5B
+        On a Windows system
+The Shibboleth SP on Windows ships with its own curl and openssl utilities.
+Step 3: The final step is to compare the computed fingerprints to the actual fingerprints. The latter are shown on this authoritative web page:
+
+https://ops.incommon.org/inc_md_cert.html
+If the computed fingerprints match the actual fingerprints, you are done. You may now safely use the certificate to verify the signature on the metadata file.
+}}}
  3. Setup EntityID for SP. Note the entityID for the SP is _NOT_ a URL. It is a unique string that identifies your SP and is usually based off of the hostname of the system. It may also be a CNAME for the system.
   * Linux: