You must be within the Advanced band or higher to use SSO as this is a chargeable module/integration. Please speak to your CSM if you are unsure whether you should have access to this feature.
You also must use ADFS (Active Directory Federation Services), Azure AD (Azure Active Directory), or 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 (AD FS) 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 AD FS, 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.
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 any SSO set up?
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 to accessplanit such as, email, surname, etc. 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?
Do you need to support logins from people outside of your network?
If yes, we’ll need to differentiate an internal user from an external user. Do all your internal users use the internet from behind a fixed IP address/range? If everyone in the office searched Google for “what’s my IP address” would they all see the same result? Do internal users that work from home use a VPN to connect to the office or would they be using accessplanit from their own IP address?
Does every internal user have a unique email address? accessplanit will need something unique back from the SSO service so that it can associate the login within a single accessplanit 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.