Security Assertion Markup Language (SAML) single sign-on (SSO) can be set up by developer(s) or IT personnel in the Admin app after you've enabled the SAML Integration feature on the Features page. The developer or IT personnel will configure the SAML settings, including service provider (SP), identity provider (IdP), and any attributes.


This article provides configuration details for the Widen Collective to act as an SP, or relying party, for a SAML version 2.0-compliant identity server.

Refer to the SAML SSO Configuration for ADFS article for technical details about configuring a SAML SSO for ADFS.

 

Common terms

The following are terms and definitions for those terms.


Term
Definition
Service provider
Server or application that is requesting authentication for a user
Identity provider
Server that is capable of performing authentication
Metadata
XML documents that describe capabilities and specific details for SP or IdP servers

Implemented capabilities

The Collective will redirect unauthenticated users to your IP server to be authorized. After successful authentication, users are redirected back to the Collective to start using the application.

In more technical terms, the Collective uses the SAML web browser SSO profile that:

  • Is initiated by an SP
  • Uses a redirect binding to the IdP
  • Uses a POST binding for the consumer assertion service


Binding is described in section 5.1.2 on pages 26 to 30 of the standards SAML technical document on the Oasis Foundation website.

Best practices are described on the InteroperableSAML 2.0 website.

 

Service provider configuration

To complete the SP configuration, the following information is required from your SP server:

  • Issuer/entity ID
  • Name ID format
  • A registration code

The following SP information can also be entered:
  • SP metadata
  • An SP-initiated URL
  • A logout redirect URL
  • Assertion consumer service URLs

Metadata import

Collective SP metadata is available directly from our application at https://{name}.widencollective.com/saml2/metadata.


If you're unable to import SP metadata from a URL, your Widen customer experience manager can supply an XML document.


Manual configuration

The SP metadata file includes the information below. You can skip this configuration if your IdP supports SP metadata import.


Issuer/entity ID
https://{name}.widencollective.com
Assertion consumer service URL
POST binding
https://{name}.widencollective.com/saml2/auth

Single logout service redirect URL

REDIRECT binding
https://{name}.widencollective.com/saml2/logout

Name ID format
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
Help Desk Support
support@widen.com

Identity provider configuration

To complete the IdP configuration, this information is required from your IdP server:

  • HTTPS service authorization endpoint
  • Metadata endpoint
  • Certificate files
  • A support email address users can contact if they have issues authenticating into your system


Attributes configuration

Returned attributes should use the given name listed in the table below. Email address and first and last name are required attributes, but the others listed can be included. The friendly name is the user interface value displayed in ADFS.


Field Name
 
Email address*
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
First name*
 http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
Last name*
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
Title
http://www.widen.com/saml2/claims/title
Department
http://www.widen.com/saml2/claims/department
Company
http://www.widen.com/saml2/claims/company
Phone
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/otherphone
Street Address
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/streetaddress
City
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality
State/Province
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/stateorprovince
ZIP/Postal Code
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/postalcode
Country
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country
Roles
http://schemas.microsoft.com/ws/2008/06/identity/claims/role
Passcode
http://www.widen.com/saml2/claims/passcode
*Required field
 


Send user roles via claims

When SAML is used for authentication, users can be assigned roles in the active directory that specifies the access they have in the Collective. We accept a group of user authorization roles using the attribute name listed in the table above. Each time a user is authenticated via SAML SSO, the Collective performs these actions:

  • SAML role names are compared to Collective role names. SAML role names that match are considered valid and are used for further processing.

  • If there are no valid roles, the user’s Collective role assignments are left as is. (A Collective configuration point, defaulted to zero, stops the login process if a minimum number of roles is not matched.)

  • If there are more than one valid, the user’s Collective role assignments are updated to match the SAML roles. This may involve adding and/or removing some roles for the user.