Single Sign-On (SSO)

Single Sign-On (SSO) Overview

Using SSO authentication greatly simplifies the end user experience, resulting in greater customer satisfaction. With SSO, a user only needs to remember one password to access CloudShare.

CloudShare supports powerful SSO authentication at both the account and class levels:

• Account-Level SSO. You can manually configure SSO access for your account using the following protocols:
  • SAML 2.0 integrates CloudShare with any Identity Provider (IdP) for SAML 2.0 user authentication. 
  • OpenIDConnect integrates CloudShare with any Identity Provider (IdP) to for OpenID Connect user authentication.
  • WS-Federation (Okta) integrates CloudShare with Okta for WS-Federation user authentication and authorization.
• Class-Level SSO. You can activate SSO for a selected class, so that a student logs in using your selected SSO service provider to instantly access their own CloudShare environment.

Enabling SAML 2.0 Single Sign On (SSO)

CloudShare can set up user authentication via SAML 2.0 SSO for your account. When SSO is enabled for your account, users log into CloudShare using a dedicated SSO login page and are then authenticated by the Identity Provider (IdP) of your choice. 

This guide describes how to enable SSO for your account, how to manage user authentication in SSO-enabled accounts, and how to log into CloudShare with SSO.  

SAML 2.0 support includes authentication only. User authorization via SAML 2.0 is currently not supported.

Note: SSO login is for CloudShare project member users only. It does not affect end users such as students invited to classes on CloudShare or users invited to a CloudShare-hosted POC. 

Enabling SSO for Your CloudShare Account

In order to enable SAML 2.0 SSO, all of the following steps must be completed. Note that the order of steps could vary depending on your IdP. 

Step 1: Open a Support Request

Open a request to CloudShare Support and request SAML SSO enablement for your account. 

Provide the following information:

• Entity ID - The unique string used to identify your IdP. Obtain this from your IdP.
• Public X.509 Certificate - The certificate CloudShare will use to establish trust with your IdP and validate incoming SAML assertions from your IdP. Obtain this from your IdP.
• IdP Login URL - The URL to which CloudShare should redirect users for authentication. Obtain this from your IdP.
• SAML Metadata file - A file containing your SSO configuration details. Obtain this from your IdP.
• SSO Owner - A CloudShare user of your choice who will always have password login enabled in addition to SSO login. This ensures that your organization can access CloudShare in the event of failure on the IdP side. The user must be defined in your IdP with an email address belonging to one of the specified email domains (described below).
• Email Domains - The names of the email domains and/or sub-domains that you want to enable for SSO authentication. For security reasons, these should be domains owned by your organization.
• Test User - The email address of a test user to use when testing the SSO integration. The user must be defined in your IdP with an email address belonging to one of the specified email domains (described above). This can be either the SSO owner user or a dedicated test user that you create on your IdP. Do not submit an active CloudShare project member user other than the SSO owner as the test user, since the SSO configuration disables regular login.

Based on the details you provide, CloudShare will integrate with your IdP to enable SAML 2.0 SSO on a test project in your account. At this stage, your users can continue to log into CloudShare via regular password login. We will provide you with: 

• A metadata file with information about CloudShare, for your IdP.
• A dedicated login URL.

Step 2: Configure your IdP to Provide SSO for CloudShare

Follow your IdP's instructions to configure the IdP to provide SSO authentication for your CloudShare account. You will need to supply metadata from CloudShare, using the file provided to you by CloudShare Support. This will provide the IdP with information about where and how to send SAML messages.

Example instructions for configuring Okta IdP SAML settings can be found here.

Step 3: Test the SSO Integration

1. Using a browser in which you are currently not logged into CloudShare or to your IdP, browse to the dedicated login URL provided to you by CloudShare Support.
2. Click the Log in to CloudShare button. You will be directed to your IdP.  
3. Sign into the IdP using your test user. 
4. Verify that you are logged into CloudShare successfully as your test user.
5. Report back to CloudShare Support that you have completed the integration test. Specify if you were logged into CloudShare successfully as the test user. CloudShare Support will now work with you, based on your test results, to fully establish successful integration. 

Step 4: Verify Configuration of Existing Users

Once the integration with your IdP is established, CloudShare is ready to extend the integration to the active projects in your account. When this is complete, your users will no longer be able to log into CloudShare via regular password login. Therefore, the next step is to make sure that all existing users are correctly set up so that they will be authenticated successfully over SSO once the integration is fully enabled on your account. 

For each user, verify that:

• On CloudShare, the user's CloudShare username is an email address that belongs to an SSO-enabled domain, as agreed with CloudShare Support in step 1. For example, if "company1.com" is a domain that CloudShare enabled for your account for SSO, then a user whose email address is "user@company1.com" is set up correctly on CloudShare for SSO authentication.
  
  We recommend that all usernames belong to the SSO-enabled domains. In the event that a user's email address does not belong to one of your SSO-enabled domains, the user is not SSO-enabled and is authenticated using regular password login.
  For example, if the domain, "company2.com" is not SSO-enabled for the account, then a user whose CloudShare user name is "user@company2.com" would not be SSO-enabled. That user would be authenticated using regular password login. AND in your IdP, EITHER

• The user's IdP user name is identical to the user's CloudShare username.
  In this case, during the SAML authentication process, the SAML response assertion sent by the IdP to CloudShare should include the user's email address in the NameID attribute. For example:

  <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameidformat:unspecified">user@company1.com</saml2:NameID>

  OR

• The user's email address (which is the CloudShare username) is defined in the IdP as another attribute, in such a way that the SAML response assertion from the IdP to CloudShare inserts the email address into an attribute statement with attribute name "email". For example:

<saml2:AttributeStatement>

            <saml2:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrnameformat:unspecified" Name="email">

                <saml2:AttributeValue xsi:type="xs:string" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance">user@company1.com</saml2:AttributeValue>

            </saml2:Attribute>

        </saml2:AttributeStatement>

Step 5: Complete the Enablement

When you are ready for CloudShare to complete the enablement for your entire account, contact CloudShare Support and we will complete the enablement for you. 

Managing User Authentication in SSO-Enabled Accounts

When your CloudShare account is SSO-enabled, SSO login is automatically enabled for all users with emails that belong to your SSO-enabled domain(s). SSO login cannot be disabled per user. In order for the users to be successfully authenticated, they must also be defined in your IdP with the same email address as their user name or email. 

Normal password login is automatically disabled by default for all users whose email addresses belong to your specified SSO-enabled domains, with the exception of the SSO owner user, who can use both SSO login and password login. 

If a user's email address does not belong to one of your SSO-enabled domains, the user will be enabled for normal password login and not for SSO login.

It is possible to enable password login as an additional login path for any individual SSO-enabled user. Use this option with caution. As a best security practice, we recommend restricting users to SSO login wherever possible.

Adding New Users

To add a new user, do both of the following:

• Add the user to your IdP, making sure to enter the SSO-enabled email address as the user name or as the email address, such that the IdP inserts the email address into an attribute statement with attribute name "email". For example, if the domain "company1.com" is SSO-enabled for your account, "user@company1.com" would be SSO-enabled. 
• Invite the user to CloudShare (via User Management > Project Member Invitations). CloudShare checks that the email address that you enter in the Email field is SSO-enabled for your account. Provided the email domain is SSO-enabled, the user is created as an SSO-enabled user and has no CloudShare password. The user receives an invitation email directing the user to your dedicated SSO login page. 

Enabling Password Login for SSO-Enabled Users (Optional)

Regular password authentication is disabled by default for SSO-enabled users.

For security best practices, we recommend that you do not normally enable password login for SSO-enabled users. 

The SSO owner user, specified in your support request for SSO enablement (see step 1 above), always has the ability to log into CloudShare by regular password login. This means that in case any IdP failure should ever occur, your organization will still have a way to access CloudShare.

Note: This task requires the Project Manager user role.

To enable password login for an SSO-enabled user (not usually recommended):

1. From the User Management menu, click Project Members. The Project Members page is displayed.
2. Locate and click the Email of the relevant user. The User Details page for that user is displayed.
3. Click Allow Non-SSO Login. The Allow Non-SSO Login button is replaced by the Allow SSO Login Only button. The user is now able to log into CloudShare via password, as well as via SSO.  If the user had a CloudShare password previous to SSO enablement, that password is once again activated. In the event that the user does not have or know their password, the user should click Can't access your account? on the CloudShare login page, and follow the instructions.  To disable password login, click Allow SSO Login Only.

Logging into CloudShare with SSO 

Once your account is SSO-enabled, SSO-enabled users can log in via the dedicated SSO login page supplied to you by CloudShare Support. 

If an SSO-enabled user visits the regular CloudShare login page, the user is redirected to the dedicated SSO login page.

Integrating CloudShare with Okta for WS-Federation SSO

WS Federation SSO Overview

CloudShare supports WS Federation Single Sign On (SSO).

This article provides full instructions for how to integrate Okta into CloudShare as a single sign-on (SSO) identity provider (IdP). This guide assumes you are an Okta admin user.

Okta provides a template through which you can create a WS-Federation enabled app that enables Okta to handle CloudShare authentication. Using this template, Okta acts as the IdP while CloudShare acts as the service provider (SP) in the following authentication flow:

1. The user browses to the CloudShare login page or clicks a “chicklet” in Okta.
2. CloudShare redirects the user to the configured login URL (Okta’s generated app instance URL) sending a passive request. 
3. Okta is sent a passive request (assuming you have an existing Okta session). 
4. Okta sends a response to CloudShare. 
5. CloudShare receives the response and verifies that the claims are correct. A CloudShare session is established.
6. The user is authenticated and receives the assigned CloudShare user role. 

Follow the steps in this guide to create the app and assign your users correctly.

Step 1: Contact CloudShare Support

Call CloudShare support to request Okta integration. We will decide together with which of your projects, teams, owning project managers and email domains should be included in the scope of the Okta integration. We will then provide you with an SSO Provider Name, which you will use in step 2.  

Step 2: Add CloudShare to Okta

In this step, you will add CloudShare to Okta as an application:

1. Log in to Okta as a system administrator and click Admin to enter the Admin area.
2. From the Applications menu, select Applications and then click Add Application.
3. Search for "Template WS-Fed" and add that application template.
   
   
    
4. In the Add Template WS-Fed page, enter the following field values:

5. Click Next, click Next again (skip Assign to People), and then click Done. The Cloudshare application is added to your active applications.
   
   
    

6. Open the Cloudshare application you just created.
7. Select the SignOn tab, click View Setup Instructions and then copy the Realm (App ID URI) from the setup instructions page.

8. Select the General tab and paste the value you copied into the Audience Restriction

Step 3: Assign Users

Each user must have a first name, a last name, and a primary email address defined in Okta. The Okta primary email address (and not the Okta username) becomes the user’s CloudShare username.

For existing Okta users, check before assigning them that they have the required details, and fix if necessary.

For any users not defined yet in Okta, add them as Okta users and then assign them.

To assign a user to CloudShare:

1. Open the Cloudshare application that you created (From the Applications menu, select Applications, and then click the application name).
2. Select the People tab and then click Assign to People. The Assign Cloudshare to People dialog box appears.
3. Search for a user you want to add and click the Assign button for the user.
   
   
    
4. Click Save and Go Back.
5. Assign more users the same way.
6. Click Done.

Checking Okta User Details

To check that an existing Okta user has the required details for CloudShare:

1. Select People from the Directory
2. Click the user’s name and then select the Profile
3. On the Profile tab, the First name, Last name, and Primary email fields must be populated. If not, click Edit and add those details.

Adding New Users

To create a new Okta user:

1. From the Directory menu, select People.
2. Click Add Person. The Add Person dialog box appears.
3. Enter the First name, Last name, and Primary email.
4. Select Send user activation email now. This will send the user an activation email and enable the user to set a password.
5. Click Save (or Save and Add Another if you want to add more users).

Step 4: Add Users to Groups

Note: This step is required in order to complete the integration successfully. Users who do not belong to a CloudShare group will not be able to sign into CloudShare.

CloudShare user roles are defined per CloudShare project. There are three CloudShare user roles allowed for accessing any CloudShare project:

• Project manager (highest level access)
• Team manager
• Team member (lowest level access)

The CloudShare-Okta integration applies roles and project access through Okta groups named according to a pre-configured naming convention. Each group you can create enables members to access a specific project with a specific role. For example, adding a user to a group called CloudshareCampaign-MyProject-TeamMember gives the user access to a project called MyProject with the Team Member role

Create a group for every role you need to assign per project. Add users to the groups that give them the correct role for the correct project.

Creating Groups

To create a group:

1. From the Directory menu, select Groups.
2. Click Add Group.
3. In the Name field, enter:

CloudshareCampaign-<Project Name>-<Role>

<Project Name> is the name of the project. Users who belong to this group will be able to access the specified project.

<Role> must be one of the following:

• TeamMember – assigns the team member role.
• TeamManager – assigns the team manager role.
• CampaignManager – assigns the project manager role.

For example, to assign the team member role for access to a project called MyProject, create a group called CloudshareCampaign-MyProject-TeamMember.

Upon request, CloudShare Support can customize the role names for you.

4. Click Add Group. The group is created.

Adding Users to Groups

Add each user to a group to grant the user access to a specific project with a specific user role.

To add users to a group:

1. From the Directory menu, select Groups.
2. Click the group you want to add users to.
3. Click Manage People and then add members:
   • Use the search box to find people.
   • To add one person, mouse over the person in the Not Members box and then click
   • To add multiple non-members, click Add All.

4. Click Save.

Step 5: Send Us These Details

To complete the integration:

1. Go to the Sign On tab and click the View Setup Instructions.
2. From the page that appears, retrieve the following and provide them to CloudShare Support:
   • The Realm (APP ID URI)
   • The Issuer
   • The Passive Endpoint
   • The certificate thumbprint, which you can find in an “<add thumbprint=" element in the Sample ASP.NET Configuration code sample.
   • IntegrateCloudSharewithOkta.pdf
     300 KB  Download

Enabling Single Sign On (SSO) for Classes

With class-level SSO authentication, students only need to remember the access credentials for their SSO identity provider. CloudShare does all the background work for matching each user sign on with the relevant class.

Using class-level SSO makes logging in to the training environment simpler, giving the entire training experience a better start. It also offers additional branding opportunities.

Note: Class-level SSO connections are available only when pre-configured for your account. Contact your CloudShare Support Representative for setup.

A user with the appropriate role permissions can enable SSO when creating or editing a class:

With class-level SSO enabled, students will receive an invitation link that takes them directly to the chosen SSO provider, where they log in:

After successful login to the organization's SSO provider (for example Okta, as shown above), students are taken directly to their CloudShare environment, without the need to enter any additional credentials.

When required, CloudShare will verify that a student is actually registered for the class before sending them to the SSO provider.

Note: Classes that use LTI-based access (LMS integration) will automatically authorize the students based on the LMS authorization.

Configuring an Account for SSO

Before SSO can be configured, a CloudShare System Admin must enable the Is End Users SSO Visible feature flag for the account. For assistance, contact CloudShare Support.

An Account Manager performs Step 1 through Step 3 below to set up and test a SSO platform connector with the desired IdP. Following this setup, a Project Manager can enable and select the relevant SSO connector for the class.

1. On the General page, click Add Single Sign-On (SSO) Connector near the bottom. The page will be redirected to CloudShare's SSO platform vendor, displaying all available SSO identity provider (IdP) options.
2. Select the desired IdP and click Get Started, following that vendor's procedure for configuring the SSO connection.

3. Test the new SSO connection with your selected vendor:
   

   Note: Only successfully tested SSO connections can be assigned to an account.

4. When the SSO connection is set up and tested, a Project Manager can confirm that the Enable Single Sign-On option is enabled in the Settings panel for the desired project (this option appears in the Class Setup section of the panel).
   
   If multiple SSO connections are configured for the account, the Project Manager can choose which connection will be available for each project.

Following configuration, the SSO connection will be available as an access choice for any class that is created in the enabled project. 

Editing an Existing SSO Connection

An Account Manager can edit an existing SSO connection by clicking the setup icon for the desired SSO connection:

Deleting a SSO Connection

An Account Manager can delete an existing SSO connection, as long as it is not in use by an existing class (either scheduled or running).