Shibboleth Customer Configuration Guide for SAML Single Sign-On Integration

Overview

This guide describes the SAML values that a Shibboleth identity provider must send to Accruent to support customer single sign-on.

This guide is intended for identity provider administrators. Contact Accruent Support for environment-specific service provider settings.

A successful sign-in requires the following:

  • A stable NameID value that identifies the user across sign-ins.
  • SAML attributes that provide the user's username, email address, and optional profile information.

Important: The NameID value and SAML attributes are separate elements. Releasing an email attribute does not replace the requirement for a stable NameID.

ClosedRequired login identifier

NameID format

Configure the SAML subject NameID using one of the following formats.

Preferred format Format identifier Example value Notes
Persistent urn:oasis:names:tc:SAML:2.0:nameid-format:persistent 7f3b2d1e-6a4b-4c91-9a32-2a6f1d8e4c10 Preferred when the identity provider can issue a stable opaque identifier.
Email address urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress [email protected] Acceptable when the email address is stable and will not be reassigned.

Do not use the following format:

urn:oasis:names:tc:SAML:2.0:nameid-format:transient

A transient NameID can change between sign-ins. When that happens, the application might not recognize the same user across sessions.

NameID requirements

  • Release exactly one NameID value for each sign-in.
  • Keep the value stable for the lifetime of the user account.
  • Do not use a short-lived session identifier.
  • Do not use a value that changes when the user's display name or email changes unless email has been designated as the stable identifier.
  • Scope persistent identifiers to the Accruent service provider.

ClosedSAML attributes to release

Release the following attributes to the Accruent service provider.

Username / identity

The stable SAML NameID is the primary login identifier. When available, eduPersonPrincipalName is the preferred Shibboleth attribute.

Preferred claim type Alternative claim type SAML attribute name Requirement Example value Use
Stable SAML NameID None NameID with format persistent or stable emailAddress Required [email protected] Identifies the user across sign-ins.
eduPersonPrincipalName Stable SAML NameID urn:oid:1.3.6.1.4.1.5923.1.1.1.6 Recommended [email protected] Preferred username value for Shibboleth deployments.
SAML email Stable SAML NameID or ePPN http://schemas.xmlsoap.org/ws/2005/05/identity/claims/email Alternative [email protected] Fallback username value.
SAML email address Stable SAML NameID or ePPN http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress Alternative [email protected] Fallback username value.
mail Stable SAML NameID or ePPN mail Alternative [email protected] Fallback username value.

Important: The NameID must remain stable. Do not use a transient or changing value as the primary identifier.

Email profile claim

Preferred claim type Alternative claim type SAML attribute name Requirement Example value Use
Shibboleth mail SAML email or email address urn:oid:0.9.2342.19200300.100.1.3 Recommended [email protected] Populates the email claim.

Given name

Given name is recommended but not required for authentication.

SAML attribute name Requirement Example value
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname Recommended Jane

Family name / surname

Family name is recommended but not required for authentication.

SAML attribute name Requirement Example value
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname Recommended Doe

Attribute value requirements

  • Send one string value for each attribute.
  • Do not send empty values for required attributes.
  • Use the user's actual email address for mail.
  • Use a stable institution-controlled value for eduPersonPrincipalName.
  • Do not send display names as username or email values.

ClosedRecommended shibboleth release configuration

Configure the Shibboleth attribute resolver and attribute filter to release the required attributes to the Accruent service provider.

The exact implementation depends on your directory schema and Shibboleth deployment version.

Use the attribute names listed in the preceding tables. Those values identify the attributes that Accruent expects to receive. They are not intended to serve as copy-and-paste configuration files.

If your environment does not provide eduPersonPrincipalName, release a stable NameID value instead.

The NameID is part of the SAML subject and is not released as a standard SAML attribute.

<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
						[email protected]
						</saml2:NameID>

Release attributes only to the Accruent service provider entity configured for your environment.

Do not rely solely on global attribute release policies when your service provider uses a unique entity ID or connection.

ClosedSAML response validation

Before testing the application, capture a successful SAML response and verify the values listed in this section.

Response-level checks

  • Verify that the response Destination matches the Accruent callback URL for the environment.
  • Verify that the assertion issuer identifies your Shibboleth identity provider.
  • Verify that the IdP signs the response or assertion with the current signing certificate.
  • Verify that the assertion is valid within the configured NotBefore and NotOnOrAfter time window.
  • Verify that the assertion audience matches the Accruent service provider entity ID.

Subject checks

  • Verify that the assertion contains a NameID.
  • Verify that the NameID format is persistent or emailAddress.
  • Verify that the NameID value is stable and non-empty.
  • Verify that the SubjectConfirmationData recipient matches the Accruent callback URL.

Attribute checks

The assertion should contain values similar to the following examples.

<saml2:Subject>
						<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
						[email protected]
						</saml2:NameID>
						</saml2:Subject>
				
<saml2:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6">
						<saml2:AttributeValue>[email protected]</saml2:AttributeValue>
						</saml2:Attribute>
				
<saml2:Attribute Name="urn:oid:0.9.2342.19200300.100.1.3">
						<saml2:AttributeValue>[email protected]</saml2:AttributeValue>
						</saml2:Attribute>

The XML prefixes are not significant. Validate the attribute names and values rather than the prefixes.

ClosedCommon configuration problems

Sign-in succeeds at the IdP but the application cannot find the user

Your identity provider might be sending a transient or changing NameID.

Configure the IdP to send a persistent identifier or a stable email address. The NameID must identify the same user across sign-ins.

Login succeeds but the email claim is empty

Your identity provider might contain the user's email address but may not be releasing it in the SAML assertion.

Release the standard Shibboleth mail attribute:

urn:oid:0.9.2342.19200300.100.1.3

ePPN exists in the directory but is missing from the assertion

The attribute resolver may define eduPersonPrincipalName, but the attribute filter may not release it to the Accruent service provider.

Review both the attribute resolver and attribute filter configurations.

The attribute appears under an unexpected name

The friendly name displayed by Shibboleth tools may differ from the actual SAML attribute name transmitted in the assertion.

Validate the emitted attribute Name value rather than the friendly name.

Given name or surname is empty

These attributes are optional for authentication but recommended for profile population.

Verify that the IdP releases the supported claim URI and that the values are not empty.

ClosedCustomer verification checklist

  • Verify that the Accruent service provider is configured as a SAML 2.0 relying party.
  • Verify that the response sends users to the correct Accruent callback URL.
  • Verify that the assertion audience matches the Accruent service provider entity ID.
  • Verify that the IdP signs the assertion with the current signing certificate.
  • Verify that the NameID format is persistent or emailAddress.
  • Verify that the NameID value is stable and non-empty.
  • Verify that either a stable NameID or eduPersonPrincipalName is available for username resolution.
  • Verify that eduPersonPrincipalName is released as urn:oid:1.3.6.1.4.1.5923.1.1.1.6 when used.
  • Verify that mail is released as urn:oid:0.9.2342.19200300.100.1.3.
  • Verify that given name and surname values are released when profile population is required.
  • Verify the configuration against a real SAML assertion and not only against metadata.

ClosedInformation to include in a Support request

If authentication fails, include the following information when contacting Support.

  • Customer name and environment name.
  • SAML response timestamp.
  • NameID format and a redacted example value.
  • Assertion issuer and audience values.
  • List of emitted attribute names.
  • Application error message and the time it occurred.

Do not include passwords, private keys, session cookies, or other sensitive credentials.

If you provide an assertion for troubleshooting purposes, redact unnecessary personal information while preserving the attribute names and value formats needed for analysis.