Enable OpenID Connect Single Sign On (SSO)
CloudShare can set up user authentication via OpenID Connect for your account. When SSO is enabled for your account, users log into CloudShare using a dedicated SSO login page and they are authenticated by the OpenID Connect identity provider (IdP) of your choice.
This guide describes how to enable OpenID Connect SSO for your account, how to manage user authentication in SSO-enabled accounts, and how to log into CloudShare with SSO.
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.
In order to enable OpenID Connect SSO, all of the following steps must be completed.
Follow your IdP's instructions to create an OpenID Connect authorization server to provide SSO authentication for your CloudShare account. You will need to supply the following redirect URL: https://use.cloudshare.com/Ent/OpenIdConnectLogin.mvc/SignIn.
Follow any steps required to obtain a client identifier and client secret for the authorization server. Record these values for later.
Note
Keep the client secret in a secure place.
On the IdP's site, find the URLs that the IdP uses as the OpenID Connect authorization endpoint, token endpoint and issuer. Record these URLs for step 2.
Example instructions for configuring Okta IdP OpenID Connect settings can be found here.
Open a request to CloudShare Support and request OpenID Connect SSO enablement for your account. Provide the following information:
Item |
Description |
---|---|
Authorization endpoint |
The IdP's OpenID Connect authorization endpoint URL. Obtain this from your IdP. |
Token endpoint |
The IdP's OpenID Connect token endpoint URL. Obtain this from your IdP. |
Issuer |
The IdP's OpenID Connect issuer URL. Obtain this from your IdP. |
Client Identifier |
A unique identifier for the authorization server by the IdP. Obtain this from your IdP. |
Client Secret |
This is a token that will be used by CloudShare to verify the authenticity of the response from the IdP. This value is a secret and should be kept securely. Obtain this from your IdP for your authorization server (see step 1). |
Public keys |
The public keys that CloudShare will use to establish trust with your authorization server and validate incoming messages from your authorization server. Obtain this from your IdP for your authorization server (see step 1). |
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 would be able to 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 (see next). |
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 (see previous). 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 authorization server to enable OpenID Connect 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 the dedicated login URL that you will first use for testing, in the next step, and which your users with use as their SSO login page when the procedure is complete.
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.
-
Click the Log in to CloudShare button.
You are directed to your IdP.
Sign into the IdP using your test user.
Verify that you are logged into CloudShare successfully as your test user.
-
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.
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 make sure 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.
Verify both of the following:
-
On CloudShare, the user's CloudShare username, which must be an email address, 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.
Note
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.
In the IdP, the user's email address must be defined so that it matches the CloudShare username and will be passed by the IdP in the email claim per the OpenIdConnect protocol, specifically as the
email
scope value. For example, if you use Google as the IdP, the user's Gmail address (e.g. alice@gmail.com) will be passed as theemail
scope in the claim.
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.
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.
Regular password authentication is disabled by default for SSO-enabled users.
For security best practices, we recommend you do not normally enable password login for SSO-enabled users.
Note
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):
From the User Management menu, click Project Members. The Project Members page is displayed.
Locate and click the Email of the relevant user. The User Details Page for that user is displayed.
-
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.
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.
Note
If branding is enabled for your account, the dedicated SSO login page displays your logo. See Add Your Company Branding to CloudShare for more details.
Comments
0 comments
Article is closed for comments.