Integrations/Okta

Centralise artifact access control with Okta

Cloudsmith connects directly to your Okta organisation via SAML 2.0 SSO and SCIM 2.0 provisioning, so your identity policies govern artifact access from day one. Map Okta groups to Cloudsmith teams, automate user lifecycle management, and enforce SAML-only authentication across every repository your engineers touch.

How we support Okta

Cloudsmith gives you a direct, standards-based path from your Okta directory to fine-grained artifact access control. Connect once and let your identity policies do the rest.
    SAML 2.0 Single Sign-On
    Authenticate your engineers against Cloudsmith using Okta as the SAML identity provider. Users reach your workspace via a dedicated SAML login URL and you can optionally enforce SAML-only access to eliminate credential sprawl.
    SCIM 2.0 User Provisioning
    Cloudsmith is SCIM 2.0-compliant. Automatically provision new users, deprovision leavers, and sync profile changes from Okta in real time, so access to your artifacts is always in step with your directory.
    SAML Group Sync
    Map Okta groups to Cloudsmith teams using SAML Group Attribute Statements. Users are automatically assigned to the right team and role the moment they log in, without any manual steps in Cloudsmith.
    Enforced SAML-Only Authentication
    Lock down your Cloudsmith workspace so all users must authenticate via Okta. No local passwords, no bypasses. Every access event is tied to a verified Okta identity.
    Full Audit Traceability
    Every package pull, push, and permission change is logged against the authenticated Okta identity. Cloudsmith's audit log gives you a complete, attributable record for compliance and incident review.

Why teams integrate Cloudsmith with Okta

Without a proper integration, Okta manages authentication but not artifact access. Cloudsmith closes that gap with SAML, SCIM, and group sync working together.
Without CloudsmithOkta controls who can log in to your apps, but artifact repositories stay on separate credentials. Engineers hold local Cloudsmith passwords that fall outside your identity governance scope.
With CloudsmithSAML 2.0 SSO ties every Cloudsmith login to your Okta identity. Enforce SAML-only authentication and local credentials are eliminated entirely, bringing artifact access inside your identity perimeter.
Without CloudsmithWhen someone joins or leaves, IT disables their Okta account but their Cloudsmith access lingers. Offboarding is a manual checklist item that gets missed under pressure, leaving former employees with live artifact access.
With CloudsmithSCIM 2.0 provisioning means Cloudsmith reflects your Okta directory automatically. Deprovision a user in Okta and their Cloudsmith access is revoked in real time, with no manual steps required.
Without CloudsmithAssigning team members to the right Cloudsmith repositories is done by hand. As org structure changes in Okta, Cloudsmith permissions drift out of sync and engineers either lack access they need or retain access they should not have.
With CloudsmithSAML Group Sync maps Okta groups to Cloudsmith teams automatically. Org changes in Okta flow through to repository permissions on the next login, keeping access aligned without any manual reconciliation.

Frequently asked questions

  1. Cloudsmith supports SAML 2.0 for single sign-on with Okta. You configure Okta as your SAML identity provider and provide the IdP metadata XML to Cloudsmith. SCIM 2.0 is also supported for automated user and group provisioning.

  2. Create a Cloudsmith application in Okta, configure the SAML settings, then copy the IdP metadata XML from the Sign On tab and paste it into your Cloudsmith workspace authentication settings. Full step-by-step instructions are in the Cloudsmith Okta documentation.

  3. Yes. Cloudsmith is SCIM 2.0-compliant. Enable SCIM in your Cloudsmith workspace settings, then configure the Cloudsmith application in Okta to use SCIM. You can then automatically provision new users, deprovision leavers, and sync profile updates from your Okta directory.

  4. Yes. SAML Group Sync lets you map Okta Group Attribute Statements to Cloudsmith teams. Configure the group attributes in your Okta application, then create the corresponding group sync mappings in Cloudsmith. Users are assigned to the correct team and role on login.

  5. Yes. Once SAML is configured, you can enable SAML-only authentication in your Cloudsmith workspace settings. This removes the ability to log in with local credentials, ensuring every access event goes through your Okta identity provider.

  6. With SCIM provisioning enabled, deprovisioning a user in Okta automatically revokes their Cloudsmith access in real time. Without SCIM, SSO-only configurations still prevent login, but SCIM ensures the account is fully removed from your workspace.

  7. You can use SAML SSO on its own for authentication, and add SCIM separately for lifecycle management. Most teams benefit from running both together: SAML handles authentication and SCIM keeps user accounts and group memberships in sync.

  8. Yes. Every action in Cloudsmith is logged against the authenticated user identity, regardless of whether they authenticated via SAML, SCIM, or API key. The audit log shows package events, permission changes, and login activity, all tied to the individual Okta user.

  9. SAML SSO and SCIM provisioning are available on Okta plans that support these protocols. Okta's SSO features are available from their standard Workforce Identity plans. Check your Okta subscription for specific feature availability.

  10. Yes. You can configure and test SAML and SCIM in Cloudsmith before enforcing SAML-only authentication. This lets you verify that group sync and provisioning are working correctly before cutting over, so your team can keep accessing Cloudsmith throughout the migration.

Integrations

Discover more Cloudsmith Integrations