Current release 3.10.0
CloudShark 3.9.6 CloudShark 3.9.5 CloudShark 3.9.4 CloudShark 3.9.3 CloudShark 3.9.2 CloudShark 3.9.0 CloudShark 3.8.3 CloudShark 3.8.2 CloudShark 3.8.1 CloudShark 3.8.0 CloudShark 3.7.4 CloudShark 3.7.3 CloudShark 3.7.2 CloudShark 3.7.1 CloudShark 3.7.0 CloudShark 3.6.0 CloudShark 3.5.0 CloudShark 3.4.0 CloudShark 3.3.0 CloudShark 3.2.0 CloudShark 3.1.0 CloudShark 3.0.0 CloudShark 2.8.0 CloudShark 2.7.0 CloudShark 2.6.0 CloudShark 2.5.0 CloudShark 2.4.0 CloudShark 2.3.0 CloudShark 2.2.0 CloudShark 2.1.0 CloudShark 2.0.0 CloudShark 1.9.0 CloudShark 1.8.0 CloudShark 1.7.0 CloudShark 1.6.0 CloudShark 1.5.0 CloudShark 1.4.0 CloudShark 1.3.0 CloudShark 1.2.0

OAuth

OAuth 2.0 based authentication allows your users to login to your CloudShark Enterprise server via either Google or Okta. This simplifies the work of an Administrator by eliminating the need to create user accounts or reset passwords if they are forgotten. CloudShark accounts can be created when a user logs in for the first time and default CloudShark settings can be configured using the User Default Settings.

Okta

CloudShark 3.9.6 added support for authentication via Okta. This authentication method supports configuring a custom base URL and makes group membership available via OAuth. Okta is also supported as a SAML 2.0 authorization endpoint if you would prefer to do it that way.

Configure Okta

Authentication via Okta requires your Okta admin to create a new "app integration" within your domain for your CloudShark Enterprise server. You can follow the Okta documentation here.

  • Choose "OIDC - OpenID Connect" as the sign-in method
  • Choose "Web Application" as the Application type.

General Settings:

  • "Authorization Code" is the only option that needs to be selected for Grant type

Sign-in redirect URIs

A single sign-in redirect URI should be configured in Okta to match the URI for your CloudShark Enterprise system with the path set to /auth/okta. For example: https://cloudshark.my.corp.lan/auth/okta. We do not recommend allowing a wildcard in the sign-in URI redirect.

Sign-out redirect URIs are optional and should be removed.

Assignments

The assignments section is specific to your organization.

Making Group membership available

In order for Group memberships to be available in CloudShark, you must update the Application within Okta to send them.

After saving and creating the application, visit the "Sign On" tab for your new application integration. Edit the section labeled "OpenID Connect ID Token". You must configure a Groups Claim in order for group membership to be available within CloudShark.

If you do not have specific group requirements, change the groups claim filter to be "groups", "Matches regex", ".*" as shown here:

 groups claim filter matches regex .*

Configure CloudShark

Once you have created the application in Okta, move to CloudShark to finish setting it up.

Configure the BaseURL for your Okta org. It will be something like https://${myBaseUrl}.okta.com. Once that is configured, click the "auto-discover endpoints" link to fetch your organizations Authorize and Token URLs.

Copy the following from Okta into CloudShark:

  • Client ID
  • Client Secret

Note: CloudShark does not support using a Public/Private key for Client authentication.

Groups

If you want Okta group membership to map to CloudShark groups, please read our External Authentication documentation under the "Managing External Groups" section.

Testing

Press "Save settings" on the External Authentication settings page. You are now configured to log your users in via Okta. To test, log out and verify that there is a new "Login with Okta" button on the sign-in page. Clicking it will start the authentication exchange to log you in.

 

Google

Instructions for generating Client ID and Client Secret for OAuth with Google

When Google is used to authenticate users for CloudShark their e-mail address will become their username.

If you are using a work domain with google you can specify a Domain to restrict users to your domain. This will require that the user uses an e-mail address that is a part of the specified domain.

Google requires that the host-name in the Callback URL is able to be resolved using a public DNS server.

Twitter

Please note that OAuth support for Twitter has been deprecated and will be removed from future versions of CloudShark. 

Instructions for generating API Key and API Secret for OAuth with Twitter

When Twitter is used to authenticate users for CloudShark their Twitter handle will become their username.

Facebook

Please note that OAuth support for Facebook has been deprecated and will be removed from future versions of CloudShark.

Instructions for generating App ID and App Secret for OAuth with Facebook

When Facebook is used to authenticate users for CloudShark their e-mail address will become their username.