Page History
...
IdP (Identity Provider): A web-based system that can authenticate a user on behalf of another system called SP (for Service Provider).
...
| Filename | Location on SP | Notes |
|---|---|---|
| idp-metadata.xml | /etc/shibboleth/idp-metadata.xml | A copy of your IdP's metadata. You'll need to ask the admins 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, and the paths of the key and certificate as xml attributes of the <CredentialResolver> element of shibboleth2.xml |
| 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 |
| 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. 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 replace "shrine-sso-node01" with your own node name add the following element under the top-level "shrine" element: OR add the following line to override.conf:
| |
| server.xml | /opt/shrine/tomcat/conf/server.xml | Set up as the receiving end of AJP over NIO2 connection with Apache. No changes are needed. |
More-Detailed Discussion of Shibboleth, Apache, and Tomcat Configuration
Here we discuss key items in the various configuration files; not only the items that need to be modified but also those that deserve an explanation.
Shibboleth Configuration
| server.xml | /opt/shrine/tomcat/conf/server.xml | Set up as the receiving end of AJP over NIO2 connection with Apache. No changes are needed. |
More-Detailed Discussion of Shibboleth, Apache, and Tomcat Configuration
Here we discuss key items in the various configuration files; not only the items that need to be modified but also those that deserve an explanation.
Shibboleth Configuration
Shibboleth consists of a Daemon plus an apache module. These must be configured for Shibboleth to intercept certain requests (see Apache Configuration belowShibboleth consists of a Daemon plus an apache module. These must be configured for Shibboleth to intercept certain requests (see Apache Configuration above). When a request is intercepted, Shibboleth will decide whether the user (1) needs to login at the configured IdP (which will present a login form to the user), or (2) is already logged in (and Shibboleth will let the request be served as if it wasn't there to intercept it)
...
REMOTE_USER: how the REMOTE_USER attribute will be populated, in the form of a list of attribute names. Note that "ecommonsid" which is specific to HMS IT, comes first, so for this environment REMOTE_USER will be set to the value of "ecommonsid". Otherwise, the first attribute name from the list which matches the name of an attribute returned by the IdP will be used.
"attributePrefix" must must be set to "AJP_" so that the attributes from the "attribute-map.xml" file (see below) are passed to Tomcat as request attributes (as opposed to request headers). See also server.xml on the same topic.
...
<Connector protocol="org.apache.coyote.ajp.AjpNio2Protocol"proxyName="shrine-sso-node01"enableLookups="true"address="0.0.0.0"allowedRequestAttributesPattern=".*"port="8009"secretRequired="false"redirectPort="6443" />=".*"port="8009"secretRequired="false"redirectPort="6443" />
/opt/shrine/tomcat/lib/shrine.conf, /opt/shrine/tomcat/lib/override.conf
Explaining shrine.conf and override.conf is beyond the scope of the present document. However here are the changes you must make to them for SSO.
Option 1:
add the following element under the top-level "shrine" element in shrine.conf
queryEntryPoint {authenticationType = "sso"}
Option 2:
add the following line to override.conf:
shrine.queryEntryPoint.authenticationType = "sso"
SP Metadata
/var/www/html/sp-metadata.xml
...
Overview
Content Tools