Single Sign-On (SSO) is a method of user authentication (logging in) that adds security to the login process and makes onboarding new employees and software easy. Instead of employees being expected to keep track of multiple logins, they can log in to any number of service providers (such as 15Five) through a single login profile using SSO.
What you’ll find in this article:
- How to set up SSO
- How to test your SSO configuration
- How to manage SSO settings
- How to disconnect SSO
- Troubleshooting, FAQs, and errors
Set up SSO
In this section, we will go through the steps to set up SSO with 15Five. While you're setting up and testing SSO we suggest enabling the 'Allow Password Sign In' option in your SSO configuration settings in 15Five. Doing so will allow people to access 15Five via their email and password, rather than strictly SSO.
What you need for your Identity Provider (IdP) to setup SSO (SAML 2.0) 15Five:
- Your XML Metadata
- 15Five Metadata URL/Entity ID: https://<your subdomain>.15five.com/saml2/metadata/
- 15Five ACS URL: https://<your subdomain>.15five.com/saml2/acs/
- 15Five Service URL: https://<your subdomain>.15five.com/
Set up SSO in 15Five
- Navigate to the ’SAML Single Sign-On’ page in 15Five. If you don’t have access to that page, contact support@15Five.com and we can work on adding that for you.
- Set your company's subdomain—typically this will be your company name or some form of it. You can choose anything they want as long as it does not contain characters, capital letters, or spaces. The subdomain name needs to also be a unique name—no other company can be using the same domain. Click Save.
- You will be taken to the next page to enter the Metadata from your IdP and set your SSO contact.
- The 'Contact email' should be the email of the IT point of contact that 15Five Support or others in your company should reach out to about SSO-related questions or issues.
- Check the box labeled ‘Automatically update metadata' if you’d like to include the link to where 15Five can check your metadata. Doing so will allow 15Five to automatically update your metadata if changes are made, rather than updating the metadata manually. Click Save.
- Next, you will set your SAML attributes and settings.
- SAML Single Sign-On Enabled: Should be checked to enable SSO.
- Allow Password Sign In: Can be checked if you want their users to have the ability to log in using their email and password, rather than just through SSO. This can be turned on during testing and turned off after if preferred.
- Allow Identity Provider Initiated Login: A setting that allows employees to log in directly from the app dashboard when they log in via your company’s IdP.
- Allow Auto Login: Indicates that the employee will be auto-logged in using their IdP, instead of having to re-authenticate before logging in. This option only works if the ’Allow Password Sign-In’ option is disabled.
-
Allow Creation of New Users (JIT Provisioning): Automatically creates a new, paid account in 15Five if an employee who has access to 15Five in your IdP attempts to log into 15Five.
Note
JIT Provisioning is not recommended when the Name ID is set to ‘Email’ or if you are using another integration like SCIM or an HRIS. Using JIT Provisioning with either of these options can cause duplicate accounts and issues with one integration overriding the other.
- Require Reviewer Selection: Requires an employee to choose their reviewer upon signing in for the first time. Such a choice will only be presented if reviewer information has not been passed in the SAML response. Most customers will want this off.
- Ensure assertions are signed and Ensure messages are signed: Tell 15Five what to expect from your IdP. You must have at least one of the two checked in order to proceed, but you are able to turn one setting off depending on your setup.
- The next four lines show the Service Provider User Sign In URL, IdP Entity ID, etc. These fields are auto-populated by pulling from the XML metadata you entered on the previous screen.
-
The bottom half of the page is where you set your attributes. The best way to know what should go in here is to check your IdP’s attribute mappings. If you need some guidance, the blue link labeled 'Attributes Help' may be helpful. The ‘Name ID Contents' and ’Email attribute name’ are the ones that are necessary to set up SSO, but there are a few others that you may want to sync.
Note
If ‘Name ID Contents“ is set to ’Not Used’, then the ‘Employee ID attribute name' must be filled out. Otherwise, there will be issues with employees logging in.
If you would like the employee’s reviewer to sync to 15Five, and you do not use another integration with 15Five like SCIM or another HRIS, then you would put the reviewer information under the ‘Reviewer Attributes’ section. Make sure to click Save!
If you need some guidance, reach out to 15Five Support with your attribute mappings and we're happy to help.
Test your SSO configuration
Looking to test that your SSO setup is working correctly? Follow these steps:
- Log out of 15Five.
- Head to https://<your subdomain>.15five.com
- Click the Sign in using Single Sign-on button and follow any other login steps provided by your Identity Provider (eg. Okta, OneLogin)
- You should then be redirected to 15Five and logged in.
SAML 2.0 does not offer de-provisioning support or asynchronous updates (updates to a profile in Google G Suite or Okta will not automatically show up in 15Five). For that, we offer SCIM integration for full auto-provisioning functionality with Okta or OneLogin.
Manage SSO
SSO is a great tool to more easily and securely manage access to your company's various software. SSO is not able to create new accounts unless the JIT setting is turned on.
Note
JIT provisioning is not recommended when Name ID is set to ‘Email’ or if you are using another integration like SCIM or an HRIS. Using this with either option can cause duplicate accounts and issues with one integration overriding the other.
In order to control access to 15Five, you remove or grant access to the platform through your IdP’s provisioning screens. Once you have assigned the platform to the employee on your IdP’s side, the employee will be allowed to log in. Without access, the employee will get a 400/403 permissions error.
Giving an employee access to your IdP does not automatically create a new account in 15Five. You can invite an employee manually, via bulk import, or through the use of JIT provisioning (if you do not use Email as your Name ID.) If you have SCIM or another HRIS integration, these integrations will automatically create new accounts in 15Five for you.
If you are using ‘User ID’ or ‘Not Used’ as your Name ID attribute, you can update the email in your IdP and when the employee goes to log in, their email update will carry to 15Five. See note below if you are using another integration to push updates, like SCIM or another HRIS.
If you are using ‘Email’ as your ‘Name ID’ attribute, then it is imperative that you update their email in 15Five so that the emails match. Otherwise, your employee will not be able to access the platform since the email we have in 15Five does not match what has access in your IdP. If you have JIT enabled and Email set as the ‘Name ID' attribute, it is important to update the emails before making the change in your IdP (or at least before an employee tries to log in with the new email address.) You can perform a bulk update if you are doing a larger update, such as company-wide domain changes.
Note
If you have SCIM or a HRIS integration set up with 15Five, then these changes will be pushed through that, and not through on the employee’s last login.
To remove access to 15Five, you would remove the app from the employee’s list of permissions in your IdP. However, this does not deactivate the employee’s account in 15Five. They will have to be manually deactivated, deactivated through bulk import, or through your SCIM/HRIS integration if you have that enabled.
Note
If you have 'Allow Password Sign In' enabled the employee will still be able to log in by requesting a password reset, as long as they are still active in 15Five.
Disconnect SSO
If you decide that you no longer want SSO set up, you will just need to uncheck the ‘SAML Single Sign-On Enabled’ option in your SSO settings and hit Save. If you remove SSO, then employees will have to log in using their email and password. If they have never set a password, they will have to select the forgot password option to set up their password.
Troubleshooting, Support, and FAQs
During your configuration of SSO, password login will still be an option. You will be able to login using both SSO and email+password until you explicitly shut off the option to log in with an email+password.
Yes. As soon as SSO is integrated, people will be able to log in.
Yes. SSO would allow your users to sign in with their SSO credentials. An HRIS or SCIM integration would help keep your people's details up to date. One solves an identity management and security problem, one solves a data management problem. For us, the answer depends on if we integrate with your HRIS system or not. If we don’t, then you can import user attributes through an SSO and/or SCIM, which would likely require a conversation with IT. See a list of our integrations here.
Yes. You can turn on or off this setting by clicking the box next to it on your company's Single Sign-On configurations page in 15Five:
We need the full XML.
This depends on what you use for user management in 15Five. We do not deprovision accounts via SAML/SSO. If the employee is transferred/terminated, this 1-removes access to the 15Five app in your IdP for that user. If not deactivated in 15Five, they may be able to access their 15Five account—if they have a 'keep me logged in' option in their browser. If you have SCIM or another integration setup, then that integration would handle deactivating the employee.
SAML is an authentication protocol, OAuth 2.0 is not. This means that OAuth 2.0 and SAML cannot be thought of as equal. OAuth 2.0 does not pass attributes about a user who has just authenticated. On top of that, Just-In-Time (JIT) provisioning is independent of SAML and not part of the SAML protocol specifications. The fact that SAML sends across user attributes in an assertion can be leveraged to implement a JIT provisioning system on top of, but that is a local implementation choice, not a SAML feature. One could build the same JIT system on top of OpenID Connect, which is a user authentication protocol built on top of OAuth 2.0. That would be comparable to JIT with SAML. (https://stackoverflow.com/questions/29885675/oauth-2-custom-attributes-like-saml#29894429). We do use OpenID Connect. We do not offer JIT provisioning with OpenID connect.
Account admins have control over whether their people can log in with email+passwords once SSO is enabled. There is a setting (checkbox) that appears during SSO set up. If you would like to allow people to continue using their original passwords set up with 15Five in addition to SSO, leave the 'Allow Password Sign In' box checked.
SSO does not provision users (does not create anyone's 15Five account) automatically. A user can sign in to 15Five with SSO using just-in-time provisioning. You can make sure the entire organization doesn’t receive email invites via the checkbox on the CSV bulk import or, if SCIM is on - there is a checkbox you can shut off there.
We do not provide an SSO service, as we are not an IdP; however, we do offer SSO integrations within our application.
It can put people’s job titles into 15Five if the attribute is set, but not automatically. A user would have to sign in to 15Five. SCIM 2.0 could do this automatically.
When the user logs in, the information is updated.
Yes.
No, just SSO/IdPs that use SAML 2.0. It’s standard, so it should be most.
The Reviewer information will be determined if you’ve included it in the ‘Review Email Attribute.’ If you have SCIM or another HRIS integration enabled, then this integration will pass the update, not SSO.
If no user attributes/information is being sent from ADFS or Azure AD to 15Five, make sure the below rules are configured on the ADFS/ Azure AD side:
Typically this is an issue with the Transform rule. Create a normal rule for email and then a transform rule that transforms email into NameID. Changing the NameID format to "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" would all be done in the Rely Party Trust modal. This is the claim rule (a non-default setting) as it would appear in ADFS.
Below you will find answers to the Azure AD partner application forms (include spreadsheet below).
|
Partner (Application) Information |
|
|
Application Descriptions |
Purpose: The application provides for intra-company communication and insight. Name: 15Five https://azuremarketplace.microsoft.com/en-us/marketplace/apps/aad.15five |
|
Multifactor Authentication |
Does the application Support Multifactor Authentication? Yes Will the application require Authentication? Yes. When? Authentication is required immediately. |
|
Sign on URL |
https:// subdomain>.15five.com |
|
Identifier |
https:// subdomain>.15five.com/saml2/metadata |
|
Reply URL |
https:// subdomain>.15five.com/saml2/acs |
|
User Identifier |
NameID or email |
|
Relay State |
https:// subdomain>.15five.com/ |
|
Secure Hash Algorithm |
SHA256 |
|
Access Rules |
Members with access to the application in the Azure Marketplace will have access to the 15Five app. |
Errors
A 403 error is a permissions error. This typically means that the employee does not have access in your company’s IdP, the email that they have permissions with does not match the one we have in 15Five, or the ‘Employee ID’ attribute was not passed (if your company uses User ID or Not Used as the Name Id attribute.) Make sure that the emails match, the employee is logging with the right email at the right URL, and that the Employee ID attribute is set if applicable.
Depending on the error you received (messages or assertions were not signed) you will have to uncheck the box next to that requirement. You are required to have at least one checked (the form will not save without it), but you can uncheck one, 'Save', and re-try logging in. You can update these settings on the SSO configuration page:
Possible solution: These conditions usually mean some manual configuration of SSO is necessary. Specifically, the SAML attributes sent by your Identity Provider (IdP) need to be mapped to the appropriate fields in 15Five. To see what attributes 15Five is receiving from your IdP, click on the "Attributes Help" text under the User Attributes section or check your attribute mappings in your IdP. Please note that at least one login attempt from your IdP to 15Five must be made before these attributes will be populated. These attribute names can then be used to fill in the form fields below.
You also may have to grant admin permissions to the tenet (15Five). See this link on how to do this:
https://stackoverflow.com/questions/57186280/application-misconfiguration-error-for-azure-active-directory
Possible solution: Sign-on URL” value in the Azure AD > Enterprise Applications > 15Five > Single Sign-On > Basic SAML Configuration section was set to an incorrect value. It should be set to https://SUBDOMAIN.15five.com. To find your subdomain, you would see in 15Five > Single Sign-On > Getting Started.
Possible solution: The Issuer attribute sent from the application to Azure AD in the SAML request doesn’t match the Identifier value configured for the application in Azure AD. The entity ID is set incorrectly in AAD. See below for an example of a misconfigured Entity ID (under Basic SAML configuration). Entity ID should =
https://<tenent-url>.15five.com/saml2/metadata/
Possible solution: Check to see if the subdomain is capitalized instead of lowercase.