Page History
...
Very Basic Overview
idP IdP (Identity Provider): A web-based system that can authenticate a user on behalf of another system called SP (for Service Provider).
In the present casethis implementation of SSO, the SP consists of the Shibboleth SP version 3 software. See https://shibboleth.atlassian.net/wiki/spaces/SP3/overview .
Upon successful login at the idPIdP, the idP IdP will send information about the user back to the SP as "attributes" – in the present case, at least "remote_user".
Among other things, The SP must be configured to specify which of these attributes should be passed to the shrine code (in the form of request headers).
...
Filename | Location on SP | Notes |
---|---|---|
idp-metadata.xml | /etc/shibboleth/idp-metadata.xml | A copy of your IdP's metadata. |
key pair | /etc/shibboleth/sp-key.pem /etc/shibboleth/sp-cert.pem | Create a key pair; include the certificate (sp-cert.pem) in sp-metadata.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 idPIdP's maintainers/admins; or omit from the SP, and instead email it to the IdP admins In either case, populate the public key certificate with yours |
shibboleth2.xml | /etc/shibboleth/shibboleth2.xml | Specifies many aspects of your SP |
attribute-map.xml | /etc/shibboleth/attribute-map.xml | Specifies the user-information that your IdP sends to the SP upon a successful SSO login |
sp.conf | /etc/httpd/conf.d/sp.conf | Tells Apache to require Shibboleth login for Shrine Urls (/shrine-api/*) . Tomcat should open port 8080 only to localhost (???), and should reside on the same host as your SP |
shrine.conf | /opt/shrine/tomcat/lib/shrine.conf | replace "shrine-sso-node01" with your own node name add the following shrine element: queryEntryPoint { |
...
The following tells Shibboleth to make the attributes it collects from the idP IdP available as request headers in Apache. This is the opposite of what is recommended, i.e. the Shibboleth documentation says that ideally ShibUseEnvironment
should be On (resulting in request attributes) and ShibUseHeaders
should be Off. However the recommended setup requires proxying to Tomcat using the AJP protocol, which we are not using because it is being phased out of Tomcat (so we are proxying using the HTTP protocol). Also, see https://shibboleth.atlassian.net/wiki/spaces/SHIB2/pages/2577072327/NativeSPApacheConfig.
...
Shibboleth consists of a Daemon plus an apache module. This Apache module 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 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)
...
entityID: the ID of our Service Provider (SP)
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 that matches from the list which matches the name of an attribute returned by the idP IdP will be used.
<ApplicationDefaults entityID="https://shrine-sso-node01.catalyst.harvard.edu"
REMOTE_USER="ecommonsid eppn uid persistent-id targeted-id"
signing="true"
>
...
The following specifies the entityID of the idP IdP to use for authentication. We also specify that we speak only SAML2 protocol.
...
<Handler type="Session" Location="/Session" showAttributeValues="true"
contentType="application/json"
/>
The idPIdP's metadata is stored in a file called idp-metadata.xml. It should be obtained from the idP IdP admin/maintainer.
<MetadataProvider type="XML" validate="true" path="idp-metadata.xml"/>
The attribute-map.xml file will specify which attributes are extracted from the idPIdP's response and the name of the request headers they will be available as (to the java code). More on this file later.
...
the "Location" attribute specifies the URL at which the idP IdP will post the user info after a successful login:
...