Single Sign-On (SSO) for W&B Enterprise isn’t just about convenience; it’s a fundamental shift in how your team accesses and interacts with your machine learning artifacts and experiments, creating a more secure and auditable environment.
Let’s see it in action. Imagine your team is using W&B. Without SSO, each user has their own W&B username and password. This means managing credentials, ensuring password complexity, and handling offboarding can become a significant administrative burden.
With SSO integrated, when a user tries to access W&B, they’re redirected to your organization’s identity provider (IdP) – think Okta, Azure AD, Google Workspace, etc.
User attempts to access W&B UI.
W&B redirects user to IdP for authentication.
User authenticates with their corporate credentials.
IdP sends a SAML assertion (or OIDC token) back to W&B.
W&B validates the assertion/token and logs the user in.
This flow means your existing security policies for password strength, multi-factor authentication (MFA), and account lifecycle management are automatically applied to W&B access.
The core problem W&B Enterprise SSO solves is centralized identity management for your ML team. Instead of a separate credential store for W&B, it leverages your existing, trusted identity infrastructure. This drastically reduces the attack surface related to credential theft and simplifies user provisioning/de-provisioning. When an employee leaves, disabling their account in your IdP immediately revokes their W&B access, ensuring no lingering access to sensitive project data.
Internally, W&B supports standard protocols like SAML 2.0 and OpenID Connect (OIDC). When you configure SSO, you’re essentially establishing a trust relationship between W&B (the Service Provider, SP) and your IdP (the Identity Provider, IdP). This involves exchanging metadata: W&B provides its SP metadata (entity ID, assertion consumer service URL), and your IdP provides its IdP metadata (entity ID, single sign-on service URL, signing certificate).
Here are the key levers you control during configuration:
- IdP Entity ID: The unique identifier for your identity provider.
- IdP SSO URL: The endpoint on your IdP where W&B will redirect users for authentication.
- IdP Signing Certificate: The public certificate used by W&B to verify the authenticity of assertions coming from your IdP.
- W&B SP Entity ID: The unique identifier for your W&B instance.
- W&B Assertion Consumer Service (ACS) URL: The endpoint on W&B where your IdP will send the SAML assertion after successful authentication.
- Attribute Mapping: This is crucial. You map attributes from your IdP (like email, first name, last name) to corresponding fields in W&B. The most important is mapping the
emailattribute, as this is typically used as the unique identifier for a user within W&B.
Beyond SSO, W&B Enterprise provides robust Audit Logs. These logs are a detailed, immutable record of who did what, when, and to which W&B resource. Think of them as the security camera footage for your ML operations. Every significant action – experiment creation, artifact upload, dashboard modification, user invitation, configuration change – is logged.
These logs are invaluable for:
- Security Monitoring: Detecting suspicious activity, unauthorized access attempts, or data exfiltration.
- Compliance: Meeting regulatory requirements (like GDPR, HIPAA, SOX) by demonstrating control and accountability over data and processes.
- Troubleshooting: Understanding the sequence of events that led to an error or unexpected outcome.
- Forensics: Investigating security incidents.
Audit logs can be accessed via the W&B UI for a defined retention period or exported programmatically via the API for long-term storage and analysis in your SIEM (Security Information and Event Management) system.
The compliance aspect is where SSO and Audit Logs truly shine together. By enforcing SSO, you ensure that only authenticated and authorized users from your organization can access W&B. The audit logs then provide an irrefutable record of their actions. This combination creates a strong control framework. For example, if a compliance audit requires you to prove that only specific individuals had access to a particular dataset artifact, you can cross-reference the SSO login records with the audit log entries showing access to that artifact.
One aspect often overlooked is the role of attribute mapping in SSO and its downstream effects on RBAC (Role-Based Access Control) within W&B. While W&B’s primary SSO integration focuses on authentication, the attributes sent by your IdP can be used to infer group memberships or roles. For instance, if your IdP sends a department attribute, you could potentially use this information, in conjunction with W&B’s RBAC features, to automatically assign users to specific W&B teams or grant them certain permissions upon their first login. This allows for dynamic, policy-driven access control that scales with your organization’s identity management.
With SSO and audit logs in place, the next logical step is often exploring how to integrate W&B’s data and metadata into your broader data governance and MLOps pipelines.