Federation metadata is signed for integrity and authenticity. Participants are strongly encouraged to verify the XML signature on the metadata file before use; failure to do so will seriously compromise the security of your SAML deployment.

To verify the XML signature on the metadata file before use, review the Metadata Refresh Policy.

In addition to accepting identities from InCommon, some applications have an additional administrative area that will only accept identities from a specific identity provider.  Administrative users may find it annoying to work through a discovery service when they know that certain web pages will only accept identities from specific identity provider. The shibboleth2.xml configuration file normally defines where a user is directed when Shibboleth authentication is required.

In the shibboleth2.xml configuration file, the user may be directed to a discovery service: 

<SSO discoveryProtocol="SAMLDS" discoveryURL="https://wayf.incommonfederation.org/DS/WAYF">
SAML2 SAML1 </SSO>

 or to one specific identity provider:

 <SSO entityID="https://some-idp.domain.edu/idp/shibboleth">
SAML2 SAML1 </SSO>

In the apache configuration file the following directives are normally used to protect pages with Shibboleth and will redirect an authenticating user to a discovery service or identity provider specified in shibboleth2.xml:

<Location /somewebpath/*.cgi>
AuthType shibboleth
ShibRequestSetting requireSession 1
ShibUseHeaders on
require valid-user
</Location>

The following directives within an Apache configuration file will override the specification within the shibboleth2.xml file for specific pages and direct the authenticating user to a specific identity provider:

<Location /anotherwebpath/*.cgi>
AuthType shibboleth
ShibRequestSetting requireSession 1
ShibRequestSetting entityId https://login.cmu.edu/idp/shibboleth
ShibUseHeaders on
require valid-user
</Location>

Note that this configuration only affects where users are directed when authentication is required. Those who already have Shibboleth sessions will not be redirected even if they have not authenticated via the https://login.cmu.edu/idp/shibboleth. The restrictions on acceptance of user identities by the application must still be enforced by the application itself.

If your application does not support CMU's AndrewID domain, follow the instructions provided below:

1. Add the following line to /etc/shibboleth/attribute-map.xml:
   <Attribute name="urn:oid:1.3.6.1.4.1.3.5.1.1210" id="cmuAndrewCommonNamespaceId"/>
   Note: This adds the CMU specific attribute to the list of known mapped attributes.
2. In /etc/shibboleth/shibboleth2.xml where HOSTNAME is the name of your service as known to users, change the following line
   FROM:
   <ApplicationDefaults entityID="https://HOSTNAME/shibboleth" REMOTE_USER="eppn persistent-id targeted-id">
   TO:
   <ApplicationDefaults entityID="https://HOSTNAME/shibboleth" REMOTE_USER="cmuAndrewCommonNamespaceId">

Note: This configuration should be used to support legacy applications only. New web services should be designed to use an identifier in the form of "user@domain" to represent the authenticated identity. To release "cmuAndrewCommonNamespaceID" for your service provider, email a request to the Shibboleth team.