Page History

...

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

...

entityID: the ID of our Service Provider (SP)

Our current version of the Shrine application does not support the use of Request headers. However if you decide to go that way instead of using AJP and request attributes, the following paragraph is pertinent:

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 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 attributePrefix 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.

...

<ApplicationDefaults entityID="https://shrine-sso-node01.catalyst.harvard.edu"
  signing="true"
  attributePrefix="AJP_"
>

...

shrine-sso-node01.catalyst.harvard.edu"
  signing="true"
  attributePrefix="AJP_"
>

if using request headers instead of request attributes and AJP, include the following in the ApplicationDefaults element:

The REMOTE_USER xml attribute of ApplicationDefaults should 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.

REMOTE_USER="ecommonsid eppn uid persistent-id targeted-id"

...

The following specifies the entityID of the IdP to use for authentication. We . Get it from your idP admin(s). We also specify that we speak only SAML2 protocol.

            <SSO entityID="http://sso.med.harvard.edu/adfs/services/trust">
                SAML2
            </SSO>

...

The IdP's metadata is stored in a file called idp-metadata.xml. It should be obtained from the IdP admin/maintainer(s).

<MetadataProvider type="XML" validate="true" path="idp-metadata.xml"/>

The attribute-map.xml file (as set by the "path" xml attribute) will specify which attributes are extracted from the IdP's response and the name of the request headers or attributes they will be available as to the java code. More on this file laterbelow.

<AttributeExtractor type="XML" validate="true" reloadChanges="false" path="attribute-map.xml"/>

...

<CredentialResolver type="File" key="/etc/shibboleth/sp-key.pem" certificate="/etc/shibboleth/sp-cert.pem"/>

We left this these elements and the files it points they point to unchanged:

<SecurityPolicyProvider type="XML" validate="true" path="security-policy.xml"/>
<ProtocolProvider type="XML" validate="true" reloadChanges="false" path="protocols.xml"/>

...