Single Sign-On

Cloudsmith offers support for Single Sign-On (SSO) at the organization level using Security Assertion Markup Language (SAML). With SAML, organizations can use their existing SSO provider to manage and control access to their Cloudsmith organization account.

Getting Started

Before configuring SSO with SAML, you'll need:

  • A SAML Identity Provider that you can connect with Cloudsmith.
  • Manager access to the Cloudsmith organization.

Enable SAML

You can enable SAML in your Cloudsmith organization settings:

You just need to provide your SAML Metadata XML. You can provide the Metadata XML via a URL, or by copy/pasting the Metadata XML from a file directly inline in the form

You can then enable SAML and optionally choose if you wish to enforce SAML-only authentication.

If you choose to enforce SAML-only authentication all users that belong to this org will be forced to authenticate via SAML-only, in order to access Cloudsmith. They will not be able to use password-based authentication or other social auth providers. This is more secure, but use caution to prevent lockouts.

Supported Providers

Whilst Cloudsmith should work with any generic SAML IdP, we officially support and provide documentation for a number of the most common providers. Please see the below for guides for each officially supported provider:

Other providers may be supported, as long as they have the capability to set up a generic SAML application. If you need help with an unlisted integration, you can still contact us!

SAML Landing Page (Login)

Once configured, you'll be able to access the SAML login page of your organization at the following URL:
https://cloudsmith.io/orgs/ORG/saml/login/

Where ORG is your organization's slug/identifier (what you would normally see in the URL when accessing your organization within Cloudsmith). If you're not sure what this is, just ask us.

Caveats

  • SCIM provisioning
    Cloudsmith doesn't currently implement SCIM (it's on our roadmap) and so doesn't have automatic deprovisioning. When organization members' sessions expire after their access is removed from the IdP, they aren't automatically removed from the organization (though they'll be unable to log in again). Existing tokens grant access to the organization even after their sessions expire. To remove access, organization admins can manually remove the authorized tokens and users from the organization.

Did this page help you?