1 - SDK でフェデレーテッドアイデンティティを使用する
W&B SDKを使用して、組織の資格情報を使用したサインインにアイデンティティ連携を利用します。W&Bの組織管理者が組織向けにSSOを設定している場合、すでに組織の資格情報を使用してW&BアプリのUIにサインインしています。この意味で、アイデンティティ連携はW&B SDKのためのSSOに似ていますが、JSON Web Tokens (JWTs) を直接使用しています。APIキーの代わりにアイデンティティ連携を使用できます。
RFC 7523は、SDKを使用したアイデンティティ連携の基盤を形成しています。
Enterprise
プランで Preview
として利用可能です - SaaS Cloud、Dedicated Cloud、およびセルフマネージドインスタンス。ご質問がある場合は、W&Bチームにお問い合わせください。identity provider
と JWT issuer
という用語は交換可能に使われています。この機能のコンテキストでは、両方とも同じものを指します。JWTイシュア設定
最初のステップとして、組織管理者はW&B組織とアクセス可能なJWTイシュアの間で連携を設定しなければなりません。
- 組織ダッシュボードの Settings タブに移動します。
- Authentication オプションで
Set up JWT Issuer
をクリックします。 - テキストボックスにJWTイシュアのURLを追加し、
Create
を押します。
W&Bは、${ISSUER_URL}/.well-known/oidc-configuration
パスでOIDCディスカバリードキュメントを自動的に探し、ディスカバリードキュメント内の関連URLでJSON Web Key Set (JWKS) を見つけようとします。JWKSは、JWTが関連するアイデンティティプロバイダーによって発行されたものであることを確認するために使用されるリアルタイム検証に利用されます。
W&BへのJWTを使用
JWTイシュアがW&B組織のために設定されると、ユーザーはそのアイデンティティプロバイダーによって発行されたJWTを使用して関連するW&B Projectsへのアクセスを開始できます。JWTを使用するメカニズムは次の通りです:
- 組織内で利用可能なメカニズムの1つを使用して、アイデンティティプロバイダーにサインインする必要があります。一部のプロバイダーはAPIやSDKを使用して自動化された方法でアクセスでき、他のプロバイダーは関連するUIを使用してのみアクセス可能です。詳細については、W&B組織管理者やJWTイシュアの所有者にお問い合わせください。
- アイデンティティプロバイダーにサインインした後、JWTをセキュアな場所に保存し、環境変数
WANDB_IDENTITY_TOKEN_FILE
に絶対ファイルパスを設定してください。 - W&B SDKやCLIを使用してW&Bプロジェクトにアクセスします。SDKやCLIは自動的にJWTを検出し、JWTが正常に検証された後にそれをW&Bアクセストークンと交換します。W&Bアクセストークンは、AIワークフローを有効にするためにrun、メトリクス、アーティファクトのログを記録するための関連するAPIにアクセスするために使用されます。アクセストークンはデフォルトで
~/.config/wandb/credentials.json
のパスに保存されます。環境変数WANDB_CREDENTIALS_FILE
を指定することでそのパスを変更することができます。
JWTは、APIキー、パスワードなどの長期間の資格情報の欠点に対処するための短期間の資格情報として意図されています。あなたのアイデンティティプロバイダーで設定されたJWTの有効期限に応じて、JWTを継続的にリフレッシュし、環境変数 WANDB_IDENTITY_TOKEN_FILE
で参照されるファイルに保存されていることを確認する必要があります。
W&Bアクセストークンにもデフォルトの有効期限があり、SDKまたはCLIは、それがあなたのJWTを使用して自動的にリフレッシュしようとします。その時点でユーザーJWTが期限切れになってリフレッシュされていない場合、認証に失敗する可能性があります。可能であれば、W&B SDKやCLIを使用したAIワークロードの一部として、JWTの取得と有効期限後のリフレッシュメカニズムを実装するべきです。
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 または セルフマネージド インスタンスの場合、インスタンスレベルの環境変数SKIP_AUDIENCE_VALIDATION
をtrue
に設定してオーディエンスクレームの検証をスキップするか、wandb
をオーディエンスとして使用します。 - JWT内の
exp
クレームは、トークンが有効で期限が切れていないか、リフレッシュが必要であるかを確認するためにチェックされます。
外部サービスアカウント
W&Bは長期間のAPIキーを持つ組み込みのサービスアカウントを長年にわたりサポートしてきました。SDKとCLIのアイデンティティ連携機能を使用すると、外部サービスアカウントを持ち込むことができ、JWTを使用して認証することも可能です。ただし、それらが組織レベルで設定されている同じイシュアによって発行されている限りです。チーム管理者は、組み込みのサービスアカウントのように、チームの範囲内で外部サービスアカウントを設定することができます。
外部サービスアカウントを設定するには:
- チームの Service Accounts タブに移動します。
New service account
を押します。- サービスアカウントの名前を入力し、
Authentication Method
としてFederated Identity
を選択し、Subject
を提供してCreate
を押します。
外部サービスアカウントのJWT内の sub
クレームは、チーム管理者がチームレベルの Service Accounts タブでそのサブジェクトとして設定したものと同じである必要があります。このクレームは、JWT検証 の一環として検証されます。aud
クレームの要件は、人間のユーザーJWTと同様です。
W&Bへの外部サービスアカウントのJWTを使用するとき、通常、初期JWTを生成し、継続的にリフレッシュするワークフローを自動化する方が簡単です。外部サービスアカウントを使用してログに記録されたrunを人間ユーザーに帰属させる場合、組み込みサービスアカウントと同様に、AIワークフローのために環境変数 WANDB_USERNAME
または WANDB_USER_EMAIL
を設定することができます。
2 - SSO を LDAP で設定
資格情報を W&B Server の LDAP サーバーで認証します。次のガイドは W&B Server の設定を行う方法を説明しています。必須およびオプションの設定、システム設定 UI から LDAP 接続を設定する手順をカバーしています。また、アドレス、ベース識別名、属性など、LDAP 設定のさまざまな入力についての情報を提供します。これらの属性は W&B アプリ UI から、または環境変数を使用して指定できます。匿名バインドを設定するか、管理者 DN とパスワードでバインドすることができます。
LDAP 接続の設定
- W&B アプリに移動します。
- 右上のプロフィールアイコンを選択します。ドロップダウンから System Settings を選択します。
- Configure LDAP Client を切り替えます。
- フォームに詳細を追加します。各入力の詳細は、Configuring Parameters セクションを参照してください。
- Update Settings をクリックして設定をテストします。これにより、W&B サーバーとのテストクライアント/接続が確立されます。
- 接続が検証されたら、Enable LDAP Authentication を切り替え、Update Settings ボタンを選択します。
次の環境変数を使用して LDAP 接続を設定します。
環境変数 | 必須 | 例 |
---|---|---|
LOCAL_LDAP_ADDRESS |
はい | ldaps://ldap.example.com:636 |
LOCAL_LDAP_BASE_DN |
はい | email=mail,group=gidNumber |
LOCAL_LDAP_BIND_DN |
いいえ | cn=admin , dc=example,dc=org |
LOCAL_LDAP_BIND_PW |
いいえ | |
LOCAL_LDAP_ATTRIBUTES |
はい | email=mail , group=gidNumber |
LOCAL_LDAP_TLS_ENABLE |
いいえ | |
LOCAL_LDAP_GROUP_ALLOW_LIST |
いいえ | |
LOCAL_LDAP_LOGIN |
いいえ |
各環境変数の定義については Configuration parameters セクションを参照してください。明確さのために、環境変数の接頭辞 LOCAL_LDAP
を定義名から省略しました。
設定パラメータ
以下の表には、必須およびオプションの LDAP 設定を一覧し説明しています。
環境変数 | 定義 | 必須 |
---|---|---|
ADDRESS |
W&B Server をホストする VPC 内の LDAP サーバーのアドレスです。 | はい |
BASE_DN |
ディレクトリ内で検索を開始するルートパスであり、クエリを行うために必要です。 | はい |
BIND_DN |
LDAP サーバーに登録された管理者ユーザーのパスです。LDAP サーバーが未認証のバインドをサポートしていない場合、これが必要です。指定された場合、W&B Server はこのユーザーとして LDAP サーバーに接続します。指定されていない場合、W&B Server は匿名バインドを使用して接続します。 | いいえ |
BIND_PW |
管理者ユーザーのパスワードで、バインドを認証するために使用されます。空白の場合、W&B Server は匿名バインドを使用して接続します。 | いいえ |
ATTRIBUTES |
メールとグループ ID 属性名をコンマ区切りの文字列値として提供します。 | はい |
TLS_ENABLE |
TLS を有効にします。 | いいえ |
GROUP_ALLOW_LIST |
グループ許可リスト。 | いいえ |
LOGIN |
W&B Server に LDAP を使用して認証するかどうかを指定します。True または False を設定します。オプションとして、LDAP の設定をテストするために false に設定することができます。LDAP 認証を開始するには true に設定します。 |
いいえ |
3 - SSO を OIDC で設定
W&B サーバーは、OpenID Connect (OIDC) 互換のアイデンティティ プロバイダーをサポートしており、Okta、Keycloak、Auth0、Google、および Entra などの外部アイデンティティ プロバイダーを通じてユーザー アイデンティティとグループ メンバーシップを管理できます。
OpenID Connect (OIDC)
W&B サーバーは、外部アイデンティティプロバイダー (IdP) とのインテグレーションのために、次の OIDC 認証フローをサポートします。
- フォームポストを使用したインプリシットフロー
- コードエクスチェンジのための証明キーを使用した認可コードフロー (PKCE)
これらのフローはユーザーを認証し、必要なアイデンティティ情報 (ID トークンの形式) を W&B サーバーに提供してアクレス制御を管理します。
ID トークンは、ユーザーの名前、ユーザー名、メール、およびグループメンバーシップなど、ユーザーのアイデンティティ情報を含む JWT です。W&B サーバーはこのトークンを使用してユーザーを認証し、システム内で適切なロールやグループにマッピングします。
W&B サーバーのコンテキストでは、アクセストークンはユーザーを代表して API へのリクエストを認可しますが、W&B サーバーの主な関心はユーザー認証とアイデンティティであるため、ID トークンのみが必要です。
環境変数を使用して、Dedicated cloud の IAM オプションを設定するか、Self-managed インスタンスを設定することができます。
Dedicated cloud または Self-managed W&B サーバーインストールのためにアイデンティティ プロバイダーを設定する際は、さまざまな IdP に関するこれらのガイドラインに従ってください。SaaS バージョンの W&B を使用している場合は、組織の Auth0 テナントを設定するための支援を求めるには support@wandb.com に連絡してください。
AWS Cognito を認証に設定する手順は以下の通りです:
-
最初に AWS アカウントにサインインし、AWS Cognito アプリに移動します。
-
IdP にアプリケーションを設定するための許可されたコールバック URL を入力します:
http(s)://YOUR-W&B-HOST/oidc/callback
をコールバック URL として追加します。YOUR-W&B-HOST
を W&B ホストパスに置き換えます。
-
IdP がユニバーサルログアウトをサポートしている場合は、ログアウト URL を
http(s)://YOUR-W&B-HOST
に設定します。YOUR-W&B-HOST
を W&B ホストパスに置き換えます。たとえば、アプリケーションが
https://wandb.mycompany.com
で実行されている場合、YOUR-W&B-HOST
をwandb.mycompany.com
に置き換えます。下の画像は、AWS Cognito で許可されたコールバックとサインアウト URL を提供する方法を示しています。
wandb/local はデフォルトで
implicit
grant with theform_post
response type を使用します。また、wandb/local を設定して、PKCE Code Exchange フローを使用する
authorization_code
grant を実行することもできます。 -
アプリにトークンを届ける方法を AWS Cognito で設定するために、1 つ以上の OAuth グラントタイプを選択します。
-
W&B は特定の OpenID Connect (OIDC) スコープを要求します。AWS Cognito App から以下を選択してください:
- “openid”
- “profile”
- “email”
たとえば、AWS Cognito アプリの UI は以下の画像のようになります:
設定ページで Auth Method を選択するか、
OIDC_AUTH_METHOD
環境変数を設定して、どのグラントが wandb/local に適しているかを指定します。Auth Method を
pkce
に設定する必要があります。 -
クライアント ID および OIDC 発行者の URL が必要です。OpenID ディスカバリドキュメントは
$OIDC_ISSUER/.well-known/openid-configuration
で利用可能でなければなりません。たとえば、ユーザープール ID を User Pools セクションの App Integration タブから、Cognito IdP URL に追加することで発行者 URL を生成できます:
IDP URL には「Cognito ドメイン」を使用しないでください。Cognito は
https://cognito-idp.$REGION.amazonaws.com/$USER_POOL_ID
でそのディスカバリドキュメントを提供します。
Okta を認証に設定する手順は以下の通りです:
-
https://login.okta.com/ で Okta ポータルにログインします。
-
左側のサイドバーで Applications、そして再度 Applications を選択します。
-
“Create App integration” をクリックします。
-
“Create a new app integration” 画面で OIDC - OpenID Connect と Single-Page Application を選択し、次に「Next」をクリックします。
-
“New Single-Page App Integration” 画面で、次の内容を入力し「Save」をクリックします:
- アプリ統合名、例として “Weights & Biases”
- グラントタイプ: Authorization Code と Implicit (hybrid) の両方を選択
- サインイン リダイレクト URI: https://YOUR_W_AND_B_URL/oidc/callback
- サインアウト リダイレクト URI: https://YOUR_W_AND_B_URL/logout
- 割り当て: Skip group assignment for now を選択
-
作成したばかりの Okta アプリケーションの概要画面で、Client ID を Client Credentials の General タブの下に記録します:
-
Okta OIDC 発行者 URL を特定するには、左側のメニューで Settings そして Account を選択します。 Okta UI は Organization Contact の下に企業名を表示します。
OIDC 発行者 URL は https://COMPANY.okta.com
の形式です。該当する値で COMPANY を置き換えて、注意してください。
-
https://portal.azure.com/ で Azure ポータルにログインします。
-
「Microsoft Entra ID」サービスを選択します。
-
左側のサイドバーで「App registrations」を選択します。
-
上部で「New registration」をクリックします。
「アプリケーションの登録」画面で次の値を入力します:
-
名前を指定します。例として「Weights and Biases application」
-
デフォルトでは選択されたアカウントタイプは「この組織ディレクトリ内のアカウントのみ (デフォルトディレクトリのみ - シングルテナント)」です。必要に応じて修正してください。
-
リダイレクト URI を Web タイプで設定し、値は
https://YOUR_W_AND_B_URL/oidc/callback
-
「登録」をクリックします。
-
「アプリケーション (client) ID」と「ディレクトリ (テナント) ID」をメモしておいてください。
-
-
左側のサイドバーで、Authentication をクリックします。
-
Front-channel logout URL の下に次を指定します:
https://YOUR_W_AND_B_URL/logout
-
「保存」をクリックします。
-
-
左側のサイドバーで「Certificates & secrets」をクリックします。
- 「Client secrets」をクリックし、「New client secret」をクリックします。
「クライアントシークレットの追加」画面で次の値を入力します:
-
説明を入力します。例として「wandb」
-
「有効期限」はそのままにしておくか、必要に応じて変更します。
-
「追加」をクリックします。
-
シークレットの「値」をメモしておいてください。「シークレット ID」は不要です。
- 「Client secrets」をクリックし、「New client secret」をクリックします。
これで次の 3 つの値をメモしておいてください:
- OIDC クライアント ID
- OIDC クライアントシークレット
- OIDC 発行者 URL に必要なテナント ID
OIDC 発行者 URL は次の形式です:https://login.microsoftonline.com/${TenantID}/v2.0
W&B サーバーでの SSO 設定
SSO を設定するには、管理者権限と次の情報が必要です:
- OIDC クライアント ID
- OIDC 認証方法(
implicit
またはpkce
) - OIDC 発行者 URL
- OIDC クライアントシークレット (オプション; IdP の設定方法に依存します)
OIDC_CLIENT_SECRET
で指定してください。SSO の設定は、W&B サーバー UI を使用するか、wandb/local
pod に環境変数 を渡して設定することができます。環境変数が UI よりも優先されます。
LOCAL_RESTORE=true
環境変数を設定してインスタンスを再起動できます。これにより、一時的なパスワードがコンテナのログに出力され、SSO が無効になります。SSO の問題を解決したら、環境変数を削除して SSO を再度有効化する必要があります。System Console は System Settings ページの後継です。これは W&B Kubernetes Operator ベースのデプロイメントで利用可能です。
-
Access the W&B Management Console を参照してください。
-
Settings に移動し、次に Authentication を選択します。Type ドロップダウンで OIDC を選択します。
-
値を入力します。
-
Save をクリックします。
-
ログアウトし、IdP ログイン画面を使用して再度ログインします。
-
Weights&Biases インスタンスにサインインします。
-
W&B アプリに移動します。
-
ドロップダウンから System Settings を選択します:
-
発行者、クライアント ID、および認証方法を入力します。
-
Update settings を選択します。

LOCAL_RESTORE=true
環境変数を設定してインスタンスを再起動できます。これにより、一時的なパスワードがコンテナのログに出力され、SSO がオフになります。SSO の問題を解決したら、環境変数を削除して SSO を再度有効化する必要があります。セキュリティ・アサーション・マークアップ言語 (SAML)
W&B サーバーは SAML をサポートしていません。
4 - ワークフローを自動化するためにサービスアカウントを使用する
サービスアカウントは、チーム内のプロジェクト全体または複数チームにわたって、一般的なタスクを自動で実行できる人間でない(または機械の)ユーザーを表します。
- 組織の管理者は、組織のスコープでサービスアカウントを作成することができます。
- チームの管理者は、そのチームのスコープでサービスアカウントを作成することができます。
サービスアカウントの APIキー により、呼び出し元はサービスアカウントのスコープ内のプロジェクトを読み書きできます。
サービスアカウントは、W&B Modelsの実験管理を自動化したり、W&B Weaveのトレースをログ記録したりするために、複数のユーザーやチームによるワークフローを集中管理することを可能にします。また、WANDB_USERNAME
またはWANDB_USER_EMAIL
の環境変数を使用することにより、サービスアカウントで管理されているワークフローに人間ユーザーのアイデンティティを関連付けるオプションもあります。
組織スコープのサービスアカウント
組織スコープのサービスアカウントは、チームに関係なく、組織内のすべてのプロジェクトを読み書きする権限を持ちます。ただし、制限付きプロジェクトは例外です。制限付きプロジェクトにアクセスする前に、そのプロジェクトの管理者は明示的にサービスアカウントをプロジェクトに追加する必要があります。
組織管理者は、組織またはアカウントダッシュボードの Service Accounts タブから組織スコープのサービスアカウントの APIキー を取得できます。
新しい組織スコープのサービスアカウントを作成するには:
- 組織ダッシュボードの Service Accounts タブで New service account ボタンをクリックします。
- Name を入力します。
- サービスアカウントのデフォルトチームを選択します。
- Create をクリックします。
- 新しく作成されたサービスアカウントの横で Copy API key をクリックします。
- コピーした APIキー を秘密管理マネージャーまたは他の安全でアクセス可能な場所に保存します。
WANDB_ENTITY
変数が モデルトレーニング や生成AIアプリの環境に設定されていない場合に、ワークロードが失敗するのを防ぐのに役立ちます。異なるチームのプロジェクトに組織スコープのサービスアカウントを使用するには、そのチームに WANDB_ENTITY
環境変数を設定する必要があります。チームスコープのサービスアカウント
チームスコープのサービスアカウントは、そのチーム内のすべてのプロジェクトを読み書きできますが、そのチーム内の制限付きプロジェクトは除きます。制限付きプロジェクトにアクセスする前に、そのプロジェクトの管理者は明示的にサービスアカウントをプロジェクトに追加する必要があります。
チームの管理者として、 <WANDB_HOST_URL>/<your-team-name>/service-accounts
でチームスコープのサービスアカウントの APIキー を取得できます。あるいは、チームの Team settings で Service Accounts タブを参照してください。
チーム用の新しいチームスコープのサービスアカウントを作成するには:
- チームの Service Accounts タブで New service account ボタンをクリックします。
- Name を入力します。
- 認証メソッドとして Generate API key (Built-in) を選択します。
- Create をクリックします。
- 新しく作成されたサービスアカウントの横で Copy API key をクリックします。
- コピーした APIキー を秘密管理マネージャーまたは他の安全でアクセス可能な場所に保存します。
チームスコープのサービスアカウントを使用する モデルトレーニング や生成AIアプリの環境でチームを設定しないと、モデルのrunやweaveトレースがサービスアカウントの親チーム内の指定されたプロジェクトにログ記録されます。このようなシナリオでは、参照されているユーザーがサービスアカウントの親チームの一部でない限り、WANDB_USERNAME
または WANDB_USER_EMAIL
変数を使用したユーザー帰属は 機能しません。
外部サービスアカウント
Built-in サービスアカウントに加えて、W&B は アイデンティティのフェデレーション を使用して、JSON Web Tokens (JWTs) を発行できるアイデンティティプロバイダー (IdPs) とともに、W&B SDK と CLI を用いたチームスコープの 外部サービスアカウント もサポートしています。