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

Why should you use SAML 2.0 SSO?

Enabling SSO in Skedda

Configuring Skedda with your SAML 2.0 Identity Provider

Instructions for various IdPs

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 the 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 Google Workspace SAML SSO, for example:

Head to Settings > SSO / SAML 2.0

Before you can configure SSO on your venue account, we need to go through a few security items and possibly have your subscription upgraded. Please contact our support team to request this.

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 click the button to '+ Add SSO' in your SSO/SAML 2.0 settings page.

Input the required information in the modal window and select between a few useful options. Each field has an explanation hidden behind a '?' 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 first two 'Optional Settings' 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).

The final optional setting allows you to ensure that Skedda enables cross-session SSO authentication persistence for your Skedda users who sign in via SSO (it's essentially a 'Remember me' function for SSO).

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 "Copy to clipboard" buttons for quickly copying these items over to your IdP.

Please note: We also require that your IdP sends us the standard 'NameId' element within the 'Subject' element, with the identifier in the format of 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 information by default, or if it uses a transient value for it, make sure you explicitly set this up on your IdP side to ensure 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!

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!

If you're having trouble getting SSO to work after setting it up, take a look at our SSO Troubleshooting article.