ID フェデレーションは、SaaS Cloud、Dedicated Cloud、およびセルフマネージドインスタンスのすべてのプラットフォームタイプの
Enterprise プランで Preview として利用可能です。ご不明な点は W&B チームまでお問い合わせください。このドキュメントでは、
identity provider と JWT issuer という用語を同じ意味で使用しています。この機能のコンテキストでは、両者は同じものを指します。JWT 発行者の設定
最初のステップとして、組織管理者は W&B 組織と、パブリックにアクセス可能な JWT 発行者との間でフェデレーションを設定する必要があります。- 組織ダッシュボードの Settings タブに移動します
- Authentication オプションで、
Set up JWT Issuerをクリックします - テキストボックスに JWT 発行者の URL を入力し、
Createをクリックします
${ISSUER_URL}/.well-known/openid-configuration パスの OIDC ディスカボリドキュメントを自動的に検索し、その中の関連 URL から JSON Web Key Set (JWKS) を見つけようとします。JWKS は、JWT が関連する ID プロバイダーによって発行されたものであることを保証するために、JWT のリアルタイム検証に使用されます。
JWT を使用した W&B へのアクセス
W&B 組織に対して JWT 発行者が設定されると、ユーザーはその ID プロバイダーによって発行された JWT を使用して、関連する W&B Projects へのアクセスを開始できます。JWT を使用する仕組みは以下の通りです：- 組織で利用可能なメカニズムのいずれかを使用して、ID プロバイダーにサインインする必要があります。一部のプロバイダーは API や SDK を使用して自動的にアクセスできますが、UI を通じてのみアクセス可能なものもあります。詳細は W&B 組織の管理者または JWT 発行者の所有者に確認してください。
- ID プロバイダーにサインインして JWT を取得したら、それを安全な場所にあるファイルに保存し、環境変数
WANDB_IDENTITY_TOKEN_FILEにそのファイルの絶対パスを設定します。 - W&B SDK または CLI を使用して W&B プロジェクトにアクセスします。SDK または CLI は自動的に JWT を検出し、JWT が正常に検証された後、それを W&B アクセストークンと交換します。W&B アクセストークンは、AI ワークフローを有効にするための関連 API へのアクセス（Runs、メトリクス、アーティファクトなどの ログ 記録など）に使用されます。アクセストークンは、デフォルトで
~/.config/wandb/credentials.jsonパスに保存されます。環境変数WANDB_CREDENTIALS_FILEを指定することで、このパスを変更できます。
JWT は、APIキー やパスワードなどの有効期間の長い認証情報の欠点に対処するための、短期間有効な認証情報として設計されています。ID プロバイダーで設定された JWT の有効期限に応じて、継続的に JWT を更新し、環境変数
WANDB_IDENTITY_TOKEN_FILE で参照されるファイルに保存されていることを確認する必要があります。W&B アクセストークンにもデフォルトの有効期間があり、期限が切れると SDK または CLI は JWT を使用して自動的に更新を試みます。その時点でユーザーの JWT も期限切れであり、更新されていない場合は、認証エラーが発生する可能性があります。可能であれば、JWT の取得および期限切れ後の更新メカニズムを、W&B SDK または CLI を使用する AI ワークロードの一部として実装する必要があります。JWT の検証
JWT を W&B アクセストークンに交換し、プロジェクトにアクセスするワークフローの一環として、JWT は以下の検証を受けます：- JWT の署名は、W&B 組織レベルの JWKS を使用して検証されます。これは最初の防御ラインであり、これに失敗した場合は、JWKS または JWT の署名方法に問題があることを意味します。
- JWT の
issクレームは、組織レベルで設定された発行者 URL と一致する必要があります。 - JWT の
subクレームは、W&B 組織で設定されているユーザーのメールアドレスと一致する必要があります。 - JWT の
audクレームは、AI ワークフローの一部としてアクセスしているプロジェクトを収容する W&B 組織の名前と一致する必要があります。Dedicated Cloud または Self-Managed インスタンスの場合、インスタンスレベルの環境変数SKIP_AUDIENCE_VALIDATIONをtrueに設定して対象（audience）クレームの検証をスキップするか、オーディエンスとしてwandbを使用するように設定できます。 - JWT の
expクレームがチェックされ、トークンが有効か、あるいは期限切れで更新が必要かが確認されます。
外部サービスアカウント
W&B は以前から、有効期間の長い APIキー を持つ組み込みのサービスアカウントをサポートしてきました。SDK および CLI の ID フェデレーション機能を使用すると、認証に JWT を使用できる外部サービスアカウントを導入することもできます。ただし、それらは組織レベルで設定されたものと同じ発行者によって発行されている必要があります。チーム管理者は、組み込みのサービスアカウントと同様に、チームのスコープ内で外部サービスアカウントを設定できます。 外部サービスアカウントを設定するには：- チームの Service Accounts タブに移動します
New service accountをクリックします- サービスアカウントの名前を入力し、
Authentication MethodとしてFederated Identityを選択し、Subjectを入力してCreateをクリックします
sub クレームは、チーム管理者がチームレベルの Service Accounts タブでサブジェクトとして設定したものと同じである必要があります。このクレームは JWT validation の一部として検証されます。aud クレームの要件は、人間のユーザーの JWT の場合と同様です。
外部サービスアカウントの JWT を使用して W&B にアクセスする場合、通常、初期 JWT の生成と継続的な更新のワークフローを自動化する方が簡単です。外部サービスアカウントを使用して記録された Runs を特定のユーザーに紐付けたい場合は、組み込みのサービスアカウントと同様に、AI ワークフローに環境変数 WANDB_USERNAME または WANDB_USER_EMAIL を設定できます。
W&B では、柔軟性とシンプルさのバランスをとるために、データの機密レベルが異なる AI ワークロード全体で、組み込みのサービスアカウントと外部のサービスアカウントを組み合わせて使用することをお勧めします。