Skip to end of metadata
Go to start of metadata

Last Updated: Tuesday, November 5, 2019

Vibes exposes a SAML 2.0 Service Provider that aims to implement the Service Provider Lite profile. Assuming you are familiar with the SAML 2.0 protocol, you can find more details in the following sections.

The Vibes SAML Service Provider

  • The metadata endpoint for Vibes SAML Service Provider is:<customer_federation_id>/metadata. The metadata is signed.
  • The entityID Vibes uses is<customer_federation_id>.
  • The identifier Vibes expects back is the email address of the user, for example: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress. If your users don't have a unique email address, contact your Vibes account manager to discuss a custom solution.

Supported Features

  • Web SSO:
    • AuthnRequest - HTTP Redirect Binding.
    • AuthnRequest - HTTP POST Binding.
    • SAML Assertion - HTTP POST Binding.
  • XML Signatures:
    • Metadata XML.
    • AuthnRequests.
    • SAML Assertions.
  • Encrypted Elements:
    • Vibes supports encrypted elements in SAML Assertions.

User Timeouts

Vibes' user timeout period is 24 hours of inactivity. After 24 hours of inactivity, Vibes will re-authenticate with the customer's identity provider. 

Additional Validations and Restrictions

Only users that are configured for third-party authentication will be accepted from the customer identity provider. Other users will receive an invalid authorization error.

Setting up SAML integration

To get set up your SAML integration, please provide Vibes with the following:

  • The metadata endpoint for your SAML IdP. For example:
  • Optionally, the fingerprint of your signing certificate if you would like Vibes to verify it independent of the certificate or fingerprint provided in your IdP's metadata.

Once setup has been completed on Vibes' side, Vibes will direct users coming to your white label domain to be authenticated through your IdP.

  • No labels


  1. Open Questions

    • Is a self signed certificate good enough, or do we need to get one signed by our CA?
    • Is the wild card SSL cert we use for our SSL communications good enough, or should we really have one for
    • The supported and unsupported features lists are based on available libraries used to process the SAML requests and responses. Do we need to support any of the unsupported features?
  2. Unknown User (dean.lappi)

    I removed the following information until they are supported. Customer documentation should not have this type of info.

    Features That Are Planned, But Not Yet Supported

    • Web SSO:
      • AuthnRequest - HTTP Artifact Binding.
      • SAML Assertion - HTTP Artifact Binding.
    • Single Logout:
      • IdP Initiated - HTTP Redirect Binding.
      • SP Initiated - HTTP Redirect Binding.
      • IdP Initiated - SOAP Binding.
      • SP Initiated - SOAP Binding.
    • Artifact Resolution for SSO - to support SOAP and Artifact Bindings.
  3. Unknown User (dean.lappi)

    Removed the following two sentences, Per Matt and Steven.

    • Any Vibes Global Authorization roles that are granted to the user will be ignored for third-party Authenticated users.
    • The user's Company context and allowable companies will be limited to Parent/Children of the main account associated with the white label domain. This applies to all user accounts that have accessed the Platform via the white label domain, regardless of whether they authenticated locally or via third-party, as well as whether they have the ACCESS_ALL_COMPANIES role or not.