Accounts
Single Sign-On, SAML and Automatic User Provisioning
Overview
Depending on your plan type, Cloud 66 supports both Single Sign-On (SSO) via SAML and Automatic User Provisioning (AUP).
- Automatic User Provisioning - Team plans (and above)
- SSO via SAML - Business plans
Automatic User Provisioning
Account owners can enable AUP for their Cloud 66 organization for either of these two signup methods:
- Sign-ups that use Google oAuth
- Sign-ups via SAML (see the Configuring AUP with SSO section)
What is AUP?
Automatic User Provisioning assigns a set of predefined permissions to any new team members that meet on of these predefined criteria:
- Either their email address is from a verified domain
- Or they sign in via an SSO-enabled account
It acts as a kind of open, “forward looking” invitation to any eligible user who meets one of these criteria.
Setting up AUP for Google sign-ups
Automatic User Provisioning for Google sign-ups is based on the email domain associated with the Google account.
In other words, you would specify your organization’s domain (e.g. “mycompany.net”) and then any sign-ups from Google accounts that use email addresses with that domain will be automatically added to your Cloud 66 account.
To set up AUP for Google sign-ups
- Verify of your organization’s email domain
- Configure AUP settings
Follow the instructions below to do both:
Domain verification
You must verify any domain before you can use it for Google-based AUP. To do this, you will need to add a TXT record to your DNS by following these steps:
- Log into your Cloud 66 Dashboard
- Click on your avatar (top right) and choose Account Settings
- Click on Verified Domains in the Settings panel on the left
- Copy the unique TXT record provided at the top of the page
- Log into the DNS management interface of your domain provider
- Add the TXT record you copied above at the root level of the domain (usually denoted as
@
) and submit it. If you’re not sure how to add a TXT record, check the help docs of your domain provider. - Go back to Cloud 66, input your domain name and click Add Domain
- We’ll test your domain repeatedly for a day or two. You can click on the Domain Verification Running link to see the logs from our attempts.
If your domain is not verified within a couple of days. You can manually trigger a check by using the retry button that will appear if the first attempt at verification fails.
Once your domain is verified, you can configure AUP for your organization (see the next section).
Configuring AUP settings for Google sign-ups
To configure AUP for Google sign-ups:
- Log into your Cloud 66 Dashboard
- Click on your avatar (top right) and choose Account Settings
- Click on Members in the Collaboration panel on the left
- Find your verified domain in the Automatic User Provisioning for Verified Domains panel and click the Setup Rules button next to the domain in question
- Set default permissions for automatically provisioned accounts
- Click Save Rules at the bottom of the page
You can have different AUP policies for different verified domains. Only one AUP policy can be linked to a each verified domain.
You can edit an existing AUP by clicking the edit icon (pencil and paper) or remove AUP for an SSO provider by clicking the delete icon (trashcan).
AUP will now begin working for all new sign-ups to Cloud 66 that use your email domain.
AUP permissions are forward-looking
Permissions granted when you configure AUP only apply to signups that happen after configuration. Any team member provisioned individually, using a different AUP configuration will not have their permissions changed. Updating existing AUP permissions will not affect the permissions of accounts that signed up before the update.
SSO integration
Cloud 66 uses Security Assertion Markup Language (SAML) to enable Single Sign-On (SSO). We support any SAML-compatible external Identity Provider (IdP) - including Okta, Auth0, OneLogin, Microsoft, Google and thousands more. You can have multiple SAML integrations per Cloud 66 organization.
Setting up a SAML integration with your preferred IdP requires two things:
- Configuring your Identity Provider (IdP) to recognise Cloud 66 as a Service Provider (SP)
- Configuring your Cloud 66 account with details of your (SAML) IdP
SSO does not assume AUP
You can enable SSO without automatic user provisioning. In that case users will need to sign up for Cloud 66 accounts using the email associated with their SSO credentials and you can then manually add them to your team and provision them as per usual.
These are the official guides for some popular SAML IdPs:
- Google (Workspace) SSO and custom SAML application guides
- Okta SAML app guide and field reference guide
- Microsoft Azure AD add enterprise application and enable SSO for an enterprise app guides
- OneLogin Advanced Custom Connector guide
Configuring Cloud 66 as a SAML Service Provider
Your SAML Identity Provider (IdP) needs to be configured to recognize Cloud 66 as an approved Service Provider (SP) for your IdP account. This requires two URLs:
- An ACS URL
- An Entity URL
Some providers also require Name Field Format (also called NameID format). We only support email NameIDs - see below for the full definition.
Different IdPs have different names for the configuration URLs, here are some examples
IdP | ACS URL name | Entity URL name |
---|---|---|
Okta | Single sign-on URL | Audience URI |
OneLogin | ACS (Consumer) URL and Recipient | Audience |
Auth0 | Post-back URL | Entity ID |
ACS URL | Entity ID | |
Microsoft (Azure AD) | Reply URL | Identifier |
The values for Cloud 66 are the same for all accounts:
- ACS URL:
https://app.cloud66.com/users/saml/auth
- Entity URL:
https://app.cloud66.com/users/saml/metadata
- Name field format:
urn: oasis: names: tc: SAML: 1.1 :nameid-format: emailAddress
(or, if there’s a predefined list of options, selectemail
) - If there’s an option for “Signed response” you should select / enable it
To configure your IdP:
- Log into the admin interface
- Follow the instructions to add a new SAML service provider (also known as an “application”).
Once Cloud 66 is set up as an SP you can move onto the next step.
Connecting your Cloud 66 account to your IdP
Now that your IdP will recognize your Cloud 66 account, you need to point your account at that IdP to allow the exchange of credentials. To do this, you’ll first need to add some information from your IdP to your Cloud 66 account:
- An Entity ID (usually a URL)
- An SSO URL
- A certificate or fingerprint (and algorithm)
You’ll notice the names of these URLs are very similar (or identical) to the ones used to set up an SP. This can be confusing, so be sure you are looking at the fields for Identity Provider (and not Service Provider) - many SSO platforms can act as either SPs or IdPs (or even both). It’s needlessly confusing, we know.
If your IdP uses fingerprints rather than certificates, you will need to specify a fingerprinting algorithm. We currently support SHA1, SHA256, SHA384 and SHA512
Once you have found all of the above info, you will need to add it to your Cloud 66 accounts. Do this this:
- Log into your Cloud 66 Dashboard
- Click on your avatar (top right) and choose Account Settings
- Click on Login & Security in the Account panel on the left
- Scroll down to the form and add the required info
- Click the Add SAML Single Sign-On button
You should now see your provider listed in the Single Sign-On Providers panel.
We strongly recommend thoroughly testing that SSO works before beginning to enforce it. Most IdPs have a test mechanism in their admin interfaces.
Existing logins will continue to work
By default existing users can continue to log into their accounts with their old credentials as well as SAML. Account owners can limit this for existing users by enabling the SSO-only setting on their account. Users created with SAML SSO will only be able to login with SAML.
Signing in via SSO
To sign into Cloud 66 via SSO you will need to use the URL provided by your IdP, which you’ll find on their admin dashboard. It will be under the Cloud 66 application (or service) that you configured in the first step above.
If you enforce SSO-only sign-ins (see next section) then you will not be able to use the normal Cloud 66 login page - you will be forced to use the SSO URL.
Enforcing SSO-only logins
You can force all your team members to use SSO for added security. To enable this:
- Log into your Cloud 66 Dashboard
- Click on your avatar (top right) and choose Account Settings
- Click on Login & Security in the Account panel on the left
- Click on the Enable SSO Only button (at the bottom of the page)
You can disable this mode using the same steps.
Configuring AUP with SSO
You can set up automatic user provisioning for anyone with SSO credentials. To do this, first set up SSO (see above) and then:
- Log into your Cloud 66 Dashboard
- Click on your avatar (top right) and choose Account Settings
- Click on Members in the Collaboration panel on the left
- Find the SSO provider in the Automatic User Provisioning for Single Sign-On Providers panel and click the Setup Rules button
- Set default permissions for automatically provisioned accounts
- Click Save Rules at the bottom of the page
You can have different AUP policies for different SAML providers, and thus grant different access rights to users based on their SSO provider. Only one AUP policy can be linked to a each SAML configuration.
You can edit an existing AUP by clicking the edit icon (pencil and paper) or remove AUP for an SSO provider by clicking the delete icon (trashcan).
Account switching for SAML users
All accounts on Cloud 66 have their personal logins, but can be members of other organizations. If a user is a member of a SAML-only organization, they will not be able to switch to that organization in the Cloud 66 dashboard if they are not logged in using SAML. They will need to log out and log back in using SAML before they will be able switch.
If a user logs in via SAML (SSO), they can switch to organizations (including their personal one) that have lower security requirements.
Two-factor authentication (2FA) and SAML
Logins via SAML are exempt from 2FA requirements. If 2FA or FIDO keys are setup on a login, they will not be used if the user logs in with SAML. If SSO-only is not enabled, non-SAML logins will still be subject to the organization’s 2FA requirements.