In Structural, Admins have the ability to set up Single Sign-On directly through the Admin Panel. This ensures employees will have a more secure and efficient login experience. Also, it allows the company's IT team to be the source of truth when login issues occur.

You can watch this video below or follow the step-by-step instructions to set up Azure SSO for your team.

The tutorial is based on our Legacy Structural platform being used), but the concepts are still relevant & helpful. The step-by-step instructions below are current.

To setup Azure Single Sign-On follow these steps:

*Sign-in for customers is configured within the app.structural.com admin interface.

  1. Visit https://app.structural.com/admin

  2. Select the "Single Sign-On" menu item on the left sidebar.

Here, you can review configured sign-in providers, remove them, and configure new providers. To configure a new provider with Azure Active Directory:

  1. Select ‘New Provider’ at the top of the page

  2. Select ‘SAML 2.0' among the list of SSO connections.

  3. Select ‘Azure Active Directory’ among the list of identity providers.

Below the options you’ve selected within the right drawer, you should see a Sign-On URL presented within a grey box.

  1. Copy this URL to your clipboard

  2. Head over to your Azure Active Directory administrative panel, usually located at https://portal.azure.com/

  3. Select the ‘App Registrations’ menu item

  4. Select the ‘New Application Registration’ item at the top.

  1. Name the application whatever you'd like; just "Structural" should work great

  2. The Application type should be left as ‘Web App / API

  3. Paste the URL copied from the admin page into the field labeled "Sign-on URL"

  4. Click "Create"

You should land on the application registration page for the new Application.

  1. Copy the Application ID at the top of this page to your clipboard.

  2. Paste that into the Issuer field on the Structural admin portal.

Next, back in the Azure admin portal, exit out of the Application Registration page to return to the App Registration Page, then click Endpoints at the top.

Copy the URL in the Federation Metadata Document field, then insert that into the Federation Metadata URL field on the Structural admin portal.

  • Finally, click Add Provider.

  • Adding a Provider will not immediately present an SSO button to your Structural users for sign-in; this allows you to configure a provider, submit it, and roll it out to your users when you are ready.

  • When you are ready for your users to see the SSO button for Azure Active Directory, simply select the ‘Make Primary’ button on the Azure Active Directory provider in the list of providers.

  • Email & Password is always available as an option for sign-in, and cannot be disabled globally. Password sign-in can be reset or disabled for individual users, should a tenant administrator desire.

  • Only one non-Email & Password sign-in option can be configured and presented as the primary SSO provider for a Structural tenant, at this time.

Federation Metadata Syncing

Structural will automatically sync the federation metadata document provided during the SSO setup process on a regular basis (roughly every hour). This will ensure that any certificate rotations and sign-on URL changes are recognized automatically by our application.

Matching ADFS Users to Structural Users

If a user attempts to sign in to Structural via SSO and does not already have a Structural user account, Structural will not create one for them. All users must already have a user account provisioned for them, whether via a User Sync, CSV Import, or manually by an administrator.

When receiving a SAML assertion during a sign-in attempt, Structural inspects the following fields within the assertion for an email address:

  • EmailAddress

  • NameID

Then attempts to exactly match the value within that field to an email address for a user within your Tenant by matching against:

  • Primary Email Address (sometimes called “Work Email Address”)

  • Personal Email Address

If no match is found, or if no email address is provided in the signed SAML Assertion provided to Structural during sign-in, the sign-in attempt will be rejected.

Clock Skew

Structural allows for a clock skew of 60 seconds between our servers and your Azure AD server; if a NotBefore time is specified in the sign-in assertion less-than 60 seconds in the future, the sign-in should proceed normally. Anything beyond 60 seconds will fail.

Assertion Encryption

Structural does not support encrypted SAML assertions at this time.

Still Have Questions?

Did this answer your question?