Integrations/Ping Identity

Secure Cloudsmith access with Ping Identity SAML SSO

Cloudsmith supports SAML 2.0 single sign-on through Ping Identity and PingFederate, letting your organisation control access to artifact repositories using the same identity infrastructure you already trust. Connect your Ping Identity environment to Cloudsmith to enforce centralised authentication, automate team provisioning via SAML Group Sync, and eliminate the risk of orphaned credentials.

How we support Ping Identity

Cloudsmith integrates with Ping Identity and PingFederate to give your organisation a secure, centralised way to manage who can access your software artifacts.
    SAML 2.0 SSO
    Cloudsmith supports SAML 2.0 at the organisation level, so you can connect any Ping Identity product, including PingFederate and PingOne, as your identity provider without additional tooling.
    SAML Group Sync
    Map Ping Identity group attributes directly to Cloudsmith teams. When a user logs in via SSO, Cloudsmith automatically assigns them to the correct teams based on the attributes in the SAML assertion.
    SP-initiated and IdP-initiated SSO
    Cloudsmith supports both SP-initiated and IdP-initiated SSO flows, giving your teams flexibility in how users access the platform while staying compliant with your Ping Identity policy.
    Organisation-level access control
    SSO is configured at the Cloudsmith organisation level, so you can enforce a consistent authentication policy across all repositories, teams, and service accounts in your organisation.
    Metadata-based configuration
    Configure the integration by importing or exchanging SAML metadata between Ping Identity and Cloudsmith, reducing manual setup steps and the chance of misconfiguration.

Why teams integrate Cloudsmith with Ping Identity

Without a direct integration, managing developer access to artifact repositories outside your identity provider creates security gaps and admin overhead. Cloudsmith closes that gap.
Without CloudsmithDevelopers authenticate to Cloudsmith with separate usernames and passwords, creating credentials that live outside your Ping Identity lifecycle. Offboarding a user requires manual steps in multiple systems, leaving stale access behind.
With CloudsmithCloudsmith access is governed entirely by Ping Identity. When a user's account is disabled or removed in your IdP, their Cloudsmith access is revoked at the next login attempt, with no manual cleanup required.
Without CloudsmithTeams are managed manually in Cloudsmith, with no connection to the groups you already maintain in your directory. Keeping repository permissions in sync with org chart changes is time-consuming and error-prone.
With CloudsmithSAML Group Sync maps Ping Identity group attributes to Cloudsmith teams automatically. New starters are provisioned into the right teams on first login, and access changes propagate without any manual intervention.
Without CloudsmithThere is no audit trail linking Cloudsmith activity back to your central identity records. Security reviews require correlating logs across separate systems, making compliance reporting slow and incomplete.
With CloudsmithEvery Cloudsmith session is authenticated through Ping Identity, giving you a single authoritative record of who accessed what and when. Cloudsmith's audit logs tie back to the same identity, simplifying compliance evidence collection.

Frequently asked questions

  1. Cloudsmith supports any SAML 2.0-compliant identity provider, which includes PingFederate, PingOne, and PingOne for Enterprise. If your Ping product can be configured as a SAML IdP, it can be connected to Cloudsmith.

  2. You create a SAML application in your Ping Identity admin console, configure the Assertion Consumer Service (ACS) URL and Entity ID from Cloudsmith, and then supply Ping's SAML metadata back into Cloudsmith's SSO settings. Full steps are in the Cloudsmith documentation.

  3. Yes. Cloudsmith supports both SP-initiated SSO (where the user starts at Cloudsmith and is redirected to Ping Identity) and IdP-initiated SSO (where the user starts from the Ping Identity application portal).

  4. SAML Group Sync lets you map a group attribute from your Ping Identity SAML assertion to a team in your Cloudsmith organisation. When a user authenticates via SSO, Cloudsmith reads the group attribute and automatically adds or removes the user from the matching team. You must configure all group mappings before enabling the feature.

  5. Yes. Once SAML is configured, you can require SSO for all members of your Cloudsmith organisation. Users who attempt to log in with a username and password will be redirected to your Ping Identity IdP instead.

  6. At minimum, Cloudsmith requires the user's email address, passed as the SAML NameID or as a mapped attribute. Additional attributes such as group membership are needed if you want to use SAML Group Sync for automatic team provisioning.

  7. Once a user's account is disabled or removed in Ping Identity, they will be unable to authenticate via SAML on their next login attempt. Cloudsmith does not independently maintain a separate credential that would allow continued access after the IdP account is revoked.

  8. No. SSO is configured at the organisation level in Cloudsmith. Once Ping Identity is connected to your organisation, the authentication policy applies to all repositories and teams within that organisation.

  9. Yes, if SAML Group Sync is enabled and a user's SAML assertion does not include a mapping for a team they are currently in, they will be removed from that team on next login. Cloudsmith recommends configuring all group mappings before enabling Group Sync to avoid unintended access removal.

  10. SAML SSO is available on Cloudsmith's enterprise plans. Contact the Cloudsmith sales team to confirm which plan tier includes SSO and SAML Group Sync for your organisation's requirements.

Integrations

Discover more Cloudsmith Integrations