Skedda supports the authentication and auto-registration/provisioning of users through Identity Providers with a SAML 2.0 option. Such providers include:

  • Microsoft Azure Active Directory (AD) / Office 365
  • G-Suite
  • Okta
  • ADFS
  • OneLogin
  • (...and many more)

Why should you use SAML 2.0 SSO?

Here are just a few of the reasons:

  • Security: SAML is used to provide a single point of authentication at a secure identity provider, meaning that user credentials never leave the firewall boundary, and then SAML is used to assert the identity to others. This means that applications like Skedda do not need to store or synchronize identities, which in turn ensures that there are fewer places for identities to be breached or stolen.
  • Simplified user management: With employees or team members using multiple applications, it can become a nightmare for IT departments to manage access rights as roles change or as employees leave the company. SAML simplifies this as each user can be managed from a single directory, with access to the relevant applications automatically revoked once they user is removed from that central directory.
  • Improved online experience for end users. SAML enables single sign-on by allowing your users to authenticate once with your identity provider, and then access Skedda as well as all your other service providers without additional authentication. Most identity providers will additionally offer an "Apps dashboard" concept which shows Skedda as a direct app to click on. Here's how the Skedda app looks with G-Suite SAML SSO, for example:

Enabling SAML 2.0 SSO in Skedda

You'll find the SSO-configuration section for your venue account under Settings => SSO / SAML 2.0:

Before you can actually configure SSO on your venue account, we need to go through a few security items and you need to have your subscription upgraded by Skedda support. Please contact our support team to request this (you can do this directly from the settings page shown above as well). Note that this feature involves additional subscription charges (our support team will fill you in on these during the consultation).

Configuring Skedda SSO with your SAML 2.0 Identity Provider

In this section, we'll refer to your Identity Provider with the acronym "IdP".

The configuration process involves sharing some values between Skedda and your IdP. To begin (and once Skedda support has enabled the SSO feature on your Skedda account) head to Settings => SSO / SAML 2.0 and click the button to Add SSO:

This will display a modal that allows you to configure the required information as well as a number of useful options. Each field has an explanation hidden behind a handy question-mark icon.

You'll obtain the three "Required Settings" at the top (Entity ID, Login URL and Certificate Public Key) from your IdP (see concrete examples for the big providers below).

Attribute rules (optional)

The "Attribute Rules" section allows you to control how Skedda grants user tags to your users when they are automatically provisioned during their first SSO login (e.g. when they first come/login to Skedda via SSO). Specifically, you can map attributes coming from your IdP to user tags in Skedda. For example, if your IdP can pass a SAML attribute called "Department" to Skedda, you might like to have users tagged in Skedda according to their department. Here's a concrete example, showing that we're adding the Skedda user tag "Marketing" to newly-provisioned SSO users coming with the SAML attribute "Department" having a value of "Marketing".

Here's an example of how such a "Department" attribute would be set up on Microsoft Azure, for example (Azure uses the term "claims", so the claim name is "Department" and the value passed to Skedda is the user's department, i.e. user.department):

Further optional settings

The "Optional Settings" down the bottom allow you to choose a friendly name for the SSO (e.g. "Log in with Azure AD" or "Log in with YourOrgName"), and to hide other login possibilities from your Skedda account's login page (handy if you want to help prevent your users from using other kinds of logins).

Once you've saved these settings, you'll then see a number of items to configure on the side of your IdP. These items are the Skedda Entity ID, Reply URL (ACS URL), Relay State (see screenshot below, as well as the concrete examples for the big providers at the end of this doc), and the expected attribute/claims mappings. We provide simple "Copy to clipboard" buttons for quickly copying these items over to your IdP.

Important note: We also require that your IdP sends us the standard "Name Id" attribute/claim. The attribute name is specifically called http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier, and the value of this attribute must be the user's unique, static email address. Most IdPs will do this automatically, so we don't mention it on the settings page explicitly (to avoid confusion). If your IdP is one of the few that doesn't send this attribute by default, or if it uses a transient value for it, make sure you explicitly set up this attribute as well on your IdP side, ensuring it sends us the unique, static email address of the user.

After you've configured these items on your IdP, you're good to go!

To assist you with your concrete case, we've included some further details below for the big IdPs. If you need support for another provider, just reach out to our support team!

Did this answer your question?