Applies to these roles: Admin
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 Rise, you’ll manage users and potentially groups a little differently. To learn more about setting up SSO for your organization, click here.
Rise 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.
No matter which configuration you use, you can still add non-provisioned users in Rise by following the steps listed here. Just keep in mind that those users aren’t managed by your Identity Provider (IdP) and, in some cases, you might not be able to add them to groups.
Note: Users managed by your IdP don't receive Rise welcome emails. Once your IdP and Rise are connected, they'll be able to use their SSO-provisioned login to access your site immediately.
Here’s how SSO can affect what you do in the People tab.
Managing Users Authenticated with SAML
If your organization just 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 Rise. These users will have an ID icon in their entry. The attributes that are required for a user to be created in Rise are:
firstName= first name
lastName= last name
Unique User Identifier= email address
You can also send optional attributes:
role= learner, author, reporter, or admin
avatar= replaces user-defined profile photo (must be passed as a URL)
If your SSO administrator hasn’t added
role as a field in your IdP, or that field contains something other than the standard Rise roles, then the default role for your team will be applied and you can change it as usual. However, if
role is later defined in the IdP, that value overwrites the value you set in Rise.
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.
With SAML, your groups are managed in Rise as usual.
Note: Users can't be excluded from libraries before they log in for the first time. Limit what new users can and can't see with one of the tips here.
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 Rise. As with SAML, you won’t be able to modify their names or change or reset their passwords in Rise. These users will have an ID icon in their entry.
If your SSO administrator hasn’t added
role as a field in your IdP, or that field contains something other than the standard Rise roles, then the default role for your team will be applied and you can change it as usual. However, if the Role field is later defined in the IdP, that value overwrites the value you set in Rise.
urn:scim:schemas:extension:metadata:2.0:User as the external namespace value when adding
role to your IdP,
Users who’ve been provisioned by SCIM can only be removed via your IdP, not in Rise. If they’ve created content, you’ll need to transfer it to a different user. Users who have been added to Rise 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 Rise.
Note: The communication interval with Rise is governed by your IdP. It might take several hours for you to see changes made in your IdP.
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.
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 Rise, that accepts SAML messages from an identity provider (IdP).
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 Rise SSO, the GUID refers to your Rise 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 Rise, to sign users in to a service, such as your Rise 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 Rise SSO solution uses SAML rather than LDAP integration.
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.
We’re currently evaluating MFA for Rise. In the meantime, we recommend enabling MFA through your IdP for an extra layer of security.
OAuth, or Open Authorization, is a standard for giving users access to third-party apps without exposing their passwords. The Rise SSO solution doesn’t involve OAuth.
Okta is an enterprise-grade identity management service that authenticates users, granting them access to apps without needing separate usernames and passwords for each app.
We use Okta to provide SSO service to Rise subscribers so team members can sign in with their company identities.
OpenAM is an open-source access management system used by some organizations to provide SSO service to their users. The Rise 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 Rise.
Our SSO solution uses SAML 2.0 to authenticate users in Rise based on their company identities, so users don’t have to manage a separate set of credentials for Rise.
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 into the service. Rise 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.