これは、このセクションの複数ページの印刷可能なビューです。 印刷するには、ここをクリックしてください.

このページの通常のビューに戻る.

Authentication

1 - Configure SSO with LDAP

W&B サーバー LDAP サーバーで認証情報を認証します。次のガイドでは、W&B サーバーの 設定を構成する方法について説明します。必須およびオプションの設定、システム設定 UI から LDAP 接続を構成する手順について説明します。また、アドレス、ベース識別名、属性など、LDAP 設定のさまざまな入力に関する情報も提供します。これらの属性は、W&B App UI または 環境変数を使用して指定できます。匿名バインド、または管理者 DN とパスワードを使用したバインドのいずれかをセットアップできます。

LDAP 接続を構成する

  1. W&B App に移動します。
  2. 右上からプロフィール アイコンを選択します。ドロップダウンから、[システム 設定] を選択します。
  3. [LDAP クライアントを構成] を切り替えます。
  4. フォームに詳細を追加します。各入力の詳細については、[パラメータの構成] セクションを参照してください。
  5. [設定の更新] をクリックして、設定をテストします。これにより、W&B サーバーとのテスト クライアント/接続が確立されます。
  6. 接続が確認されたら、[LDAP 認証を有効にする] を切り替え、[設定の更新] ボタンを選択します。

次の 環境変数を使用して 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 いいえ

各 環境変数の定義については、設定 パラメータ セクションを参照してください。わかりやすくするために、環境変数プレフィックス LOCAL_LDAP が定義名から省略されていることに注意してください。

設定 パラメータ

次の表に、必須およびオプションの LDAP 構成を示し、説明します。

環境変数 定義 必須
ADDRESS これは、W&B サーバーをホストする VPC 内の LDAP サーバーの アドレスです。 はい
BASE_DN ルート パスは検索の開始元であり、この ディレクトリーにクエリを実行するために必要です。 はい
BIND_DN LDAP サーバーに登録されている管理 ユーザーのパス。LDAP サーバーが認証されていないバインドをサポートしていない場合に必要です。指定した場合、W&B サーバーはこの ユーザーとして LDAP サーバーに接続します。それ以外の場合、W&B サーバーは匿名バインドを使用して接続します。 いいえ
BIND_PW 管理 ユーザーのパスワード。これはバインドの認証に使用されます。空白のままにすると、W&B サーバーは匿名バインドを使用して接続します。 いいえ
ATTRIBUTES メールとグループ ID の属性名をコンマ区切りの文字列値として指定します。 はい
TLS_ENABLE TLS を有効にします。 いいえ
GROUP_ALLOW_LIST グループ許可リスト。 いいえ
LOGIN これは、W&B サーバーに LDAP を使用して認証するように指示します。True または False に設定します。オプションで、LDAP 構成をテストするために false に設定します。LDAP 認証を開始するには、これを true に設定します。 いいえ

2 - Configure SSO with OIDC

W&B Server の OpenID Connect (OIDC) 互換アイデンティティプロバイダーのサポートにより、Okta、Keycloak、Auth0、Google、Entra などの外部アイデンティティプロバイダーを介したユーザーアイデンティティとグループメンバーシップの管理が可能になります。

OpenID Connect (OIDC)

W&B Server は、外部 Identity Provider (IdP) との統合のために、以下の OIDC 認証フローをサポートしています。

  1. フォームポストによる暗黙的フロー
  2. Proof Key for Code Exchange (PKCE) を使用した認証コードフロー

これらのフローはユーザーを認証し、アクセス制御を管理するために必要なアイデンティティ情報 (ID トークンの形式) を W&B Server に提供します。

ID トークンは、ユーザーの名前、ユーザー名、メール、グループメンバーシップなどのユーザーのアイデンティティ情報を含む JWT です。W&B Server はこのトークンを使用してユーザーを認証し、システム内の適切なロールまたはグループにマップします。

W&B Server のコンテキストでは、アクセス トークンはユーザーに代わって API へのリクエストを承認しますが、W&B Server の主な関心事はユーザー認証とアイデンティティであるため、ID トークンのみが必要です。

環境変数を使用して、IAM オプションを設定 して、専用クラウド または Self-managed インスタンスを構成できます。

専用クラウド または Self-managed W&B Server インストール用に Identity Provider を構成するには、次のガイドラインに従って、さまざまな IdP に従ってください。W&B の SaaS バージョンを使用している場合は、support@wandb.com に連絡して、組織の Auth0 テナントの構成を支援してください。

認証に AWS Cognito を設定するには、以下の手順に従ってください。

  1. まず、AWS アカウントにサインインし、AWS Cognito アプリケーションに移動します。

    認証ではなく認証に OIDC を使用する場合、パブリッククライアントはセットアップを簡素化します

  2. IdP でアプリケーションを構成するために、許可されたコールバック URL を指定します。

    • コールバック URL として http(s)://YOUR-W&B-HOST/oidc/callback を追加します。YOUR-W&B-HOST を W&B ホストパスに置き換えます。

  3. 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 は、デフォルトで form_post 応答タイプによる implicit 付与 を使用します。

    PKCE Code Exchange フローを使用する authorization_code 付与を実行するように wandb/local を構成することもできます。

  4. AWS Cognito がトークンをアプリに配信する方法を構成するために、1 つ以上の OAuth 付与タイプを選択します。

  5. W&B には特定の OpenID Connect (OIDC) スコープが必要です。AWS Cognito アプリから以下を選択します。

    • “openid”
    • “profile”
    • “email”

    たとえば、AWS Cognito アプリの UI は次の図のようになります。

    必須フィールド

    設定ページで Auth Method を選択するか、OIDC_AUTH_METHOD 環境変数を設定して、wandb/local にどの付与を行うかを指示します。

    Auth Method を pkce に設定する必要があります。

  6. クライアント ID と OIDC 発行者の URL が必要です。OpenID ディスカバリドキュメントは $OIDC_ISSUER/.well-known/openid-configuration で利用可能である必要があります。

    たとえば、ユーザープール セクション内の アプリの統合 タブから Cognito IdP URL にユーザープール ID を追加して、発行者 URL を生成できます。

    AWS Cognito の発行者 URL のスクリーンショット

    IDP URL に “Cognito ドメイン” を使用しないでください。Cognito は、https://cognito-idp.$REGION.amazonaws.com/$USER_POOL_ID でディスカバリドキュメントを提供します。

Okta を認証用に設定するには、以下の手順に従ってください。

  1. https://login.okta.com/ で Okta ポータルにログインします。

  2. 左側で、Applications を選択し、次に Applications をもう一度選択します。

  3. 「Create App integration」をクリックします。

  4. 「Create a new app integration」という画面で、OIDC - OpenID Connect と Single-Page Application を選択します。次に、「Next」をクリックします。

  5. 「New Single-Page App Integration」という画面で、以下の値を入力して Save をクリックします。

    • アプリケーション統合名（例: “Weights & Biases”）
    • 付与タイプ: Authorization Code と Implicit (hybrid) の両方を選択します
    • Sign-in redirect URIs: https://YOUR_W_AND_B_URL/oidc/callback
    • Sign-out redirect URIs: https://YOUR_W_AND_B_URL/logout
    • Assignments: Skip group assignment for now を選択します

  6. 作成した Okta アプリケーションの概要画面で、General タブの Client Credentials の下の Client ID をメモします。

  7. Okta OIDC Issuer URL を識別するには、左側の Settings を選択し、次に Account を選択します。 Okta UI には、Organization Contact の下に会社名が表示されます。

OIDC 発行者 URL の形式は https://COMPANY.okta.com です。COMPANY を対応する値に置き換えます。メモしておいてください。

  1. Azure ポータル (https://portal.azure.com/) にログインします。

  2. 「Microsoft Entra ID」サービスを選択します。

  3. 左側で、「App registrations」を選択します。

  4. 上部で、「New registration」をクリックします。

    「Register an application」という画面で、以下の値を入力します。

    • 名前を指定します（例: “Weights and Biases application”）

    • デフォルトでは、選択されているアカウントの種類は「Accounts in this organizational directory only (Default Directory only - Single tenant)」です。必要に応じて変更します。

    • リダイレクト URI をタイプ Web で値 https://YOUR_W_AND_B_URL/oidc/callback で構成します

    • 「Register」をクリックします。

    • 「Application (client) ID」と「Directory (tenant) ID」をメモします。

  5. 左側で、Authentication をクリックします。

    • Front-channel logout URL の下で、https://YOUR_W_AND_B_URL/logout を指定します。

    • 「Save」をクリックします。

  6. 左側で、「Certificates & secrets」をクリックします。

    • 「Client secrets」をクリックし、次に「New client secret」をクリックします。

      「Add a client secret」という画面で、以下の値を入力します。

      • 説明を入力します（例: “wandb”）
      • 「Expires」はそのままにするか、必要に応じて変更します。
      • 「Add」をクリックします。

    • シークレットの「Value」をメモします。「Secret ID」は必要ありません。

これで、次の 3 つの値をメモしておく必要があります。

  • OIDC クライアント ID
  • OIDC クライアントシークレット
  • テナント ID は OIDC Issuer URL に必要です

OIDC 発行者 URL の形式は https://login.microsoftonline.com/${TenantID}/v2.0 です

W&B Server で SSO をセットアップする

SSO を設定するには、管理者権限と以下の情報が必要です。

  • OIDC クライアント ID
  • OIDC 認証方式 (implicit または pkce)
  • OIDC Issuer URL
  • OIDC クライアントシークレット (オプション、IdP の設定方法によって異なります)

W&B Server UI を使用するか、環境変数 を wandb/local pod に渡すことによって、SSO を設定できます。環境変数は UI より優先されます。

システムコンソールは、システム設定ページの後継です。W&B Kubernetes Operator ベースのデプロイで使用できます。

  1. W&B 管理コンソールへのアクセス を参照してください。

  2. Settings に移動し、次に Authentication に移動します。Type ドロップダウンで OIDC を選択します。

  3. 値を入力します。

  4. Save をクリックします。

  5. ログアウトし、再度ログインします。今回は IdP ログイン画面を使用します。

  1. Weights&Biases インスタンスにサインインします。

  2. W&B アプリケーションに移動します。

  3. ドロップダウンから、System Settings を選択します。

  4. 発行者、クライアント ID、および認証方式を入力します。

  5. Update settings を選択します。

Security Assertion Markup Language (SAML)

W&B Server は SAML をサポートしていません。

3 - Use federated identities with SDK

Identity federation を使用して、W&B SDK 経由で組織の認証情報を使用してサインインします。W&B organization の管理者が organization 向けに SSO を設定している場合、すでに組織の認証情報を使用して W&B アプリの UI にサインインしているはずです。その意味で、identity federation は W&B SDK の SSO のようなものですが、JSON Web Tokens (JWT) を直接使用します。identity federation は、APIキー の代替として使用できます。

RFC 7523 は、SDK との identity federation の基礎を形成します。

JWT issuer の設定

最初の手順として、organization の管理者は、W&B organization と公開されている JWT issuer の間の federation を設定する必要があります。

  • organization の ダッシュボード で Settings タブに移動します
  • Authentication オプションで、Set up JWT Issuer を押します
  • テキストボックスに JWT issuer の URL を追加し、Create を押します

W&B は、${ISSUER_URL}/.well-known/oidc-configuration のパスで OIDC discovery document を自動的に検索し、discovery document 内の関連する URL で JSON Web Key Set (JWKS) を見つけようとします。JWKS は、JWT が関連する identity provider によって発行されたことを確認するために、JWT のリアルタイム検証に使用されます。

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

JWT issuer が W&B organization 用に設定されると、ユーザーはその identity provider によって発行された JWT を使用して、関連する W&B プロジェクト へのアクセスを開始できます。JWT を使用するメカニズムは次のとおりです。

  • organization で利用可能なメカニズムのいずれかを使用して、identity provider にサインインする必要があります。一部のプロバイダーには、API または SDK を使用して自動化された方法でアクセスできますが、関連する UI を使用してのみアクセスできるプロバイダーもあります。詳細については、W&B organization の管理者または JWT issuer の所有者にお問い合わせください。
  • identity provider へのサインイン後に JWT を取得したら、安全な場所にファイルに保存し、環境変数 WANDB_IDENTITY_TOKEN_FILE に絶対ファイルパスを設定します。
  • W&B SDK または CLI を使用して W&B project にアクセスします。SDK または CLI は、JWT を自動的に検出し、JWT が正常に検証された後、W&B access token と交換する必要があります。W&B access token は、AI ワークフローを有効にするための関連する API にアクセスするために使用されます。つまり、run、メトリクス、Artifacts などを ログ に記録します。access token は、デフォルトで ~/.config/wandb/credentials.json のパスに保存されます。環境変数 WANDB_CREDENTIALS_FILE を指定することで、そのパスを変更できます。

JWT の検証

JWT を W&B access token と交換し、project にアクセスする ワークフロー の一部として、JWT は次の検証を受けます。

  • JWT 署名は、W&B organization レベルで JWKS を使用して検証されます。これは最初の防御線であり、これが失敗した場合、JWKS または JWT の署名方法に問題があることを意味します。
  • JWT の iss クレームは、organization レベルで設定された issuer URL と同じである必要があります。
  • JWT の sub クレームは、W&B organization で設定されているユーザーのメールアドレスと同じである必要があります。
  • JWT の aud クレームは、AI ワークフローの一部としてアクセスしている project を収容する W&B organization の名前と同じである必要があります。Dedicated Cloud または Self-managed インスタンスの場合、インスタンスレベルの環境変数 SKIP_AUDIENCE_VALIDATION を true に設定して、オーディエンスクレームの検証をスキップするか、オーディエンスとして wandb を使用できます。
  • JWT の exp クレームは、トークンが有効かどうか、または期限切れで更新が必要かどうかを確認するためにチェックされます。

外部サービスアカウント

W&B は、有効期間の長い APIキー を持つ組み込みのサービスアカウントを長年サポートしてきました。SDK および CLI 向けの identity federation 機能を使用すると、organization レベルで設定されているのと同じ issuer によって発行されている限り、JWT を認証に使用できる外部サービスアカウントも導入できます。team 管理者は、組み込みのサービスアカウントと同様に、team のスコープ内で外部サービスアカウントを設定できます。

外部サービスアカウントを設定するには:

  • team の Service Accounts タブに移動します
  • New service account を押します
  • サービスアカウントの名前を入力し、Authentication Method として Federated Identity を選択し、Subject を入力して、Create を押します

外部サービスアカウントの JWT の sub クレームは、team 管理者が team レベルの Service Accounts タブでサブジェクトとして設定したものと同じである必要があります。そのクレームは、JWT の検証 の一部として検証されます。aud クレームの要件は、ヒューマンユーザー JWT の要件と同様です。

外部サービスアカウントの JWT を使用して W&B にアクセスする 場合、通常は、初期 JWT を生成し、継続的に更新する ワークフロー を自動化する方が簡単です。外部サービスアカウントを使用して ログ に記録された run をヒューマンユーザーに帰属させたい場合は、組み込みのサービスアカウントの場合と同様に、AI ワークフローの環境変数 WANDB_USERNAME または WANDB_USER_EMAIL を設定できます。

4 - Use service accounts to automate workflows

組織とチームのスコープを持つサービスアカウントを使用して、自動化された、または非インタラクティブな ワークフロー を管理します。

サービスアカウントは、チーム内またはチーム間で、プロジェクトを横断して共通タスクを自動的に実行できる、人間ではないまたは機械の ユーザー を表します。

  • 組織の 管理者 は、組織の スコープ で サービスアカウント を作成できます。
  • チーム の 管理者 は、その チーム の スコープ で サービスアカウント を作成できます。

サービスアカウント の APIキー を使用すると、呼び出し元は サービスアカウント の スコープ 内の プロジェクト から読み取りまたは書き込みができます。

サービスアカウント を使用すると、複数の ユーザー または チーム による ワークフロー の集中管理、W&B Models の 実験管理 の自動化、または W&B Weave の トレース の ログ記録 が可能になります。 環境変数 WANDB_USERNAME または WANDB_USER_EMAIL のいずれかを使用することにより、人間の ユーザー の ID を サービスアカウント によって管理される ワークフロー に関連付けるオプションがあります。

組織スコープ の サービスアカウント

組織に スコープ された サービスアカウント は、 制限付き プロジェクト を除き、 チーム に関係なく、組織内のすべての プロジェクト で読み取りおよび書き込みの権限を持ちます。組織スコープ の サービスアカウント が 制限付き プロジェクト に アクセス するには、その プロジェクト の 管理者 が サービスアカウント を プロジェクト に明示的に追加する必要があります。

組織の 管理者 は、組織またはアカウント ダッシュボード の [ Service Accounts ] タブから、組織スコープ の サービスアカウント の APIキー を取得できます。

新しい組織スコープ の サービスアカウント を作成するには:

  • 組織 ダッシュボード の [ Service Accounts ] タブにある [ New service account ] ボタンをクリックします。
  • [ Name ] を入力します。
  • サービスアカウント のデフォルト チーム を選択します。
  • [ Create ] をクリックします。
  • 新しく作成された サービスアカウント の横にある [ Copy API key ] をクリックします。
  • コピーした APIキー を、シークレットマネージャーまたはその他の安全で アクセス 可能な場所に保存します。

チームスコープ の サービスアカウント

チームスコープ の サービスアカウント は、その チーム 内のすべての プロジェクト で読み取りおよび書き込みができます。ただし、その チーム 内の 制限付き プロジェクト は除きます。チームスコープ の サービスアカウント が 制限付き プロジェクト に アクセス するには、その プロジェクト の 管理者 が サービスアカウント を プロジェクト に明示的に追加する必要があります。

チーム の 管理者 として、チームスコープ の サービスアカウント の APIキー を <WANDB_HOST_URL>/<your-team-name>/service-accounts で取得できます。または、チーム の [ 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 (JWT) を発行できる ID プロバイダー (IdP) との Identity federation を使用して、W&B SDK および CLI を使用した チーム スコープ の External service accounts もサポートしています。