How to securely access the W&B SDK and CLI with identity federation
We've improved how you can access our software developer kit and command line interface. Here's what you need to know.
Created on August 7|Last edited on August 7
Comment
Identity federation using common standards has enabled organizations of all sizes to leverage single sign-on (SSO) for accessing external SaaS applications. W&B Models and W&B Weave both support SSO for the application console across all deployment types, including SaaS cloud, dedicated cloud, and customer-managed instances. The other interfaces you use to access W&B—namely the software development kit (SDK) and command line Interface (CLI)—have required managing long-lived API keys and passwords for authentication. We wanted to improve that.
Today, we’re delighted to announce identity federation with W&B SDK. It allows users to sign in to W&B SDK and W&B CLI using their JSON Web Token (JWT) enterprise credentials. In addition, customers can bring external service identities from identity providers such as Okta and cloud service providers to automate AI development workflows, as long as the provider can issue JWT credentials and expose JSON Web Key Set (JWKS) for token validation. RFC 7523 is the underlying basis for this capability.
To get started, one of your organization’s W&B admins needs to set up a federation between your identity provider and your W&B organization. The admin user must configure the JWT issuer and its JSON Web Key Set (JWKS) in the settings of your W&B organization. Note that identity providers who don’t issue JWTs cannot federate with W&B.
After the federation setup is complete, W&B users in your organization can use SSO for SDK and CLI by following these steps:
- Sign in to your identity provider
- Fetch the necessary JWT
- Store the JWT in a file that’s configured in the environment variable WANDB_IDENTITY_TOKEN_FILE, and
- Use the SDK to access projects in W&B
You can automate the steps above so that when a user signs in, their JWT is configured on the AI compute nodes from where the W&B SDK is accessed.
JWTs allow for access using short-lived credentials. Therefore, depending on the expiry time configured within the issuer, the user JWT needs to be refreshed periodically, either manually or by using an issuer specific API.
The W&B SDK and CLI exchange the user JWT with a W&B internal access token, which is used to access the user's projects. This internal access token also has a default expiry duration, after which the W&B SDK and CLI automatically refresh the token as long as the user JWT is valid and not expired.
Apart from your users, it's possible for external service identities (also referred to as "service accounts" or "service principals") to access W&B using relevant JWTs. W&B already has built-in service accounts which have long-lived API keys. You can use a combination of built-in and external service accounts across AI workloads with different levels of data sensitivity to strike a balance between flexibility and simplicity. Since W&B doesn’t have knowledge of external service accounts by default, your W&B admins must configure an external service account for a W&B team before it can be used as part of automated workflows in that team.
Identity Federation with W&B SDK is available in preview as part of enterprise plans on SaaS cloud, Dedicated cloud, and Customer-managed instances. Reach out to your Weights & Biases team or to support@wandb.com for any questions. And feel free to read the docs here.
You can also check out other related features released earlier this year including Custom Roles, SCIM API and Restricted Projects.
Add a comment
Iterate on AI agents and models faster. Try Weights & Biases today.