Prerequisites

Enabling Single Sign On is a technical task that requires a Systems/Identity Administrator with appropriate access at your end for configuration of your systems. You will need to have a SAML 2 compatible Identity Provider service. 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:

1. Configuring Skills Base
2. 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)
• Okta
• OneLogin
• 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 and last names). Skills Base will use this email address to match a person in the system. If there is no match, you can choose to either reject that login or to create a new person with that email address (providing you have enough capacity in your license and have the Automatic User Account Provisioning feature enabled).

How Security Groups are assigned

All new people are assigned the default Security Group that has been configured for your instance (in [Administration > 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 or importing 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 [Administration > Settings > Default entities].  Some entities permit "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.

Note about 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 [Administration > 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

See: People Administration

SP vs IdP-initiated sign-in

Skills Base supports SP-initiated sign-in only.  Skills Base does not support IdP-initiated sign-in. As such, users always need to use your organization's Skills Base shortcut link to initiate a sign on.

For organizations that make use of integrated portals, add your Skills Base shortcut link to invoke SP-initiated sign-in instead of using your IdP-initiated sign on link.

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.  If you have Automatic User Account Provisioning enabled a new user account will be created for them in the system. As such, you will end up with two people with the same name but different emails, 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. If you have Automatic User Account Provisioning enabled Skills Base will create a new account with the new email address. You will end up with two people with the same name but different emails, and it is not possible to merge these accounts.  Under these circumstances 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.

Synchronizing people attributes via SSO

You can use the SSO integration to synchronize some people attributes in Skills Base with your corporate user directory. attributes that can be synchronized via the SSO integration are:

• First name
• Last name
• Team
• Role
• Location
• Custom Fields

SSO attribute synchronization is enabled and configured by Skills Base Support staff. It is not possible for customers to enable or configure SSO attribute synchronization. In order for Skills Base Support staff to enable synchronization it is first necessary to configure your SSO Identity Provider to send Skills Base the desired additional attributes via the SAML assertion.  At minimum an SSO integration is configured to send the mandatory attributes: Email, First name, and Last name.  Any additional attributes should be provided in the SAML assertion the same way those mandatory attributes are provided.

Once the additional attributes are configured and being sent to Skills Base, and at least one person from the organization has successfully logged into Skills Base via SSO with that new configuration in place, Skills Base Support staff will be able to map the attributes you provided to the desired Skills Base person record fields.

Creating non-existent related entities

Another key decision is whether Skills Base should create non-existent related entities for the following specific attributes:

• Team
• Role

That is, if a Team name is specified in the SAML attribute which does not match any existing team in Skills Base, should Skills Base create the team and place the person into it?  The same applies for non-existent roles. There are some considerations in the decision to create non-existent related entities:

1. Teams and roles that are created will have no skills assigned by default.  Therefore, if people's "Skill set" defaults to "Use team skills" or "Use role skills" and the team or role doesn't exist and needs to be created at the time of login, that person will not be able to complete an assessment until some skills are assigned to their role/team.
2. New teams will be created at the root of the Teams hierarchy.  This means the team will be isolated, and will contain only one person initially. Depending on the privileges granted to the person's Security Group, the person may not have the necessary access to list/view/edit/assess other people.

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)
• Any Skills Base SSO settings change (for example expiration of the Skills Base SP certificate)

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.

The steps required to update SSO configuration are essentially a subset of the steps that you followed when initially setting up SSO:

1. Ensure you have access to a local Administrator account. This is an account where the password is stored in Skills Base.
2. Make the required changes to your IdP (eg: install new certificates).
3. Download your IdP's new metadata file.
4. Using the metadata file, add a new IdP to Skills Base via the [Administration > Authentication] menu
5. Enable the new IdP in Skills Base when you are ready to make the switch
6. After the new configuration is proven to be working, deprovision the old IdP configuration in both Skills Base and your IdP

Migrating to another region or a new environment

When an organization chooses to have a new environment created or chooses to have their environment migrated (moved) from one region to another such as from North America to Australia, a new SSO configuration will be required. The set up required is the same as previously performed for a new SSO configuration. 

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:

http://app.skills-base.com/o/demo/local

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.