Reach 360: Manage Groups and Users with Single Sign-On (SSO)

Single Sign-On (SSO) allows users to sign in to a single system, such as a company directory, and then access multiple apps without having to sign in to each one with separate credentials. When SSO is enabled for your organization in Reach 360, you’ll manage users and potentially groups a little differently. Reach 360 account owners can enable SSO from the in-app interface. 

Reach 360 uses Security Assertion Markup Language (SAML) to authenticate users and supports System for Cross-domain Identity Management (SCIM) to automate user provisioning. You can use SAML on its own or with SCIM for added automation. 

Note: You can still add users in Reach 360 by following the steps listed here. Just keep in mind that users added in Reach 360 aren’t managed by your Identity Provider (IdP).  

Here’s how SSO can affect what you do in the People tab.

• Managing Users Authenticated with SAML
• Managing Groups with SAML
• Managing Users and Groups Provisioned with SCIM
• Glossary

Managing Users Authenticated with SAML

If your organization uses SAML, users managed by your IdP won’t display on the People tab until they first sign in with their SSO credentials. You won’t be able to modify their names or change or reset their passwords in Reach 360. These users will have an ID icon in their entry. 

The required attributes for a user to be created in Reach 360 are:

• firstName = first name
• lastName = last name
• email = email address
• subjectNameId or Unique User Identifier = any unique ID from your IdP

You can also send optional attributes:

• avatar = replaces user-defined profile photo (must be passed as a URL)
• groups = a list of groups the user is assigned to in the IdP that you’d like synced over to Reach 360.

To remove a user, you must first delete them from your IdP. Once they’ve been deleted there, you can remove their record from the Users tab.

Managing Groups with SAML

Group membership modifications made in your IdP aren't processed until the learner logs out, then logs back in to Reach 360. 

In Reach 360 with SSO enabled, group names must match with the IdP attribute or new groups will be created. Rename the group both in the IdP and Reach 360 to prevent accidental group membership changes and content enrollment issues when learners log back into Reach 360.

To remove a group that's linked to an SSO login, you must first remove the group assignment from the groups claim. Once it’s no longer being sent for users, you can remove the group from the Groups tab in Reach 360. If you don't update your SSO configuration, the group is reactivated the next time a user with that assignment in your IdP signs in with SSO.

Managing Groups and Users Provisioned with SCIM

If your organization uses SCIM in addition to SAML, you’ll see users displayed in the People tab after they’re added to your IdP, even if they haven’t yet signed in to Reach 360. As with SAML, you won’t be able to modify their names or change or reset their passwords in Reach 360. These users will have an ID icon in their entry. 

Users who’ve been provisioned by SCIM can only be removed via your IdP, not in Reach 360. Users who have been added to Reach 360 without provisioning can be removed as usual. 

When your organization uses SCIM, you can also have IdP-managed groups. Adding and deleting members from these groups must be done in your IdP, and you can’t add non-IdP managed users to them in Reach 360. 

The required attributes for a user to be created in Reach 360 via SCIM are:

• name.givenName = first name
• name.familyName = last name
• userName = email address

You can also send optional attributes:

• avatar = replaces any profile photo uploaded by the user (must be passed as a URL and is to be sent as an attribute that is part of the urn:scim:schemas:extension:metadata:2.0:User schema)
• externalId = any unique ID from your IdP

Note: The communication interval with Reach 360 is governed by your IdP. Once data is received by our SCIM server it will be available in Reach 360 immediately.

Glossary

Active Directory (AD)

Active Directory (AD) is a Microsoft product for managing users, permissions, and access to network resources. Many organizations use AD to manage their teams. Our SSO solution is compatible with AD, since both support SAML communication.

Assertion

An assertion is data sent by an identity provider (IdP) that supplies one or more of the following statements to a service provider (SP).

• Authentication statements declare that a user authenticated successfully and record the time they did so.
• Attribute statements supply details about the user. For example, the NameID attribute provides the username and is required for authentication. Other attributes can be manually configured as well.
• Authorization decision statements grant or deny the user access to a resource.

Assertion Consumer Service URL (acsURL)

An Assertion Consumer Service URL (acsURL) is an HTTPS location or resource at a service provider (SP), such as Reach 360, that accepts SAML messages from an identity provider (IdP).

Entity ID

The Entity ID is a unique string of letters and numbers, usually in the form of a URL, that identifies the service provider (SP). The Entity ID is also referred to as the Audience URI, and it’s often the same URL as the Assertion Consumer Service URL (acsURL).

Globally Unique Identifier (GUID)

A Globally Unique Identifier (GUID) is a string of letters, numbers, and dashes that identifies an entity. In the context of Reach 360 SSO, the GUID refers to your Reach 360 subscription ID. 

Identity and Access Management (IAM)

Gartner has a great definition of Identity and Access Management (IAM):

Identity and access management (IAM) is the security discipline that enables the right individuals to access the right resources at the right times for the right reasons.

IAM addresses the mission-critical need to ensure appropriate access to resources across increasingly heterogeneous technology environments and to meet increasingly rigorous compliance requirements. This security practice is a crucial undertaking for any enterprise. It is increasingly business-aligned, and it requires business skills, not just technical expertise.

Enterprises that develop mature IAM capabilities can reduce their identity management costs and, more importantly, become significantly more agile in supporting new business initiatives.

Identity Provider (IdP)

An identity provider (IdP) is a service that stores and manages a directory of user accounts or digital identities. Organizations use IdPs to manage their users and grant access to network resources. IdP examples include Okta, Azure, and Ping.

In the context of SSO, an IdP responds to authentication requests from a service provider (SP), such as Reach 360, to sign users into a service, such as your Reach 360 account.

Just-in-Time (JIT) Provisioning

Just-in-Time (JIT) provisioning automatically creates user accounts in an SSO solution the first time a user authenticates with their identity provider (IdP).

Lightweight Directory Access Protocol (LDAP)

Okta sums up Lightweight Directory Access Protocol (LDAP) nicely:

Lightweight Directory Access Protocol (LDAP) is an internet protocol that enterprise programs such as email, CRM, and HR software use to authenticate access and find information from a server.

The Reach 360 SSO solution uses SAML rather than LDAP integration.

Metadata

Metadata is information supplied by an identity provider (IdP) to a service provider (SP), or vice versa, in XML format.

• SP metadata supplies the Assertion Consumer Service URL (acsURL), the Audience Restriction, the NameID format, and x.509 certificates (used by the IdP to verify signatures from the SP and encrypt SAML requests to the SP from the IdP, if needed). 
• IdP metadata supplies the SSO URL, the Entity ID, and the x.509 certificates required by the SP to verify the signature of the assertion from the IdP and, if encryption of SAML requests is required, encrypt messages from the SP to the IdP. 

Multi-Factor Authentication (MFA)

Multi-factor authentication (MFA), also called two-factor authentication (2FA), requires users to pass a second layer of security when signing in to an app or system. A common form of MFA asks users to enter a verification code, which they get via text or an authenticator app. 

MFA isn't supported for Reach 360. We recommend enabling MFA through your IdP for an extra layer of security.

OAuth

OAuth, or Open Authorization, is a standard for giving users access to third-party apps without exposing their passwords. The Reach 360 SSO solution doesn’t involve OAuth.

OpenAM

OpenAM is an open-source access management system used by some organizations to provide SSO service to their users. The Reach 360 SSO service is compatible with OpenAM, since both support SAML communication.

Security Assertion Markup Language (SAML)

Security Assertion Markup Language (SAML) is an open, XML-based standard for exchanging authentication data between an identity provider (IdP) and a service provider (SP), such as Reach 360.

Our SSO solution uses SAML 2.0 to authenticate users in Reach 360 based on their company identities, so users don’t have to manage a separate set of credentials for Reach 360.

Single Sign-On (SSO)

Single sign-on (SSO) allows users to sign in to a single system, such as a company directory, and then access multiple apps without signing in to each one with separate credentials. SSO boosts productivity and lets organizations enforce their own password security requirements.

Service Provider (SP)

A service provider (SP) is a company that offers a service, such as hosting content. An SP communicates with an identity provider (IdP) to sign users in to the service. Reach 360 is the SP in this context.

System for Cross-Domain Identity Management (SCIM)

SCIM is an open standard for the automation of user provisioning and deprovisioning. For example, a company could use SCIM to automatically add their users to a subscription cloud service and synchronize their company profiles with the cloud service.