Single Sign On
Single Sign On
Single Sign On (SSO) is available to paid license holders and allows you to use your organization's on-premise Identity Provider (IdP) service to authenticate users. This means your employees don't have to maintain/remember separate login details for Skills Base and will securely log in using their organizational username and password. The username and password is never sent to or even known by Skills Base. Single Sign On also removes the need for you to invite or manually add people to Skills Base as accounts are automatically created upon initial login.
Enabling Single Sign On is a technical task that requires a Systems Administrator at your end for configuration of your systems. You will need to have a SAML 2 compatible Identity Provider service set up that is exposed to the Internet. If you have already enabled SAML2-based Single Sign On integration with other Cloud solutions, adding Skills Base should be straightforward.
Configuring Single Sign On
There are two parts to enabling Single Sign On:
- Configuring Skills Base
- Configuring your on-premise Identity Provider (IdP)
At present, we provide full instructions for configuring the following Identity Providers (IdPs):
- Active Directory Federation Services 2.0 (ADFS 2.0)
- Active Directory Federation Services 2016 (ADFS 2016)
- Google G Suite
- Microsoft Azure AD
If yours is not listed the steps may be similar to one of the above or you may try our general instructions for All other IdPs.
How sign in and account creation works
Skills Base uses email addresses as the primary way of identifying a person. When a user signs into your IdP, your IdP will send the user's email address to Skills Base (as well as their first name and surname). Skills Base will use this email address to match a person in the system. If there is no match, Skills Base will create a new person with that email address (providing you have enough capacity in your license).
How Security Groups are assigned
All new people are assigned the default Security Group that has been configured for your instance (in Admin > Settings > Default entities). An Administrator can later change a person's Security Group by:
- Manually assigning a desired Security Group by editing the person's record after it has been created by the Single Sign On process.
- Creating a user account with a matching email before the user signs in via SSO for the first time and assigning the account the desired Security Group. Note that the email must exactly match the email stored in the IdP.
How other entities are assigned
Entities such as Team, Role, Location and Skill Set are assigned based on the defaults that have been configured in Admin > Settings > Default entities.
Some entities allow "Let the person choose" to be selected in which case new people will be prompted to choose upon first login. If their entity does not appear in the list, they can select the option "My [entity] doesn't appear" and as a result they will not be assigned anything for the given entity.
Letting the person choose their own team
Although the "Let the person choose" option is available for the Team entity to allow people to choose their own team upon account creation, please note that this may be undesirable in some circumstances as Teams can be used to control permissions. As such, if you allow people to choose their own team, be aware that you may also be granting them the power to choose which people their granted permissions will be applied to.
This is due to the fact that Security Group permissions granted with "Delegated" scope apply based on the team the person is placed into. To provide administrators with some control over this, Skills Base provides the ability to filter the list of teams that are selectable by people upon creating their account if "Let the person choose" is selected as the default team in Admin > Settings > Default entities. To filter in/out a team from user selection:
- Navigate to the "Edit" or "Add" screen for a team
- Set the "User selectable" field to "Yes" to allow the team to be selected by users, or "No" to prevent users from selecting it.
User account types
Notes about your Identity Providers clock
It is critical that the clock on your Identity Provider server is accurate and is synchronized to an external time server using the NTP protocol. The reason being is that the SAML protocol encodes timestamps into its communications and these are validated by the receiving server to ensure they have not expired. Whilst a small buffer is built in, too great a drift in a server's clock will cause Single Sign On to break and you will receive error messages such as the following:
- "Received an assertion that is valid in the future. Check clock synchronization on IdP and SP."
- "Received an assertion that has expired. Check clock synchronization on IdP and SP."
- "Received an assertion with a session that has expired. Check clock synchronization on IdP and SP."
To avoid these, always ensure that your Identity Provider server's clock is accurate and synchronized to an external time server using the NTP protocol.
Single Sign On and email addresses
As Skills Base relies on email addresses as the primary way of identifying a person, you should be aware of the implications of changing a person's email address either within Skills Base or within your IdP:
- If you change a person's email address at your IdP, the next time that person signs in to Skills Base their account won't be found and a new user will be created in the system. You will end up with two people with the same name and there is no way to merge these accounts. Under these circumstances, you should delete the newly created account in Skills Base and update the existing account to reflect the new email address. Next time the user logs in via your IdP they will be connected with their old account.
- If you change a person's email address within Skills Base, next time they log in via your IdP Skills Base will be unable to match the email address and will create a new account with the new email address. You will end up with two people with the same name in Skills Base. It is not possible to merge these accounts and so you should delete the newly created account and either revert the email address in Skills Base back to reflect the IdP, or update your IdP with the users new email address.
Updating Single Sign On Configuration
Circumstances where updating SSO configuration may be necessary
It may be necessary to update your Single Sign On Configuration if:
- You update any of the certificates on your IdP
- Any other settings change on your IdP (eg: URL)
The most common event is the first bullet point as certificates generally expire after 1 year. Skills Base tracks the expiry date of your certificates and sends administrators within your organization an email when certificates are approaching expiry (30 days before the expiry date).
Updating SSO configuration
We provide comprehensive instructions for Updating AD FS configuration. For all other IdPs, the general procedure is provided below.
Note: Updating SSO configuration requires a brief outage of SSO services (ie: People will not be able to log in for a short time), so conduct this process during a suitable maintenance period.
The steps required to update SSO configuration are essentially a subset of the steps that you followed when initially setting up SSO:
- Schedule a suitable period of downtime as this process will cause a temporary outage to Single Sign On services.
- Ensure you have access to a local Administrator account. This is an account where the password is stored in Skills Base.
- Make the required changes to your IdP (eg: install new certificates). Note that once this step has been completed Single Sign On services will cease operating.
- Download your IdP's new metadata file.
- Copy and paste the contents of the metadata file into Skills Base (Admin > Authentication > Update IdP metadata)
- Click Save. Once this step is complete, Single Sign On services should be restored.
Please test to ensure the new configuration is working and that you are able to log in via SSO.
If you become locked out or you want to log in using a local account
If you find you have become locked out of your instance due to a misconfiguration of Single Sign On, or you want to log in using a local Skills Base account for any reason, simply append "/local" to the end of your shortcut link. For example:
Then, on the login form that is presented click "Use local login" and log in using your local Skills Base account. Note that the above link will only work if you are logged out, so if you are currently logged into the system you will need to firstly log out.