メインコンテンツへスキップ
アイデンティティフェデレーションを使用すると、組織の認証情報を使って W&B SDK 経由でサインインできます。W&B 組織管理者が組織向けに SSO を設定している場合、すでに W&B アプリの UI へのサインインに組織の認証情報を使用しています。その意味で、アイデンティティフェデレーションは、JSON Web Token（JWT）を直接使用する、W&B SDK 向けの SSO のようなものです。APIキーの代替として、アイデンティティフェデレーションを使用できます。 RFC 7523 は、SDK におけるアイデンティティフェデレーションの基盤となる仕様です。
アイデンティティフェデレーションは、すべてのプラットフォームタイプ（SaaS Cloud、Dedicated Cloud、Self-Managed インスタンス）の Enterprise プランで Preview として利用できます。ご不明な点がある場合は、担当の W&B チームにお問い合わせください。
本ドキュメントでは、identity provider と JWT issuer という用語は同じ意味で使用します。この機能のコンテキストでは、どちらも同一の対象を指します。

​
JWT issuer のセットアップ

最初の手順として、組織管理者が、あなたの W&B 組織とインターネットからアクセス可能な JWT issuer の間でフェデレーションを構成する必要があります。
  • 組織のダッシュボードで Settings タブに移動します
  • Authentication オプションで Set up JWT Issuer をクリックします
  • テキストボックスに JWT issuer の URL を入力し、Create をクリックします
W&B は自動的に、${ISSUER_URL}/.well-known/openid-configuration パスにある OIDC ディスカバリードキュメントを探し、そのディスカバリードキュメント内の該当する URL から JSON Web Key Set (JWKS) を取得しようとします。JWKS は、JWT が該当するアイデンティティプロバイダ (IdP) によって発行されたものであることをリアルタイムに検証するために使用されます。

​
JWT を使用して W&B にアクセスする

JWT issuer が W&B 組織向けにセットアップされると、ユーザーはそのアイデンティティプロバイダーによって発行された JWT を使って、該当する W&B プロジェクトにアクセスできるようになります。JWT を使用する仕組みは次のとおりです。
  • 組織で利用可能ないずれかの方法を用いて、アイデンティティプロバイダーにサインインする必要があります。プロバイダーによっては、API や SDK を用いて自動的にアクセスできるものもあれば、対応する UI を用いてのみアクセスできるものもあります。詳細については、W&B 組織の管理者または JWT issuer のオーナーに問い合わせてください。
  • アイデンティティプロバイダーへのサインイン後に JWT を取得したら、それを安全な場所にあるファイルに保存し、その絶対ファイルパスを環境変数 WANDB_IDENTITY_TOKEN_FILE に設定します。
  • W&B SDK または CLI を使用して W&B プロジェクトにアクセスします。SDK または CLI は JWT を自動的に検出し、JWT が正常に検証された後に、それを W&B アクセストークンに交換します。W&B アクセストークンは、run、メトリクス、アーティファクトなどを記録することで AI ワークフローを有効化するために、関連する API にアクセスする際に使用されます。アクセストークンはデフォルトでは ~/.config/wandb/credentials.json パスに保存されます。環境変数 WANDB_CREDENTIALS_FILE を指定することでそのパスを変更できます。
JWT は、APIキーやパスワードなどの長期認証情報の問題点に対処するための、短期認証情報として設計されています。アイデンティティプロバイダーで設定された 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 クレームは、組織レベルで設定された issuer URL と一致している必要があります。
  • JWT 内の sub クレームは、W&B 組織で設定されているユーザーのメールアドレスと一致している必要があります。
  • JWT 内の aud クレームは、AI ワークフローの一部としてアクセスしているプロジェクトが属している W&B 組織の名前と一致している必要があります。Dedicated Cloud または Self-Managed インスタンスの場合、インスタンスレベルの環境変数 SKIP_AUDIENCE_VALIDATION を true に設定して audience クレームの検証をスキップするか、audience として wandb を使用できます。
  • JWT 内の exp クレームは、トークンが有効かどうか、または期限切れでリフレッシュが必要かどうかを確認するためにチェックされます。

​
外部サービスアカウント

W&B では、長期間有効な APIキー を持つ組み込みサービスアカウントを、以前からサポートしています。SDK と CLI 向けのアイデンティティフェデレーション機能により、JWT を認証に使用する外部サービスアカウントも利用できます。ただし、それらの JWT は、組織レベルで設定されているものと同じ発行者により発行されている必要があります。チーム管理者は、組み込みサービスアカウントと同様に、チームのスコープ内で外部サービスアカウントを設定できます。 外部サービスアカウントを設定するには:
  • チームの Service Accounts タブに移動します
  • New service account をクリックします
  • サービスアカウントの名前を入力し、Authentication Method として Federated Identity を選択し、Subject を指定して Create をクリックします
外部サービスアカウントの JWT 内の sub クレームは、チーム管理者がチームレベルの Service Accounts タブでサブジェクトとして設定する値と同じである必要があります。そのクレームは JWT validation の一部として検証されます。aud クレームの要件は、人間のユーザー用の JWT と同様です。 外部サービスアカウントの JWT を使って W&B にアクセスする 場合、初回の JWT の生成と継続的な更新を自動化する方が、一般的には簡単です。外部サービスアカウントを使用して記録された run を人間のユーザーに帰属させたい場合は、組み込みサービスアカウントの場合と同様に、AI ワークフロー向けに環境変数 WANDB_USERNAME または WANDB_USER_EMAIL を設定できます。
W&B は、柔軟性とシンプルさのバランスを取るために、データの機微度が異なる AI ワークロード全体で、組み込みサービスアカウントと外部サービスアカウントを組み合わせて使用することを推奨します。