Single Sign On (SSO) connects your accessplanit platform to your ADFS, SAML, or Azure network to allow your users to log-in using their existing log-in details (such as their Microsoft ADFS 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:
ADFS (Active Directory Federation Services)
Azure AD (Azure Active Directory)
SAML (Security Assertion Markup Language)
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.
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 ADFS or SAML log in details.
Users can be automatically created on the system, if they already exist in the ADFS or SAML network.
Information stored in your accessplanit system will be consistent with the information stored in your central ADFS 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.
What is 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.
Configuration options for ADFS:
The creation or rejection of a new user if the details do not yet exist in Course Manager database but do in ADFS.
The company / department assignment for new users. Users can be assigned to a central company or added to a new or existing company using information from ADFS.
The updating of existing user information in Course Manager based on changes made to information in ADFS.
The IP ranges from which users should be asked to log in through ADFS.
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.
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
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.
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.
For the SSO set-up, we will require metadata from you to connect.
The following claims are used
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.
Below is a list of key questions that are asked of you when setting up Single Sign-On:
Are you planning to use ADFS, SAML, or Azure 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?
The log in process can expose user information from ADFS / SAML / Azure to your accessplanit platform (such as email address and surname). Where possible, would you like this information want to be synced back so essentially when a log in occurs, accessplanit is updated with this user information?
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 accounts 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.