SSO Setup with Shibboleth

Default NameIDFormat in Foundry Metadata

The Foundry SAML service provider metadata includes the following NameIDFormat:

<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>

Important Note

Some identity providers, such as Shibboleth, may default to transient when generating a service provider from metadata that specifies unspecified. If this occurs, you must update the configuration to use the correct format for your institution.

Why Foundry Doesn’t Specify a Preferred NameIDFormat

Foundry does not request a specific NameIDFormat because the correct choice depends on your institution’s setup. It should match the value you plan to store—or already store—in the Foundry users’ SSO ID field. Common options include:

• Email address
• Student ID
• Persistent ID

Everfi does not require a specific format, but it must not be transient.

Advanced: Overriding NameIDFormat in Shibboleth

One Everfi client using Shibboleth shared the following approach for specifying a preferred NameID value. Everfi cannot provide additional Shibboleth guidance, so consult the Shibboleth community for further support.

Step 1: Configure NameID Generator

In saml-nameid.xml, define a NameIdentificationGenerator appropriate for your chosen identifier.

Example: Using Student/Employee Number

<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
      p:omitQualifiers="true"
      p:format="urn:oid:1.3.6.1.4.1.10177.1.101"
      p:attributeSourceIds="#{ {'uniUnivID'} }" />

This uses a URN for the student/employee number. You can provide a comma-separated list of attributes; the first released value will be used. If none are released, the NameID will be blank.

Example: Using Email Address

<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
      p:omitQualifiers="true"
      p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
      p:attributeSourceIds="#{ {'mail','Email'} }" />

Step 2: Override Metadata in relying-party.xml

Edit relying-party.xml to override the metadata’s unspecified request and enforce your preferred format:

<!-- Replace with your institution's Foundry entityID -->
<bean parent="RelyingPartyByName" c:relyingPartyIds="https://admin.fifoundry.net/org_slug/saml/sp">
    <property name="profileConfigurations">
        <list>
            <bean parent="SAML2.SSO" p:nameIDFormatPrecedence="urn:oid:1.3.6.1.4.1.10177.1.101" />
        </list>
    </property>
</bean>

For email, replace the URN with:

urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

You can also define a list of values in bean list format (not comma-separated). Shibboleth will use the first non-null value that matches the metadata or override list.

Key Points

• Use the same URN in both the generator and override.
• Ensure the entityID matches your Foundry configuration.
• Align all components for consistent NameID behavior.

FAQ

Q: When a learner clicks the SSO Login button on the Foundry customer login page, they immediately see this error on our institution’s login page:

“The request cannot be fulfilled because the message received does not meet the security requirements of the login service.”

Why is this happening?

A: This error usually means your identity provider (IdP) cannot validate Foundry’s signature in the AuthnRequest sent by Foundry. Here’s what to check:

1. Verify Foundry’s Signing Certificate and Issuer

   • Ensure your IdP has the correct Foundry signing certificate and issuer (entityID) configured in the Foundry service provider entry.

2. Check the Certificate in Foundry

   • Foundry signs requests using the certificate specified in its Identity Provider Configuration.
   • Confirm that the certificate in Foundry matches the signing certificate configured in your IdP.

3. Look for Recent Changes

   • If SSO was working previously, this error typically indicates a certificate mismatch caused by recent updates to certificates.