Azure Active Directory SSO Configuration

  • Updated
Follow

Single Sign-On (SSO) can be used to allow logging into external services to authenticate a user's access into aXcelerate. This is useful for organisations that use a single login for multiple services used within their business. The instructions in this article will guide you through the setup of an Azure-based Active Directory for SSO.

 

Tip: There may be some slight differences in your Azure environment from the steps listed in this article depending on the specific variety of Azure you have.

 

Note: Please contact our Customer Success team if you are planning to configure Single-Sign On as there are certain parts of the process that will require assistance from our team.

Provide SSO Configuration details to aXcelerate

The first step in the process is to contact the aXcelerate Customer Success team and let us know that you are planning to configure SSO. You will need to provide:

  • A subdomain to be used to log in to aXcelerate
  • A list of all Email Domains used by your users
  • The type of Active Directory you are using (e.g Azure)

Subdomain

Once all aspects of Single Sign-On have been configured, aXcelerate will be accessible with SSO via a specific subdomain. e.g https://your-subdomain.axcelerate.com

Email Domains

You should provide a list of all email domains that users will be logging in with. In order to support SSO via the Trainer App (and other future projects) we require that a user first enters their email address to identify that the login be directed via your Active Directory. Without this information, login via aXcelerate Apps will not be available.

System Type

SSO can be configured to work with aXcelerate using either Azure AD, EntraID, ADFS, or Octa. This can also work using a connection via openID & SAML.

If you are using a system other than Azure AD for SSO, the steps in this article will not apply to you. This article is specifically oriented for Azure AD. Our team will advise what the next steps should be for your configuration if you are using a different system that is supported.

Add a new SSO Enterprise Application

  1. Log into your Azure Account
  2. Select Enterprise Applications from Azure Services
  3. Within the Enterprise Application area, click Create your own application
  4. Name the application something appropriate (e.g aXcelerate SSO). The name does not matter beyond identification within Azure.
  5. Select the Integrate any other application option

Select the Enterprise Applications Area

Create a New Enterprise Application

Application Details

Set up the Enterprise Application for SSO

After you have logged into Azure and added a new Enterprise Application, you can set up the application to be compatible for SSO with aXcelerate.

  1. Select your Enterprise Application
  2. Select the Set up single sign-on option, or click on the Single sign-on menu item.
  3. Select the SAML option on the next page.
  4. Once in the SAML area, Edit the Basic SAML Configuration section
  5. You will have been provided with an identifier starting with “urn” and a reply URL. You will need to specify these values here, in the Identifier (Entity ID) field, and the Reply URL field. Enter the full text of the provided values here. If you do not have these, let your aXcelerate SSO contact know and they can be provided to you.

Set up single sign on

Edit Basic SAML Configuration

Enter the Entity ID and Reply URL

Setting up SSO User Roles / Group assignment

You are able to control the role of users within aXcelerate via Active Directory groups. This requires an additional claim rule to be added to the claims currently sent through.

  1. From the SAML Configuration page, Edit the User Attributes and Claims rules.
  2. Add a new Group Claim
  3. The groups returned under the claim can be set to a few options, we typically recommend Groups assigned to the application. This setting reduces the number of groups that are sent through to aXcelerate, as there can be users who have too many groups which in turn breaks the role provisioning.
  4. Customise the name of the group claim and set the name to http://schemas.xmlsoap.org/claims/Group. If this is not set the configuration will not work properly.
  5. Set the Source Attribute to the groupID
  6. Click Save
 

Tip: If you are familiar with writing custom claim rules, you could also customize the group claim as long as the output is in a similar format. This is not recommended without experience with custom SAML claims.

 

Note: You do not need to use roles via Active Directory, but you will still need to grant access to the Enterprise Application to groups to let them log in to aXcelerate.

Edit User Attributes & Claims

Add new Group Claim

Configure Group Claim

Configure SSO User and Group Access

In order for the application to be available for SSO for users, they will first need to be granted access to it. As mentioned in the previous section, it is recommended to assign groups to the application to control access as well as to control which groups are sent through to aXcelerate.

  1. Return to the main screen of your Enterprise Application
  2. Select the Users and Groups menu option, or the Assign users and groups option from the Enterprise Application.
  3. Search for your group name and assign them.
  4. Select the Users option under Add Assignment
 

Tip: If you have not yet set up groups for access to aXcelerate, it is recommended that new groups are created to not conflict with existing processes.

 

Note: Some setups will not be available here depending on Azure settings / Account type. Typically Security Groups will be listed and available, but some configurations done via Microsoft 365 may not be available.

Assign users and groups

Add user/group

Set SSO Group Identifiers

For the next section, you will need the identifiers from any groups in aXcelerate that were set up for linking to User Roles.

  1. These can be found in your Active Directory under the Groups section within Azure
  2. Within each group is an Object Id. Record these identifiers to match the roles between the group and the role in aXcelerate.

Record the Object ID

Provide SSO Federation Metadata

The last remaining step in Azure is to download or get the URL for the Federation Metadata file.

  1. From your Enterprise Application, Select the Single sign-on menu option
  2. Locate the SAML Signing Certificate section. Here you will find the XML File link as well as the Metadata URL. Either of these will be required for aXcelerate to be able to access and validate the claims.
  3. Send through the XML File link or Metadata URL to your aXcelerate SSO contact.

Copy the XML File link or Metadata URL

Manage aXcelerate User Roles for SSO

In aXcelerate, if you are intending to control roles via Active Directory, you will need to set up User Roles that correspond to the groups being used.

  1. Go to the System Users via the Settings menu
  2. Select Manage User Roles
  3. Here you will be able to add new roles, and - if your account has been flagged for SSO - be able to associate group identifiers with the roles.
 

Note: If you do not see a field called 'SSO ID' against the User Role, the account has not yet been flagged for SSO. Ensure that the steps in Active Directory/Azure have been completed and that you have sent through your Federation Metadata File/URL to your aXcelerate contact.

Managing SP-Initiated Login from External Portals

aXcelerate only supports Service Provider (SP) initiated authentication flows, meaning that the login process must start from our platform’s login page. In this flow, users are redirected to their Identity Provider (IdP) for authentication after attempting to access aXcelerate. Once authenticated by the IdP, they are returned to aXcelerate to complete the login process. As a result, Identity Provider initiated flows, where login starts directly from the IdP, are not supported in our system.

To streamline the login process, you can technically launch from your own portal by directing users to the following URL: https://{yoursubdomain}.{environment}.axcelerate.com/auth/user/login.cfm?provider={PROVIDERNAME}. This will automatically select the login option that matches the specified Identity Provider, bypassing the need for users to see the aXcelerate login screen. The 'yoursubdomain' will be provided by aXcelerate, and PROVIDERNAME will be supplied once the setup is complete on aXcelerate's side. Use 'stg' for the Staging environment or 'app' for the Production environment in the URL.

Azure AD SSO FAQs

Q.

Why has a new aXcelerate user been created for me on login?

A.

If your details in your Active Directory do not match those in aXcelerate, your user account may not initially be linked. In this scenario, a new aXcelerate user account would be generated.

Q.

Why does my name keep changing in aXcelerate on login

A.

This will no longer be an issue as AD will no longer update names or email addresses of the linked users on login. ‍

Q.

Why is my role stuck at a lower level (trainer / student) when I've been assigned a higher level group/role?

A.

If you end up with the wrong role, you may have been assigned 2 roles in your Active Directory. It is important to remove the lower role in AD to ensure the correct role is used.

Q.

How are existing users affected when I enable SSO?

A.

There is a strict matching criteria of givenname, surname and email address. It is imperative that a user's details in aXcelerate exactly match the corresponding record in your IDP. Commonly, abbreviated names such as "Steve" instead of "Steven" will cause duplicated contacts.
If this occurs, you will have to merge the two contacts. To do this, you must first set both contact records to exactly match the IDP details, then disable (or set to student role) the user NOT linked to the IDP, and finally, merge the contacts. When that user logs in from the IDP the next time, the issue will be resolved.

Related articles