Single Sign-On Authentication

Degreed supports Single Sign-On (SSO) connections as part of our integrated ecosystem. Beyond supporting SSO for users as they connect to the Degreed app (Degreed as SSO Service Provider (SP)), Degreed also provides the functionality to act as the proxy SSO Identity Provider (IdP) while connecting users to third-party content. Establishing an SSO connection with Degreed acting as the IdP is seen as complementary to a quality content "learning" integration. However, some customers may elect to retain the IdP auth position and the SSO connection can be created or remain intact between the customer and content provider.

Degreed supports IdP-initiated and SP-initiated authorization flows, with SP-initiated flows being "sparked" by SSO-enabled deep links. Degreed uses SAML 2.0 as the basis for its SSO connections and uses a non-federated model where each customer/content-provider connection is configured independently from one another. For additional SSO-related integration information and help with initial setup, please consult with your Degreed technical partner.

Provider Single Sign-On

📘
The following information does not apply to Degreed customers configuring SSO. Contact your Degreed technical partner to configure SSO for Degreed users.

Provider SSO with Degreed only applies when a user clicks on provider content within Degreed, and when Degreed is the selected and configured IdP for that provider within that Degreed customer organization. If Degreed is not the IdP, there is no SSO configuration for that integration with Degreed. In that scenario, if the customer’s IdP is leveraged by your integration, SSO can still occur because Degreed supports deep links as the URL value for content items. Degreed’s IdP service only leverages SAML2.0 as the protocol; no other protocols are supported.

Before You Begin

Before configuring provider SSO for an integration with Degreed, refer to Integration Data Types and Content Integration Concepts to gain a basic understanding of how to create content within a Degreed customer organization. When you create content with your provider credentials, each piece of content contains a URL and SSO deeplinks with various parameters that are supported for that URL.

This concept may sound counter-intuitive if your integration does not provide a “content catalog”. Platform integrations (non-content) that require SSO but don’t offer content items may still require SSO. For that reason, platform integrations may still need to create a small number of “placeholder” content items for users to leverage to initiate the SSO authentication process into your platform from Degreed. In other words, there are no custom “buttons” or “widgets” to represent a way for users to initiate provider SSO. Creating Degreed content items is the only way to start the process.

There is no federated IdP service for Degreed or its data centers. Degreed offers individual IdP metadata per provider record, per customer organization. This means that an integrator should be able to support multiple SP configurations for multiple customers if Degreed is to serve as the IDP, in order to secure and separate customer user connections.

Getting Started

Ensure your global provider record is inserted into the organization. In most enterprise integrations that leverage Degreed IdP SSO, this step requires a Degreed technical partner to insert the record into your organization.

📘
For certain enterprise content integrations, you can configure SSO for the provider in the Degreed UI, but for the majority of integrations, a Degreed technical representative must insert the record into your organization. For more information about in-app integrations, see Configuration Options for Enterprise Integrations.

Ensure that you have created provider content using your API credentials, thereby ensuring that the content is associated with your provider ID. Ensure that the content has a URL that includes parameters that can alert your servers that it’s an SSO request from a user within the Degreed platform. For example, https://www.platform.com/courses/course1?vendor=degreed&customer=X. With this URL, you can create redirects based on the URL parameters that point to the right SP instance.
Request the Degreed IdP metadata for your provider record in that particular customer Degreed organization. You’ll be given a hosted URL that loads the information, rather than an XML or other file.
Provide the SP Metadata that you’ll be configuring against Degreed’s endpoint to your Degreed technical partner.
Make configurations to your SP to receive and process the four claims/attributes that Degreed will always send in the assertion response: First Name, Last Name, Email, and UserID to compare against the user data you maintain in your platform.

How It Works

After completing the steps above, users access your platform through the Degreed IdP Provider SSO. When a user clicks on your provider content within a Degreed organization:

Degreed automation consults the provider record in Degreed and adds a signature/sessionid to the URL.
The SP destination in your platform receives the request, with parameters indicating that it’s a mutual customer from Degreed, and includes our IdP’s signature.
Your SP is configured to bounce that request back to our IdP for authentication.
Degreed’s IdP sees the signature/session ID and replies to your SP with the authentication for the user.
Your platform grants entry to the location the user is meant to access.

The following examples show IdP metadata from Degreed and SP metadata from a potential provider to Degreed’s ecosystem.

Degreed IdP Metadata Sample

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://betatest.degreed.com/DegreedIdP/redacted" ID="_redacted">
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<Reference URI="#_5da7645d-9b09-4d45-a2d2-0939ca2c5acb">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<InclusiveNamespaces xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="#default md saml ds xs xsi"/>
</Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<DigestValue>Q9kPc3sZXvyMhkJYderWbqCfBOAKUKaLrhg1Tpf1JL0=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>redacted</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>redacted</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<md:IDPSSODescriptor ID="_2ac7ea1b-a3d8-4ada-b4c4-473b5471a9b6" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>redacted</X509Certificate>
</X509Data>
</KeyInfo>
<md:EncryptionMethod xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
</md:KeyDescriptor>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://betatest.degreed.com/SAML/IdPSLOService/redacted"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://betatest.degreed.com/SAML/IdPSLOService/redacted"/>
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://betatest.degreed.com/SAML/SSOService/redacted"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://betatest.degreed.com/SAML/SSOService/redacted"/>
<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="UserId" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" FriendlyName="UserId"/>
<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="FirstName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" FriendlyName="FirstName"/>
<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="LastName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" FriendlyName="LastName"/>
<saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="Email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" FriendlyName="Email"/>
</md:IDPSSODescriptor>
<md:Organization>
<md:OrganizationName xml:lang="en">Degreed</md:OrganizationName>
<md:OrganizationDisplayName xml:lang="en">Degreed</md:OrganizationDisplayName>
<md:OrganizationURL xml:lang="en">https://betatest.degreed.com</md:OrganizationURL>
</md:Organization>
<md:ContactPerson contactType="technical">
<md:GivenName>Degreed</md:GivenName>
<md:SurName>SSO</md:SurName>
<md:EmailAddress>[email protected]</md:EmailAddress>
</md:ContactPerson>
</md:EntityDescriptor>

Provider SP Metadata Sample

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" validUntil="2023-10-15T17:37:31Z" cacheDuration="PT604800S" entityID="redacted">
<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://redacted" index="1"/>
</md:SPSSODescriptor>
<md:Organization>
<md:OrganizationName xml:lang="en-US">redacted</md:OrganizationName>
<md:OrganizationDisplayName xml:lang="en-US">redacted</md:OrganizationDisplayName>
<md:OrganizationURL xml:lang="en-US">https://redcated</md:OrganizationURL>
</md:Organization>
<md:ContactPerson contactType="technical">
<md:GivenName>redacted</md:GivenName>
<md:EmailAddress>redacted</md:EmailAddress>
</md:ContactPerson>
</md:EntityDescriptor>