Versions Compared

Old Version 122

changes.mady.by.user Xavier Haurie

Saved on

compared with

New Version 123

changes.mady.by.user Xavier Haurie

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

IdP (Identity Provider): A web-based system that can authenticate a user on behalf of another system called a SP (for Service Provider).

...

Among the many configuration files, there are nine which need to be modified to reflect your installation, as follows in the table below.

Each of these files needs to be adjusted to the particulars of your site , your and requirements. Ssearch Search for the marker: 'ADJUST_FOR_YOUR_SITE' in those files for indications of what / where you need to edit.

FilenameLocation on SPNotes
idp-metadata.xml

/etc/shibboleth/idp-metadata.xml

A copy of your IdP's metadata. You'll need to ask the admins admin(s) of your iDP for a copy of it.
key pair

/etc/shibboleth/sp-key.pem

/etc/shibboleth/sp-cert.pem

Create a key pair; include the content of the certificate (sp-cert.pem) in sp-metadata.xml (see below), and the paths of the key and certificate as xml attributes of the <CredentialResolver> element of shibboleth2.xml (see below)

sp-metadata.xml

/var/www/html/sp-metadata.xml 

– if your Apache sets DocumentRoot to /var/www/html (for instance in /etc/httpd/conf/httpd.conf) 

To be shared dynamically with your site's Shibboleth IdP (i.e. make it available at a given URL and share that URL with your IdP's maintainers/admins); or omit from the SP's web server, and instead email it to the IdP admins whenever it changes (if it does)

In either case, populate the entityID, public key certificate, and consumer service location with yours (what about protecting the private key with a password as per iTeam?)

shibboleth2.xml/etc/shibboleth/shibboleth2.xml

Specifies many aspects of your SP. You need to populate the <ApplicationDefaults> element's entityID and the <SSO> element's entityID xml attribute. Note that we do not make use of the REMOTE_USER xml attribute in our implementation. The remote user is specified in the attribute-map.xml instead of in shibboleth2.xml. 

The <CredentialResolver> element specifies the private+public key to use for encryption and signing while communicating with the iDP. If you put the keys in the location specified above, there is no need to modify this element. (private key should be in a "safe" location and password protected. see what iTeam/Simon does)

The <AttributeExtractor> element specifies the location of the file that specifies which attribute returned by the iDP must be made available to the the Tomcat's java code as Servlet Request attributes.

attribute-map.xml /etc/shibboleth/attribute-map.xml The file name and path of this file is specified in the <AttributeExtractor> element's path xml attribute in shibboleth2.xml. This file specifies the SAML content that your SP turns into "attributes". In our implementation it specifies that the "ecommonsid" SAML attribute returned by the iDP upon successful login will be made available to the java code running on Tomcat as the Servlet Request attribute "remoteUser". 
sp.conf/etc/httpd/conf.d/sp.conf

Tells Apache to require Shibboleth login for Shrine Urls (/shrine-api/*), and to proxy all the relevant HTTP requests to the Shrine application using the AJP protocol.

Tomcat should open port 8009 only to localhost, and should reside on the same host as your SP.

shrine.conf

override.conf

/opt/shrine/tomcat/lib/shrine.conf

/opt/shrine/tomcat/lib/override.conf


server.xml/opt/shrine/tomcat/conf/server.xmlSet up as the receiving end of AJP over NIO2 connection with Apache. No changes are needed.

...

<Attributes xmlns="urn:mace:shibboleth:2.0:attribute-map" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<!-- The 'name' attributes need to match exactly what your IdP sends in
its response to your (successful) AuthnRequest

 E.g.
 -->
<Attribute name="ecommonsId" id="remoteUser"/>
<Attribute name="Email" id="email"/>
<Attribute name="Firstname" id="firstname"/>
<Attribute name="Lastname" id="lastname"/>

</Attributes>

Apache Configuration

Note: Apache version should be 2.4.10 or higher so that the local address request field gets populated for use in the back-end code. (see: https://bz.apache.org/bugzilla/show_bug.cgi?id=56661). If it isn't populated the back-end fails with an NPE when looking for the local address in the request.

...

The following tells Apache to proxy all calls to URLs starting with "shrine-api" to http://127.0.0.1:8009/shrine-api/ over the AJP protocol. Therefore we need to set up Tomcat to listen for AJP traffic on port 8009 (see Tomcat Configuration below). In sp.conf it looks like:

ProxyPass ProxyPass "/shrine-api/" "ajp://<YOUR_HOST>:8009/shrine-api/".   (TODO: does it really have to use <YOUR_HOST> instead of 127.0.0.1? in any case need to match line above)

...

Tomcat should accept requests on port 8009, but only from localhost, and redirect to the SSL port 6443.

Configure port 6443:

    <Connector port="6443" protocol="org.apache.coyote.http11.Http11NioProtocol"
               maxThreads="150" SSLEnabled="true" scheme="https" secure="true">
        <SSLHostConfig clientAuth="none" sslProtocol="TLS" sslEnabledProtocols="TLSv1.3,TLSv1.2"
               honorCipherOrder="true" ciphers="TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,
               TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
               TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256">
            <Certificate certificateKeystoreFile="/opt/shrine/shrine.keystore"
                         certificateKeystorePassword="changeit"
                         certificateKeyAlias="*.catalyst.harvard.edu" />
        </SSLHostConfig>
    </Connector>

...

The entityId attribute specifies who we are

...

  <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="https://shrine-sso-node01.catalyst.harvard.edu">
    <md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
     

...

<md:KeyDescriptor>
        <ds:KeyInfo>
          <ds:X509Data>

            <!-- ADJUST_FOR_YOUR_SITE (X509Certificate) →            <ds:X509Certificate>MIIC6zCCAdOgAwIBAgIJAOy0nki3WAOVMA0GCSqGSIb3DQEBBQUAMBcxFTATBgNV

BAMTDDc5OTQzZmVlNzg2NTAeFw0xNTEyMTEwMzAwNDJaFw0yNTEyMDgwMzAwNDJa                 

MBcxFTATBgNVBAMTDDc5OTQzZmVlNzg2NTCCASIwDQYJKoZIhvcNAQEBBQADggEP

ADCCAQoCggEBALPBzAz0DTn+j2YsQKfqWI+m08lP5UzwVsE9ZKzLqO3PRHZqiOBm

EaFmRrYCZCAOcJ0TXcxPGtNSo8HC4uw5/Y5lJGuI3jN7X7KB1VUQDpUSwfgOqtro

uDoVRKrsaYZTnlNV8KbZ0WQz5s4Uw6CxKRB9RZ5iQMP1fuxc8B6GSOb3x69MiY6c

1jlgVAc6rV4zGfpafacxOLM8qcYhY8u3TiSd0H+oiGEqi1mFLK8yp6FKzX8OUkQf

We49YHz6wBxFOe+/p+7ziym1rBs/lGfenEo8ziCIMmjnoo257fz00bcz9rFl1rTx

KLFfgy72xTlG72l6u+pB9VqK3YNJS52Ns5UCAwEAAaM6MDgwFwYDVR0RBBAwDoIM

Nzk5NDNmZWU3ODY1MB0GA1UdDgQWBBRiDMNPjiAMC50WWubI3PMjP45S/DANBgkq

hkiG9w0BAQUFAAOCAQEAYZM/iWgC93vAq0d98egEzvESKodxHffkDOagd4Kxt/S0

AAHsVQCmAK/9kmRhsWzR3f1KIw98q4EX7nH/K68BFrerUvaL5+fEGE9W6Ki6QdW8

bM17GQkLyRDKZzGPm/hsaG1Oxru2kDf7qSvv59aRZlZ8skrDEnx8+dZ8JKC02ZDU

ClC+xWl1UPfO2BL4tJei/siSymGpiRqznQ2JMoTFu5CUUpoxyCVz1bl9lCVceoJ9

FaL38knS0p5DnXcm+I8wqNEVGLDPbDalBQryhJT9fIMm1/B85gB3AWAvcu9PPfHK

lQQUhxyEXTBJx3luLlpIjoloFKIute9K7pE5qAENjg== </ds:X509Certificate>
          </ds:X509Data>
        </ds:KeyInfo>
      </md:KeyDescriptor>

the "Location" xml attribute specifies the URL at which the IdP will post the user info after a successful login:

...

    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://shrine-sso-node01.catalyst.harvard.edu/Shibboleth.sso/SAML2/POST" index="1"/>
  </md:SPSSODescriptor>
</md:EntityDescriptor>

Running it


Developer tools

...