You know the feeling—new engineer joins, someone scrambles to add them to every build, push permissions, and hope nothing breaks. Two months later, same person leaves, and half their tokens still live in a dusty TeamCity folder. SCIM integration exists to make that entire cycle automatic and sane.
SCIM, the System for Cross-domain Identity Management, keeps user and group data consistent between identity providers like Okta or Azure AD and target apps. TeamCity, JetBrains’ CI/CD platform, handles your pipelines and secrets with precision but has no native mechanism to sync identity data across systems. Connecting SCIM to TeamCity fixes that mismatch. It turns access management from a manual ritual into a living, policy-driven process.
When SCIM manages TeamCity accounts, your identity provider defines who can build, deploy, or view logs. Users arrive and leave automatically. Group membership translates directly into permissions, preventing orphaned tokens and accidental exposure. The logic is simple: TeamCity reads SCIM updates through its REST layer, applies them to internal roles, and mirrors your directory’s reality in near real time.
How do I connect SCIM and TeamCity?
Start with an identity provider that supports SCIM—Okta or JumpCloud are common choices. Create a SCIM app, map attributes for username, display name, and group ID. TeamCity consumes those attributes according to its user model. Once provisioned, it can poll for changes or receive them via push events. No plugin guesswork, just clean identity flow.
A few best practices matter. Keep your SCIM tokens short-lived and rotate them through AWS Secrets Manager or Vault. Align your RBAC schema before syncing so your least-privilege rules transfer correctly. Always test with a staging environment first—nothing ruins lunch like 200 build agents losing visibility because of a group rename.