Page History

...

We left this and the file it points to unchanged:

...

<AttributeResolver type="Query"

...

 subjectMatch="true"/>

...

<AttributeFilter type="XML"

...

 validate="true"

...

 path="attribute-policy.xml"/>

This points to the key pair we created above:

...

<CredentialResolver type="File"

...

 key="/etc/shibboleth/sp-key.pem"

...

 certificate="/etc/shibboleth/sp-cert.pem" password="<only if needed>" />

We left these elements and the files they point to unchanged (read https://shibboleth.atlassian.net/wiki/spaces/SP3/pages/2065334523/SecurityPolicyProvider):

...

<SecurityPolicyProvider type="XML"

...

 validate="true"

...

 path="security-policy.xml"/>

...

<ProtocolProvider type="XML"

...

 validate="true"

...

 reloadChanges="false"

...

 path="protocols.xml"/>

If needed, refer to shibboleth2.xml.dist

/etc/shibboleth/idp-metadata.xml

Get it from your IdP.

/etc/shibboleth/attribute-map.xml

The path of this file is specified in the <AttributeExtractor> element in shibboleth2.xml. This file specifies the SAML content that your SP turns into "attributes". These will be made available to the Servlet Request running on Tomcat. For Shrine SSO, the only attribute needed here is the user id returned by the idP, mapped to the "userId" id so it matches the REMOTE_USER attribute in shibboleth2.xml.

IMPORTANT: you must specify exactly one attribute whose id is "userId". The Shrine SP code will look for a request attribute of that id to populate the user name in the code (which appears in the user account "badge" at the top-right corner of the UI). 

<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

...

-->

...

<Attribute name="[idP's name for the user id]" id="userId"/

...

></Attributes>