Single Sign-On (SSO)

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.

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.

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).

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: See https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/methods-for-assigning-users-and-groups

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.