メインコンテンツへスキップ
アイデンティティ フェデレーションを使用すると、W&B SDK経由で組織の認証情報を使ってサインインできます。W&B組織管理者が組織に対してSSOを設定している場合、W&B App UIにはすでに組織の認証情報でサインインしています。その意味では、アイデンティティ フェデレーションはW&B SDK向けのSSOに似ていますが、JSON Web Tokens (JWT) を直接使用する点が異なります。アイデンティティ フェデレーションは、APIキーの代替として使用できます。 RFC 7523は、SDKでのアイデンティティ フェデレーションの基盤となる仕様です。
アイデンティティ フェデレーションは、Multi-tenant Cloud、専用クラウド、セルフマネージドでプレビューとして利用できます。Enterprise ライセンスが必要です。詳細や サポートが必要な場合は、担当のAISEまたはサポートにお問い合わせください。
このドキュメントでは、identity providerとJWT issuerという用語を同じ意味で使います。どちらも、この機能の文脈では同じものを指します。

​
JWT issuer の設定

最初の step として、組織管理者は、お使いの 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 のリアルタイム検証に使用され、JWT が該当する identity provider によって発行されたことを確認します。

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

W&B 組織に対して JWT issuer が設定されると、ユーザーはその identity provider が発行した JWT を使用して、該当する W&B プロジェクトにアクセスできるようになります。JWT を使用する仕組みは次のとおりです。
  • 組織で利用可能な方法のいずれかを使用して、identity provider にサインインする必要があります。プロバイダーによっては API や SDK を使って自動的にアクセスできますが、適切な UI からしかアクセスできないものもあります。詳細については、W&B 組織の管理者または JWT issuer の所有者にお問い合わせください。
  • identity provider へのサインイン後に JWT を取得したら、安全な場所にあるファイルに保存し、そのファイルの絶対パスを環境変数 WANDB_IDENTITY_TOKEN_FILE に設定します。
  • W&B SDK または CLI を使用して W&B プロジェクトにアクセスします。SDK または CLI は、JWT が正常に検証されると、その JWT を自動的に検出して W&B アクセストークンに交換します。W&B アクセストークンは、AI ワークフローを実行するために必要な関連 API へのアクセスに使用されます。つまり、Runs、メトリクス、Artifacts などをログするために使用されます。アクセストークンはデフォルトで ~/.config/wandb/credentials.json に保存されます。このパスは、環境変数 WANDB_CREDENTIALS_FILE を指定することで変更できます。
JWT は、APIキーやパスワードなどの長期間有効な認証情報の欠点を補うため、短期間のみ有効な認証情報として設計されています。identity provider で設定された 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 組織の名と一致している必要があります。 専用クラウド または セルフマネージド インスタンスでは:
    • audience の検証をスキップするには、環境変数 FEDERATED_AUTH_AUDIENCES を wandb に設定できます。
    • 一部の組織では、audience に対して特定の要件があります。aud の値をカスタマイズするには、環境変数 FEDERATED_AUTH_AUDIENCES に、audience 値をカンマ区切りで並べた文字列を設定します。
  • JWT の exp クレームは、トークンが有効か、期限切れで更新が必要かどうかを確認するためにチェックされます。

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

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