Snyk’s enterprise SSO integration doesn’t just let users log in; it fundamentally shifts how your organization manages access and enforces security policies across developer tooling.
Let’s see it in action. Imagine a developer, Alice, needs to access Snyk. Instead of a separate Snyk password, she’ll be redirected to your company’s identity provider (IdP) – say, Okta. She logs in with her corporate credentials. Upon successful authentication, Okta sends a SAML assertion or OIDC token back to Snyk, confirming Alice’s identity and her group memberships. Snyk then uses this information to grant her access, potentially with permissions specific to her role within the organization.
// Example SAML Assertion Snippet (simplified)
{
"saml:AttributeStatement": [
{
"saml:Attribute": {
"Name": "email",
"NameFormat": "urn:oasis:names:tc:SAML:2.0:attrname-format:uri",
"saml:AttributeValue": "alice@example.com"
}
},
{
"saml:Attribute": {
"Name": "groups",
"NameFormat": "urn:oasis:names:tc:SAML:2.0:attrname-format:uri",
"saml:AttributeValue": [
"engineering",
"security-team"
]
}
}
]
}
This integration solves the problem of fragmented identity management. Instead of managing passwords and access for each tool individually, you centralize it within your existing IdP. This means:
- Simplified User Onboarding/Offboarding: When a new employee joins, granting them Snyk access is as simple as adding them to the correct group in your IdP. When they leave, revoking access from the IdP automatically locks them out of Snyk.
- Enhanced Security Posture: You can enforce your organization’s password policies, multi-factor authentication (MFA) requirements, and conditional access rules consistently across all integrated applications, including Snyk.
- Reduced Administrative Overhead: IT and security teams spend less time on user provisioning and deprovisioning, password resets, and manual access reviews.
Snyk supports two primary protocols for SSO: Security Assertion Markup Language (SAML) and OpenID Connect (OIDC).
SAML is a well-established XML-based standard. When a user tries to access Snyk, Snyk (the Service Provider, SP) redirects the user to the IdP. The IdP authenticates the user and sends back a SAML assertion containing user attributes (like email, name, and group memberships) and an authorization decision. Snyk verifies this assertion using metadata exchanged during setup.
OIDC is a modern, JSON-based protocol built on top of OAuth 2.0. It’s often considered simpler to implement and more mobile-friendly. In OIDC, after authentication by the IdP, Snyk receives an ID token (a JWT) and potentially an access token. The ID token contains verifiable claims about the authenticated user.
The core configuration involves a trust relationship between Snyk and your IdP. This is established by exchanging metadata:
- Snyk’s SP Metadata: Snyk provides an SP metadata URL or file that you upload to your IdP. This tells the IdP about Snyk’s endpoints for receiving authentication requests and responses.
- IdP Metadata: Your IdP provides an IdP metadata URL or file that you upload to Snyk. This contains the IdP’s signing certificates, its Single Sign-On (SSO) URL, and Single Logout (SLO) URL.
You’ll also configure attribute mappings. This is crucial for Snyk to understand user identity and roles. For example, you’ll map the attribute from your IdP that contains the user’s email address to Snyk’s email attribute. Similarly, you’ll map attributes for group memberships if you intend to use group-based role assignments in Snyk.
Consider this configuration in Snyk for SAML:
{
"authentication": {
"saml": {
"enabled": true,
"idpMetadataUrl": "https://your-idp.com/snyk/metadata.xml",
"spEntityId": "https://app.snyk.io/saml/your-org-id",
"attributeMappings": {
"email": "urn:oid:0.9.2342.19200300.100.1.3", // OID for email
"groups": "https://your-idp.com/SAML/groups" // Custom attribute name
},
"roleMapping": [
{
"group": "snyk-admins",
"role": "admin"
},
{
"group": "snyk-developers",
"role": "developer"
}
]
}
}
}
When you configure attribute mappings, especially for groups, Snyk expects the exact value that your IdP sends. If your IdP sends groups as "engineering-team" but your Snyk role mapping is set to "engineering", the mapping will fail. This is a common point of confusion; always verify the raw attribute values sent by your IdP using its debug tools or SAML tracers.
The most surprising thing about this integration is how it enables fine-grained, dynamic access control based on attributes Snyk receives after authentication. You’re not just saying "Alice can log in"; you’re saying "Alice, because she’s in the security-team group and her department attribute is R&D, gets read-only access to projects tagged production." This dynamic authorization, driven by the IdP’s assertions, is where the real enterprise power lies, moving beyond simple authentication to robust access governance.
The next challenge you’ll face is configuring Just-In-Time (JIT) provisioning, which automatically creates Snyk users based on SAML/OIDC assertions.