Single Sign-On

Owned by Alice Pearson
Last updated: 23 Aug, 2023 by Jenna Buttershaw
6 min read

Search for a solution
 

Single Sign On (SSO) connects your accessplanit platform to your SAML, or Azure network to allow your users to log-in using their existing log-in details (such as their Microsoft Azure details) instead of their accessplanit username and password.

As your users do not need to remember another set of log-in details, they are less likely to be locked out of their account, and they have a much more streamlined log-in process.

 

SSO is a chargeable module/integration, please speak to your CSM if you are interested in this module.

To use the SSO module, you also must use one of the following networks:

  • SAML (Security Assertion Markup Language)

  • Azure AD (Azure Active Directory) - with SAML

What is Single Sign On (SSO)? 

SSO works based upon a trust relationship set up between an application, known as the service provider, and an identity provider, like SAML 2.0 and OAuth2. This trust relationship is often based upon a certificate that is exchanged between the identity provider and the service provider. This certificate can be used to sign identity information that is being sent from the identity provider to the service provider so that the service provider knows it is coming from a trusted source. In SSO, this identity data takes the form of tokens which contain identifying bits of information about the user like a user’s email address or a username.

Benefits

  • Single Sign On (SSO) means that your system users do not need a separate accessplanit user ID or password to access the system, they can instead use their Azure or SAML log in details.

  • Users can be automatically created on the system, if they already exist in the Azure or SAML network.

  • Information stored in your accessplanit system will be consistent with the information stored in your central Azure or SAML network.

What is SAML?

SAML is an acronym used to describe the Security Assertion Markup Language (SAML). Its primary role in online security is that it enables you to access multiple web applications using one set of login credentials. It works by passing authentication information in a particular format between two parties, usually an identity provider (idP) and a web application.

Please note: 2FA (Two-Factor Authentication) may be available to you as an additional security layer, if you use Azure alongside SAML for your Single Sign-On

How does accessplanit’s SSO work?

SSO vs the standard login page

If you would like some of your users to login using SSO, and other users to login using the standard accessplanit log-in page using their accessplanit login details, you will need to choose how the SSO will be enabled. This would apply if, for example, you would like all of your administrator users to login using SSO, but you would like your trainers and learners to login using their email address and password.

SSO can either be configured to apply based on the IP Addresses of your users, or based on the URL that they choose to access the platform.

  1. If you choose to take the IP Address route, please provide us with the IP Addresses or range for the users who will login into your accessplanit platform via the SSO

  2. If you choose to take the URL route, accessplanit will create a new page for you to direct your SSO users to which will redirect to your SSO login page.

Security

For the SSO set-up, we will require a x.509 certificate to secure the responses sent from your idP.

We will also require you to permit authorisation requests from the identify provider for a selection of URLs to cover the test, sandbox, and live environments.

Metadata

For the SSO set-up, we will require metadata from you to connect.

You may need to provide different metadata for

  • The Test environment for your accessplanit platform

  • Your Sandbox environment for your accessplanit platform (if you are in implementation or have purchased the Sandbox module)

  • Your Live environment for your accessplanit platform

Metadata file requirements

  • The metadata file should include an x.509 certificate for use by accessplanit’s SAML code to secure the SAML responses sent from your idP to accessplanit.

  • The metadata file should not include an expiry date.

If you require an Entity ID, Reply URL, Sign on URL, and/or Logout URL, please get in touch with a member of the accessplanit team to share this with you.

Claims

The following claims are used

Field

Attribute

Claim

First Name

first_name

givenname

Last Name

last_name

surname

Email Address

User.email

emailaddress

Login Process

As service provider, accessplanit will generate an authorisation request token and use redirect binding to direct the user to your idP.

Assuming successful login by the user at the identity provider side and validation of the response, an existing user in the accessplanit database will be identified using the user’s email address received.

 

Key questions

Below is a list of key questions that are asked of you when setting up Single Sign-On:

  • Are you planning to use SAML, or Azure (with SAML) for Single Sign On?

  • Which version of your chosen service do you have installed and do you have any future plans to upgrade it? If so, when and what to? Any change in setup after this work has been commissioned may result in further charges.

  • Do you currently have SSO set up within your business using your chosen network?

  • If so, does your current SSO set up utilise Federation Services?

    • If yes, is it hosted on your network?

  • Would you like every user (administrators, managers, trainers, learners) to access your accessplanit platform through the SSO?

  • If not, would you like SSO users to access your accessplanit platform using a dedicated URL or through a redirect based on their IP Address?

  • Does every internal user have a unique email address? accessplanit uses email address as a unique identifier for users to associate the login within a single accessplanit user account.

  • Should accessplanit create users on the fly, for instance if a login occurs for an account that exists in the SSO service but not in accessplanit?

    • If yes - the first name, last name and email address must be captured, accessplanit will also need to know which account (company/department) to assign new users to within the platform.

    • If yes - please let us know which Account new Users should be added into, this is typically the Guest Account.

    • If no - please let us know what message you would like us to display when a user attempts to login and there are no matches found for their user in your accessplanit platform

      • Example text: We were unable to find a match for your account, please try again or contact us at [insert phone number, email address, or service desk link]

  • Please let us know what message you would like us to display when a user attempts to login and there are multiple matches found for them in your accessplanit platform

    • Example text: We were unable to find a unique match for your account, please try again or contact us at [insert phone number, email address, or service desk link]

 

Troubleshooting

If you are having any issues using your SSO, please take a look though the below to see if any of these solve your issues:

  1. When my users log in via SSO, their name and email address are not populating in my accessplanit platform
    Please check that you are using the correct claims! These are listed higher up in the guide within the “How does accessplanit’s SSO work?” section.

  2. When new users are created in accessplanit through the SSO, they are being added into the wrong Account
    Please let a member of the team at accessplanit know which Account you would like new Users to be added into and they can update this for you.

  3. When someone tries to login via SSO, they are seeing a 404 error page
    Please check the URLs that are included in your SSO process are all correct and exist:

    1. The Logout Service URL in your metadata file should not point to an accessplanit page

    2. The Sign on Service URL in your metadata file should not point to an accessplanit page

    3. When a user is directed to your SSO, ensure that the page and service is active

ADFS

ADFS is no longer supported as an off-the-shelf SSO option with accessplanit.

If you would like to integrate your accessplanit platform with an ADFS solution, please get in touch with your Customer Success Manager and we will arrange a call with you to discuss your requirements and the cost to implement support for you.

About ADFS

Active Directory Federation Services (ADFS) is the claim-based single sign-on (SSO) solution provided by Microsoft. It facilitates access to all integrated applications and systems with just your Active Directory (AD) credentials. To use ADFS, run it on Windows Server after installing the role in Server Manager. It is part of AD services.

Requirements for ADFS:

  • ADFS 2.0 or above.

  • Permission to configure the ADFS implementation.

  • Permission to configure the firewall for the ADFS host server.

  • The address of the ADFS server.

  • Credentials for a test account that can be used during implementation.