アイデンティティとアクセス管理 (IAM)

• 1: 認証
• 1.1: SDK でフェデレーテッドアイデンティティを使用する
• 1.2: SSO を LDAP で設定
• 1.3: SSO を OIDC で設定
• 1.4: ワークフローを自動化するためにサービスアカウントを使用する
• 2: アクセス管理
• 2.1: あなたの組織を管理する
• 2.2: プロジェクトのアクセス制御を管理する
• 3: ユーザーとチームの管理を自動化する
• 4: ユーザー、グループ、およびロールを SCIM で管理する
• 5: 高度な IAM 設定

1 - 認証

1.1 - SDK でフェデレーテッドアイデンティティを使用する

W&B SDKを使用して、組織の資格情報を使用したサインインにアイデンティティ連携を利用します。W&Bの組織管理者が組織向けにSSOを設定している場合、すでに組織の資格情報を使用してW&BアプリのUIにサインインしています。この意味で、アイデンティティ連携はW&B SDKのためのSSOに似ていますが、JSON Web Tokens (JWTs) を直接使用しています。APIキーの代わりにアイデンティティ連携を使用できます。

RFC 7523は、SDKを使用したアイデンティティ連携の基盤を形成しています。

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検証

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 を設定することができます。

1.2 - SSO を LDAP で設定

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

LDAP 接続の設定

• W&B アプリ
• 環境変数

設定パラメータ

以下の表には、必須およびオプションの LDAP 設定を一覧し説明しています。

1.3 - SSO を OIDC で設定

W&B サーバーは、OpenID Connect (OIDC) 互換のアイデンティティ プロバイダーをサポートしており、Okta、Keycloak、Auth0、Google、および Entra などの外部アイデンティティ プロバイダーを通じてユーザー アイデンティティとグループ メンバーシップを管理できます。

OpenID Connect (OIDC)

W&B サーバーは、外部アイデンティティプロバイダー (IdP) とのインテグレーションのために、次の OIDC 認証フローをサポートします。

1. フォームポストを使用したインプリシットフロー
2. コードエクスチェンジのための証明キーを使用した認可コードフロー (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 に連絡してください。

• Cognito
• Okta
• Entra

W&B サーバーでの SSO 設定

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

• OIDC クライアント ID
• OIDC 認証方法（implicit または pkce）
• OIDC 発行者 URL
• OIDC クライアントシークレット (オプション; IdP の設定方法に依存します)

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

• System Console
• System settings

System Console は System Settings ページの後継です。これは W&B Kubernetes Operator ベースのデプロイメントで利用可能です。

1. Access the W&B Management Console を参照してください。

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

3. 値を入力します。

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

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

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

2. W&B アプリに移動します。

   

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

   

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

5. Update settings を選択します。

セキュリティ・アサーション・マークアップ言語 (SAML)

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

1.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_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 を用いたチームスコープの 外部サービスアカウント もサポートしています。

2 - アクセス管理

組織内でのユーザーとチームの管理

ユニークな組織ドメインで W&B に初めてサインアップしたユーザーは、その組織のインスタンス管理者ロールに割り当てられます。組織管理者は特定のユーザーにチーム管理者ロールを割り当てます。

チーム管理者は、チーム内で管理権限を持つ組織内のユーザーです。

組織管理者は、https://wandb.ai/account-settings/ の組織アカウント設定にアクセスして、ユーザーを招待したり、ユーザーの役割を割り当てたり更新したり、チームを作成したり、組織からユーザーを削除したり、請求管理者を割り当てたりすることができます。詳細については、ユーザーの追加と管理を参照してください。

組織管理者がチームを作成すると、インスタンス管理者またはチーム管理者は次のことができます：

• デフォルトでは、管理者のみがそのチームにユーザーを招待したり、チームからユーザーを削除したりできます。この振る舞いを変更するには、チーム設定を参照してください。
• チームメンバーの役割を割り当てたり更新したりします。
• 組織に参加した際に自動的に新しいユーザーをチームに追加します。

組織管理者とチーム管理者は、https://wandb.ai/<your-team-name> のチームダッシュボードを使用してチームを管理します。詳細とチームのデフォルトの公開範囲を設定するには、チームの追加と管理を参照してください。

特定のプロジェクトへの公開範囲の制限

W&B プロジェクトの範囲を定義して、誰がそのプロジェクトを閲覧、編集、そして W&B の run をサブミットできるかを制限します。プロジェクトを閲覧できる人を制限することは、特にチームが機密または秘密のデータを扱う場合に役立ちます。

組織管理者、チーム管理者、またはプロジェクトの所有者は、プロジェクトの公開範囲を設定および編集することができます。

詳細については、プロジェクトの公開範囲を参照してください。

2.1 - あなたの組織を管理する

組織の管理者として、組織内の個々のユーザーを管理し、チームを管理できます。

チーム管理者として、チームを管理できます。

組織内のユーザー管理を簡素化したい場合は、ユーザーとチームの管理を自動化するを参照してください。

組織名の変更

1. https://wandb.ai/home に移動します。
2. ページの右上隅にある ユーザーメニュー のドロップダウンを選択します。ドロップダウン内の アカウント セクションで 設定 を選択します。
3. 設定 タブ内で 一般 を選択します。
4. 名前を変更 ボタンを選択します。
5. 表示されるモーダル内に、新しい組織名を入力し、名前を保存 ボタンを選択します。

ユーザーの追加と管理

管理者として、組織のダッシュボードを使用して次のことを行います。

• ユーザーを招待または削除する。
• ユーザーの組織の役割を割り当てまたは更新し、カスタム役割を作成する。
• 請求管理者を割り当てる。

組織の管理者がユーザーを組織に追加する方法はいくつかあります。

1. 招待によるメンバー
2. SSOによる自動プロビジョニング
3. ドメインキャプチャ

シートと価格

以下の表は、Models と Weave のシートの仕組みをまとめたものです。

ユーザーを招待する

管理者は、組織内の特定のチームに加えてユーザーを組織に招待できます。

• Multi-tenant SaaS Cloud
• Dedicated or Self-managed

ユーザーの自動プロビジョニング

一致するメールドメインを持つW&Bユーザーは、SSOを設定し、SSOプロバイダーが許可した場合、SSOを使ってW&B組織にサインインすることができます。SSOはすべてのエンタープライズライセンスに利用可能です。

W&Bはデフォルトで自動プロビジョニングされたユーザーに「メンバー」役割を割り当てます。自動プロビジョニングされたユーザーの役割はいつでも変更可能です。

Dedicated cloudインスタンスおよびSelf-managedデプロイメントでは、SSOを使ったユーザーの自動プロビジョニングがデフォルトでオンになっています。自動プロビジョニングをオフにすることができ、特定のユーザーを選んでW&B組織に追加することができます。

以下のタブでは、デプロイメントタイプに基づいてSSOをオフにする方法を説明します：

• Dedicated cloud
• Self-managed

カスタム役割を作成する

組織の管理者は、View-Only または Member 役割に基づいて新しい役割を作成し、追加の許可を追加することで詳細なアクセス制御を実現できます。チーム管理者は、チームメンバーにカスタム役割を割り当てることができます。カスタム役割は組織レベルで作成され、チームレベルで割り当てられます。

カスタム役割を作成するには：

• Multi-tenant SaaS Cloud
• Dedicated or Self-managed

チーム管理者は、今後、チーム設定 からチームのメンバーにカスタム役割を割り当てることができます。

ドメインキャプチャ

ドメインキャプチャは、従業員があなたの会社の組織に参加する手助けをし、新しいユーザーが会社の管轄外で資産を作成することがないようにします。

• Multi-tenant SaaS Cloud
• Dedicated or Self-managed

ユーザーの役割を割り当てまたは更新する

組織内のすべてのメンバーは、W&B Models および Weave のための組織役割とシートを持っています。彼らのシートタイプによって、彼らの請求状況と各製品ラインで取ることのできるアクションが決まります。

組織に招待する際に、ユーザーに組織の役割を初めて割り当てます。後でどのユーザーの役割も変更できます。

組織内のユーザーは、以下のいずれかの役割を持つことができます：

ユーザーの役割を変更するには：

1. https://wandb.ai/home に移動します。
2. ページの右上隅にある ユーザーメニュー ドロップダウンを選択します。ドロップダウンから ユーザー を選択します。
3. 検索バーにユーザーの名前またはメールアドレスを入力します。
4. チーム役割 ドロップダウンからユーザー名の横にある役割を選択します。

ユーザーのアクセスを割り当てまたは更新する

組織内のユーザーは、以下のいずれかのモデルシートまたは Weave アクセスタイプを持っています：フル、ビューアー、またはアクセスなし。

モデルシートタイプと Weave アクセスタイプは組織レベルで定義され、チームに継承されます。ユーザーのシートタイプを変更したい場合は、組織の設定に移動し、次のステップに従ってください：

1. SaaS ユーザーの場合、https://wandb.ai/account-settings/<organization>/settings にある組織の設定に移動します。角括弧（<>）で囲まれた値を組織名に置き換えてください。他の専用または自己管理のデプロイメントの場合は、https://<your-instance>.wandb.io/org/dashboard に移動します。
2. ユーザー タブを選択します。
3. 役割 ドロップダウンからユーザーに割り当てたいシートタイプを選択します。

ユーザーを削除する

1. https://wandb.ai/home に移動します。
2. ページの右上隅にある ユーザーメニュー のドロップダウンを選択します。ドロップダウンから ユーザー を選択します。
3. 検索バーにユーザーの名前またはメールアドレスを提供します。
4. 表示されたら、三点リーダーまたは3つの点のアイコン（…）を選択します。
5. ドロップダウンから メンバーを削除 を選択します。

請求管理者を割り当てる

1. https://wandb.ai/home に移動します。
2. ページの右上隅にある ユーザーメニュー のドロップダウンを選択します。ドロップダウンから ユーザー を選択します。
3. 検索バーにユーザーの名前またはメールアドレスを入力します。
4. 請求管理者 列の下で、請求管理者として割り当てたいユーザーを選択します。

チームを追加し管理する

組織のダッシュボードを使って、組織内でチームを作成し管理します。組織の管理者またはチーム管理者は、以下のことができます：

• ユーザーをチームに招待したり、チームからユーザーを削除したりする。
• チームメンバーの役割を管理する。
• 組織に参加した時にユーザーをチームに自動的に追加する。
• https://wandb.ai/<team-name> にあるチームのダッシュボードでチームストレージを管理する。

チームを作成する

組織のダッシュボードを使用してチームを作成します：

1. https://wandb.ai/home に移動します。
2. チーム の下の左側のナビゲーションパネルで コラボレーション用のチームを作成 を選択します。
3. 表示されるモーダルで チーム名 フィールドにチームの名前を入力します。
4. ストレージタイプを選択します。
5. チームを作成 ボタンを選択します。

チームを作成 ボタンを選択すると、W&Bは https://wandb.ai/<team-name> の新しいチームページにリダイレクトします。<team-name> はチーム作成時に入力した名前を使用します。

チームを持ったら、そのチームにユーザーを追加することができます。

チームにユーザーを招待する

組織内のチームにユーザーを招待します。ユーザーがすでにW&Bアカウントを持っている場合は、メールアドレスまたはW&Bユーザー名を使用してチームのダッシュボードからユーザーを招待します。

1. https://wandb.ai/<team-name> に移動します。
2. ダッシュボードの左側のグローバルナビゲーションで チーム設定 を選択します。
3. ユーザー タブを選択します。
4. 新しいユーザーを招待する を選びます。
5. 表示されるモーダルで、メールまたはユーザー名 フィールドにそのユーザーのメールを提供し、チームを選択する ドロップダウンからそのユーザーに割り当てる役割を選択します。チーム内でユーザーが持つことができる役割について詳しくは、チーム役割 を参照してください。
6. 招待を送信 ボタンを選びます。

デフォルトでは、チームまたはインスタンスの管理者のみがメンバーをチームに招待できます。この動作を変更するには、チーム設定を参照してください。

メール招待でユーザーを手動で招待することに加えて、新しいユーザーのメールがあなたの組織のドメインと一致する場合は、自動的に新しいユーザーをチームに追加できます。

新メンバーを登録時にチーム組織と一致させる

新規ユーザーがサインアップ時に組織内のチームを発見できるようにします。新しいユーザーは、あなたの組織の確認済みメールドメインと一致する確認済みのメールドメインを持っている必要があります。確認済みの新規ユーザーは、W&Bアカウントに登録する際に組織に属する確認済みのチームの一覧を見ることができます。

組織の管理者はドメイン請求を有効にする必要があります。ドメインキャプチャを有効にするには、ドメインキャプチャに記載されている手順を参照してください。

チームメンバーの役割を割り当てまたは更新する

1. チームメンバーの名前の横にあるアカウントタイプのアイコンを選択します。
2. ドロップダウンから、そのチームメンバーが持つことを望むアカウントタイプを選択します。

この表は、チームメンバーに割り当てることができる役割を示しています：

チームからユーザーを削除する

チームのダッシュボードを使用してユーザーをチームから削除します。メンバーが作成したrunは、そのメンバーがそのチームにいなくなった場合でもW&Bに保存されます。

1. https://wandb.ai/<team-name> に移動します。
2. 左側のナビゲーションバーで チーム設定 を選択します。
3. ユーザー タブを選択します。
4. 削除したいユーザーの名前の横にマウスをホバーします。表示されたら、三点リーダーまたは3つの点のアイコン（…）を選択します。
5. ドロップダウンから ユーザーを削除 を選択します。

2.2 - プロジェクトのアクセス制御を管理する

W&B プロジェクトの範囲を設定し、誰が W&B の run を表示、編集、提出できるかを制限します。

W&B チーム内の任意のプロジェクトに対するアクセスレベルを設定するために、いくつかのコントロールを組み合わせて使用できます。 公開範囲は、上位レベルのメカニズムです。これを使用して、どのユーザーグループがプロジェクト内の run を表示または提出できるかを制御します。Team または Restricted の公開範囲を持つプロジェクトでは、プロジェクトレベルの役割を使用して、各ユーザーのプロジェクト内でのアクセスレベルを制御できます。

公開範囲

選択できるプロジェクトの公開範囲は4つあります。最も公開されているものから最もプライベートなものの順に、それらは次のとおりです：

新規または既存のプロジェクトの公開範囲を設定する

プロジェクトを作成するとき、または後で編集するときに、プロジェクトの公開範囲を設定します。

新しいプロジェクトを作成するときに公開範囲を設定する

1. SaaS クラウド、専用クラウド、または自己管理インスタンスで W&B 組織に移動します。
2. 左側のサイドバーの My projects セクションで Create a new project ボタンをクリックします。代わりに、チームの Projects タブに移動し、右上のコーナーの Create new project ボタンをクリックします。
3. 親チームを選択し、プロジェクトの名前を入力した後、プロジェクトの公開範囲 ドロップダウンから希望の範囲を選択します。

Restricted の公開範囲を選択した場合、次のステップを完了します。

4. プロジェクトでコラボレーションするために必要な W&B チームメンバーの名前を 招待チームメンバー フィールドに入力します。

既存のプロジェクトの公開範囲を編集する

1. W&B プロジェクトに移動します。
2. 左の列で Overview タブを選択します。
3. 右上のコーナーで Edit Project Details ボタンをクリックします。
4. Project Visibility ドロップダウンから希望の範囲を選択します。

Restricted の公開範囲を選択した場合、次のステップを完了します。

5. プロジェクトの Users タブに移動し、特定のユーザーをリストリクションプロジェクトに招待するために ユーザーを追加 ボタンをクリックします。

リストリクション範囲についてのその他の重要な注意事項

• チームレベルのサービスアカウントをリストリクションプロジェクトで使用したい場合は、そのアカウントをプロジェクトに特に招待または追加する必要があります。そうでないと、デフォルトではチームレベルのサービスアカウントはリストリクションプロジェクトにアクセスできません。
• リストリクションプロジェクトから run を移動することはできませんが、非リストリクションプロジェクトからリストリクションプロジェクトに run を移動することはできます。
• プロジェクトの公開範囲をチームにのみ変換することができ、その際、チームのプライバシー設定 Make all future team projects private (public sharing not allowed) に依存しません。
• リストリクションプロジェクトのオーナーが親チームの一員でなくなった場合、チーム管理者はスムーズなプロジェクト運営のためにオーナーを変更する必要があります。

プロジェクトレベルの役割

チーム内の Team または Restricted 範囲のプロジェクトでは、ユーザーに特定の役割を割り当てることができ、その役割はそのユーザーのチームレベルの役割と異なる場合があります。例えば、ユーザーがチームレベルで Member 役割を持っている場合、そのユーザーに View-Only、Admin、または利用可能なカスタム役割をそのチーム内の Team あるいは Restricted 範囲のプロジェクトで割り当てることができます。

ユーザーにプロジェクトレベルの役割を割り当てる

1. W&B プロジェクトに移動します。
2. 左の列で Overview タブを選択します。
3. プロジェクトの Users タブに進みます。
4. 関連するユーザーの Project Role フィールドに現在割り当てられている役割をクリックすると、他の利用可能な役割がリストされているドロップダウンが開きます。
5. ドロップダウンから別の役割を選択します。それは即座に保存されます。

プロジェクトレベルの役割についてのその他の重要な注意事項

• デフォルトでは、チーム_または_リストリクション のプロジェクトにおける全ユーザーのプロジェクトレベルの役割は、それぞれのチームレベルの役割を継承します。
• チームレベルで View-Only 役割を持つユーザーのプロジェクトレベルの役割を変更することはできません。
• 特定のプロジェクト内でのユーザーのプロジェクトレベル役割がチームレベルの役割と同じである場合、チーム管理者がいつかチームレベルの役割を変更した場合、関連するプロジェクト役割も自動的にチームレベルの役割に追随して変更されます。
• 特定のプロジェクト内のユーザーのプロジェクトレベル役割をチームレベルの役割と異なるものに変更した場合、チーム管理者がいつかチームレベルの役割を変更しても、関連するプロジェクトレベルの役割はそのままとなります。
• プロジェクトレベルの役割がチームレベルの役割と異なる場合に、リストリクション プロジェクトからユーザーを削除し、その後しばらくしてユーザーをプロジェクトに戻した場合、デフォルトの振る舞いによりそのチームレベルの役割を継承します。必要であれば、プロジェクトレベルの役割を再度チームレベルの役割と異なるものに変更する必要があります。

3 - ユーザーとチームの管理を自動化する

SCIM API

SCIM API を使用して、ユーザーやその所属するチームを効率的かつ再現可能な方法で管理します。また、SCIM API を使用してカスタムロールを管理したり、 W&B 組織内のユーザーにロールを割り当てたりすることもできます。ロールエンドポイントは公式の SCIM スキーマの一部ではありません。 W&B はカスタムロールの自動管理をサポートするためにロールエンドポイントを追加しています。

SCIM API は特に以下の場合に役立ちます：

• 大規模なユーザーのプロビジョニングおよびプロビジョニング解除の管理
• SCIMサポートのアイデンティティプロバイダーを使用してユーザーを管理

SCIM API には大きく分けて 3 つのカテゴリがあります - User 、 Group 、および Roles 。

User SCIM API

User SCIM API を使用すると、ユーザーの作成、無効化、詳細の取得、または W&B 組織内の全ユーザーの一覧を表示できます。この API は、組織内のユーザーに事前定義されたロールまたはカスタムロールを割り当てることもサポートしています。

Group SCIM API

Group SCIM API は、組織内での W&B チームの作成や削除を含めた管理を行うことができます。 PATCH Group を使用して、既存のチームにユーザーを追加または削除します。

Custom role API

Custom role SCIM API は、組織内でのカスタムロールの作成、一覧表示、更新を含めた管理を行うことができます。

W&B Python SDK API

SCIM API がユーザーとチームの管理を自動化するのと同様に、一部のメソッドを使用して W&B Python SDK API も同様の目的で使用できます。以下のメソッドに注意してください：

4 - ユーザー、グループ、およびロールを SCIM で管理する

クロスドメイン・アイデンティティ管理システム (SCIM) API は、インスタンスまたは組織の管理者が W&B 組織内のユーザー、グループ、およびカスタムロールを管理できるようにします。SCIM グループは W&B のチームにマップされます。

SCIM API は <host-url>/scim/ でアクセス可能であり、RC7643 プロトコルに見られるフィールドのサブセットを持つ /Users と /Groups エンドポイントをサポートしています。さらに、公式の SCIM スキーマの一部ではない /Roles エンドポイントを含んでいます。W&B は /Roles エンドポイントを追加して、W&B 組織でのカスタムロールの自動管理をサポートしています。

認証

組織またはインスタンスの管理者は、自分の API キーを使用した基本認証を利用して SCIM API にアクセスできます。HTTP リクエストの Authorization ヘッダーを文字列 Basic の後にスペースを置き、その後のベース64エンコードされた文字列を username:API-KEY 形式に設定します。つまり、ユーザー名と API キーを : 文字で区切った後、その結果をベース64エンコードします。例えば、demo:p@55w0rd として認証するには、ヘッダーは Authorization: Basic ZGVtbzpwQDU1dzByZA== であるべきです。

ユーザーリソース

SCIM ユーザーリソースは W&B のユーザーにマップされます。

ユーザーの取得

• エンドポイント: <host-url>/scim/Users/{id}
• メソッド: GET
• 説明: ユーザーの一意の ID を提供することにより、SaaS Cloud 組織または Dedicated Cloud または Self-managed インスタンス内の特定のユーザーの情報を取得します。
• リクエスト例:

GET /scim/Users/abc

• レスポンス例:

(Status 200)

{
    "active": true,
    "displayName": "Dev User 1",
    "emails": {
        "Value": "dev-user1@test.com",
        "Display": "",
        "Type": "",
        "Primary": true
    },
    "id": "abc",
    "meta": {
        "resourceType": "User",
        "created": "2023-10-01T00:00:00Z",
        "lastModified": "2023-10-01T00:00:00Z",
        "location": "Users/abc"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "userName": "dev-user1"
}

ユーザーのリスト

• エンドポイント: <host-url>/scim/Users
• メソッド: GET
• 説明: SaaS Cloud 組織または Dedicated Cloud または Self-managed インスタンス内のすべてのユーザーのリストを取得します。
• リクエスト例:

GET /scim/Users

• レスポンス例:

(Status 200)

{
    "Resources": [
        {
            "active": true,
            "displayName": "Dev User 1",
            "emails": {
                "Value": "dev-user1@test.com",
                "Display": "",
                "Type": "",
                "Primary": true
            },
            "id": "abc",
            "meta": {
                "resourceType": "User",
                "created": "2023-10-01T00:00:00Z",
                "lastModified": "2023-10-01T00:00:00Z",
                "location": "Users/abc"
            },
            "schemas": [
                "urn:ietf:params:scim:schemas:core:2.0:User"
            ],
            "userName": "dev-user1"
        }
    ],
    "itemsPerPage": 9999,
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:ListResponse"
    ],
    "startIndex": 1,
    "totalResults": 1
}

ユーザーの作成

• エンドポイント: <host-url>/scim/Users
• メソッド: POST
• 説明: 新しいユーザーリソースを作成します。
• サポートされているフィールド:

• リクエスト例:

POST /scim/Users

{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:User"
  ],
  "emails": [
    {
      "primary": true,
      "value": "admin-user2@test.com"
    }
  ],
  "userName": "dev-user2"
}

• レスポンス例:

(Status 201)

{
    "active": true,
    "displayName": "Dev User 2",
    "emails": {
        "Value": "dev-user2@test.com",
        "Display": "",
        "Type": "",
        "Primary": true
    },
    "id": "def",
    "meta": {
        "resourceType": "User",
        "created": "2023-10-01T00:00:00Z",
        "location": "Users/def"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "userName": "dev-user2"
}

ユーザーの削除

• エンドポイント: <host-url>/scim/Users/{id}
• メソッド: DELETE
• 説明: ユーザーの一意の ID を提供することにより、SaaS Cloud 組織または Dedicated Cloud または Self-managed インスタンスから完全にユーザーを削除します。必要に応じて Create user API を使用して組織またはインスタンスに再度ユーザーを追加してください。
• リクエスト例:

DELETE /scim/Users/abc

• レスポンス例:

(Status 204)

ユーザーの無効化

• エンドポイント: <host-url>/scim/Users/{id}
• メソッド: PATCH
• 説明: ユーザーの一意の ID を提供することにより、Dedicated Cloud または Self-managed インスタンス内で一時的にユーザーを無効化します。必要に応じて Reactivate user API を使用してユーザーを再有効化します。
• サポートされているフィールド:

• リクエスト例:

PATCH /scim/Users/abc

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "replace",
            "value": {"active": false}
        }
    ]
}

• レスポンス例: この操作はユーザーオブジェクトを返します。

(Status 200)

{
    "active": true,
    "displayName": "Dev User 1",
    "emails": {
        "Value": "dev-user1@test.com",
        "Display": "",
        "Type": "",
        "Primary": true
    },
    "id": "abc",
    "meta": {
        "resourceType": "User",
        "created": "2023-10-01T00:00:00Z",
        "lastModified": "2023-10-01T00:00:00Z",
        "location": "Users/abc"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "userName": "dev-user1"
}

ユーザーの再有効化

• エンドポイント: <host-url>/scim/Users/{id}
• メソッド: PATCH
• 説明: ユーザーの一意の ID を提供することにより、Dedicated Cloud または Self-managed インスタンス内で無効化されたユーザーを再有効化します。
• サポートされているフィールド:

• リクエスト例:

PATCH /scim/Users/abc

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "replace",
            "value": {"active": true}
        }
    ]
}

• レスポンス例: この操作はユーザーオブジェクトを返します。

(Status 200)

{
    "active": true,
    "displayName": "Dev User 1",
    "emails": {
        "Value": "dev-user1@test.com",
        "Display": "",
        "Type": "",
        "Primary": true
    },
    "id": "abc",
    "meta": {
        "resourceType": "User",
        "created": "2023-10-01T00:00:00Z",
        "lastModified": "2023-10-01T00:00:00Z",
        "location": "Users/abc"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "userName": "dev-user1"
}

組織レベルのロールをユーザーに割り当てる

• エンドポイント: <host-url>/scim/Users/{id}
• メソッド: PATCH
• 説明: 組織レベルのロールをユーザーに割り当てます。このロールは、ここで説明されているように admin、viewer または member のいずれかになります (こちらを参照)。 SaaS Cloud では、ユーザー設定で SCIM API の正しい組織を設定することを確認してください。
• サポートされているフィールド:

• リクエスト例:

PATCH /scim/Users/abc

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "replace",
            "path": "organizationRole",
            "value": "admin" // ユーザーの組織スコープのロールを admin に設定
        }
    ]
}

• レスポンス例: この操作はユーザーオブジェクトを返します。

(Status 200)

{
    "active": true,
    "displayName": "Dev User 1",
    "emails": {
        "Value": "dev-user1@test.com",
        "Display": "",
        "Type": "",
        "Primary": true
    },
    "id": "abc",
    "meta": {
        "resourceType": "User",
        "created": "2023-10-01T00:00:00Z",
        "lastModified": "2023-10-01T00:00:00Z",
        "location": "Users/abc"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "userName": "dev-user1",
    "teamRoles": [  // ユーザーが所属するすべてのチームでのロールを返します
        {
            "teamName": "team1",
            "roleName": "admin"
        }
    ],
    "organizationRole": "admin" // 組織スコープでのユーザーのロールを返します
}

チームレベルのロールをユーザーに割り当てる

• エンドポイント: <host-url>/scim/Users/{id}
• メソッド: PATCH
• 説明: チームレベルのロールをユーザーに割り当てます。このロールは、ここで説明されているように admin、viewer、member またはカスタムロールのいずれかになります (こちらを参照)。 SaaS Cloud では、ユーザー設定で SCIM API の正しい組織を設定することを確認してください。
• サポートされているフィールド:

• リクエスト例:

PATCH /scim/Users/abc

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "replace",
            "path": "teamRoles",
            "value": [
                {
                    "roleName": "admin", // 定義済みロールのロール名は大文字小文字を区別しませんが、カスタムロールでは区別します
                    "teamName": "team1" // チームteam1でのユーザーのロールをadminに設定
                }
            ]
        }
    ]
}

• レスポンス例: この操作はユーザーオブジェクトを返します。

(Status 200)

{
    "active": true,
    "displayName": "Dev User 1",
    "emails": {
        "Value": "dev-user1@test.com",
        "Display": "",
        "Type": "",
        "Primary": true
    },
    "id": "abc",
    "meta": {
        "resourceType": "User",
        "created": "2023-10-01T00:00:00Z",
        "lastModified": "2023-10-01T00:00:00Z",
        "location": "Users/abc"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "userName": "dev-user1",
    "teamRoles": [  // ユーザーが所属するすべてのチームでのロールを返します
        {
            "teamName": "team1",
            "roleName": "admin"
        }
    ],
    "organizationRole": "admin" // 組織スコープでのユーザーのロールを返します
}

グループリソース

SCIM グループリソースは W&B のチームにマップされます。つまり、W&B デプロイメントで SCIM グループを作成すると W&B チームが作成されます。その他のグループエンドポイントにも同様です。

チームの取得

• エンドポイント: <host-url>/scim/Groups/{id}
• メソッド: GET
• 説明: チームの一意の ID を提供してチーム情報を取得します。
• リクエスト例:

GET /scim/Groups/ghi

• レスポンス例:

(Status 200)

{
    "displayName": "wandb-devs",
    "id": "ghi",
    "members": [
        {
            "Value": "abc",
            "Ref": "",
            "Type": "",
            "Display": "dev-user1"
        }
    ],
    "meta": {
        "resourceType": "Group",
        "created": "2023-10-01T00:00:00Z",
        "lastModified": "2023-10-01T00:00:00Z",
        "location": "Groups/ghi"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:Group"
    ]
}

チームのリスト

• エンドポイント: <host-url>/scim/Groups
• メソッド: GET
• 説明: チームのリストを取得します。
• リクエスト例:

GET /scim/Groups

• レスポンス例:

(Status 200)

{
    "Resources": [
        {
            "displayName": "wandb-devs",
            "id": "ghi",
            "members": [
                {
                    "Value": "abc",
                    "Ref": "",
                    "Type": "",
                    "Display": "dev-user1"
                }
            ],
            "meta": {
                "resourceType": "Group",
                "created": "2023-10-01T00:00:00Z",
                "lastModified": "2023-10-01T00:00:00Z",
                "location": "Groups/ghi"
            },
            "schemas": [
                "urn:ietf:params:scim:schemas:core:2.0:Group"
            ]
        }
    ],
    "itemsPerPage": 9999,
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:ListResponse"
    ],
    "startIndex": 1,
    "totalResults": 1
}

チームの作成

• エンドポイント: <host-url>/scim/Groups
• メソッド: POST
• 説明: 新しいチームリソースを作成します。
• サポートされているフィールド:

• リクエスト例:

wandb-support というチームを作成し、そのメンバーとして dev-user2 を設定します。

POST /scim/Groups

{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
    "displayName": "wandb-support",
    "members": [
        {
            "value": "def"
        }
    ]
}

• レスポンス例:

(Status 201)

{
    "displayName": "wandb-support",
    "id": "jkl",
    "members": [
        {
            "Value": "def",
            "Ref": "",
            "Type": "",
            "Display": "dev-user2"
        }
    ],
    "meta": {
        "resourceType": "Group",
        "created": "2023-10-01T00:00:00Z",
        "lastModified": "2023-10-01T00:00:00Z",
        "location": "Groups/jkl"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:Group"
    ]
}

チームの更新

• エンドポイント: <host-url>/scim/Groups/{id}
• メソッド: PATCH
• 説明: 既存のチームのメンバーシップリストを更新します。
• サポートされている操作: メンバーの追加、メンバーの削除
• リクエスト例:

wandb-devs に dev-user2 を追加する

PATCH /scim/Groups/ghi

{
	"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
	"Operations": [
		{
			"op": "add",
			"path": "members",
			"value": [
	      {
					"value": "def",
				}
	    ]
		}
	]
}

• レスポンス例:

(Status 200)

{
    "displayName": "wandb-devs",
    "id": "ghi",
    "members": [
        {
            "Value": "abc",
            "Ref": "",
            "Type": "",
            "Display": "dev-user1"
        },
        {
            "Value": "def",
            "Ref": "",
            "Type": "",
            "Display": "dev-user2"
        }
    ],
    "meta": {
        "resourceType": "Group",
        "created": "2023-10-01T00:00:00Z",
        "lastModified": "2023-10-01T00:01:00Z",
        "location": "Groups/ghi"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:Group"
    ]
}

チームの削除

• SCIM API では、チームには追加データがリンクされているため、現在チームの削除はサポートされていません。削除を確認するにはアプリからチームを削除してください。

ロールリソース

SCIM ロールリソースは W&B のカスタムロールにマップされます。前述したように、/Roles エンドポイントは公式 SCIM スキーマの一部ではありません。W&B は W&B 組織内のカスタムロールの自動管理をサポートするために /Roles エンドポイントを追加しています。

カスタムロールの取得

• エンドポイント: <host-url>/scim/Roles/{id}
• メソッド: GET
• 説明: ロールの一意の ID を提供し、カスタムロールの情報を取得します。
• リクエスト例:

GET /scim/Roles/abc

• レスポンス例:

(Status 200)

{
    "description": "A sample custom role for example",
    "id": "Um9sZTo3",
    "inheritedFrom": "member", // 定義済みロールを示します
    "meta": {
        "resourceType": "Role",
        "created": "2023-11-20T23:10:14Z",
        "lastModified": "2023-11-20T23:31:23Z",
        "location": "Roles/Um9sZTo3"
    },
    "name": "Sample custom role",
    "organizationID": "T3JnYW5pemF0aW9uOjE0ODQ1OA==",
    "permissions": [
        {
            "name": "artifact:read",
            "isInherited": true // member 定義済みロールから継承された
        },
        ...
        ...
        {
            "name": "project:update",
            "isInherited": false // 管理者によって追加されたカスタム権限
        }
    ],
    "schemas": [
        ""
    ]
}

カスタムロールの一覧

• エンドポイント: <host-url>/scim/Roles
• メソッド: GET
• 説明: W&B 組織のすべてのカスタムロールの情報を取得します
• リクエスト例:

GET /scim/Roles

• レスポンス例:

(Status 200)

{
   "Resources": [
        {
            "description": "A sample custom role for example",
            "id": "Um9sZTo3",
            "inheritedFrom": "member", // 定義済みロールからカスタムロールが継承されていることを示します
            "meta": {
                "resourceType": "Role",
                "created": "2023-11-20T23:10:14Z",
                "lastModified": "2023-11-20T23:31:23Z",
                "location": "Roles/Um9sZTo3"
            },
            "name": "Sample custom role",
            "organizationID": "T3JnYW5pemF0aW9uOjE0ODQ1OA==",
            "permissions": [
                {
                    "name": "artifact:read",
                    "isInherited": true // member 定義済みロールから継承された
                },
                ...
                ...
                {
                    "name": "project:update",
                    "isInherited": false // 管理者によって追加されたカスタム権限
                }
            ],
            "schemas": [
                ""
            ]
        },
        {
            "description": "Another sample custom role for example",
            "id": "Um9sZToxMg==",
            "inheritedFrom": "viewer", // 定義済みロールからカスタムロールが継承されていることを示します
            "meta": {
                "resourceType": "Role",
                "created": "2023-11-21T01:07:50Z",
                "location": "Roles/Um9sZToxMg=="
            },
            "name": "Sample custom role 2",
            "organizationID": "T3JnYW5pemF0aW9uOjE0ODQ1OA==",
            "permissions": [
                {
                    "name": "launchagent:read",
                    "isInherited": true // viewer 定義済みロールから継承された
                },
                ...
                ...
                {
                    "name": "run:stop",
                    "isInherited": false // 管理者によって追加されたカスタム権限
                }
            ],
            "schemas": [
                ""
            ]
        }
    ],
    "itemsPerPage": 9999,
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:ListResponse"
    ],
    "startIndex": 1,
    "totalResults": 2
}

カスタムロールの作成

• エンドポイント: <host-url>/scim/Roles
• メソッド: POST
• 説明: W&B 組織内で新しいカスタムロールを作成します。
• サポートされているフィールド:

• リクエスト例:

POST /scim/Roles

{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Role"],
    "name": "Sample custom role",
    "description": "A sample custom role for example",
    "permissions": [
        {
            "name": "project:update"
        }
    ],
    "inheritedFrom": "member"
}

• レスポンス例:

(Status 201)

{
    "description": "A sample custom role for example",
    "id": "Um9sZTo3",
    "inheritedFrom": "member", // 定義済みロールを示します
    "meta": {
        "resourceType": "Role",
        "created": "2023-11-20T23:10:14Z",
        "lastModified": "2023-11-20T23:31:23Z",
        "location": "Roles/Um9sZTo3"
    },
    "name": "Sample custom role",
    "organizationID": "T3JnYW5pemF0aW9uOjE0ODQ1OA==",
    "permissions": [
        {
            "name": "artifact:read",
            "isInherited": true // member 定義済みロールから継承された
        },
        ...
        ...
        {
            "name": "project:update",
            "isInherited": false // 管理者によって追加されたカスタム権限
        }
    ],
    "schemas": [
        ""
    ]
}

カスタムロールの削除

• エンドポイント: <host-url>/scim/Roles/{id}
• メソッド: DELETE
• 説明: W&B 組織内のカスタムロールを削除します。慎重に使用してください。 カスタムロールから継承される定義済みロールは、操作前にカスタムロールに割り当てられていたすべてのユーザーに再び割り当てられます。
• リクエスト例:

DELETE /scim/Roles/abc

• レスポンス例:

(Status 204)

カスタムロールの権限の更新

• エンドポイント: <host-url>/scim/Roles/{id}
• メソッド: PATCH
• 説明: W&B 組織内のカスタムロールにカスタム権限を追加または削除します。
• サポートされているフィールド:

• リクエスト例:

PATCH /scim/Roles/abc

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "add", // 操作のタイプを示し、他の可能な値は `remove`
            "path": "permissions",
            "value": [
                {
                    "name": "project:delete"
                }
            ]
        }
    ]
}

• レスポンス例:

(Status 200)

{
    "description": "A sample custom role for example",
    "id": "Um9sZTo3",
    "inheritedFrom": "member", // 定義済みロールを示します
    "meta": {
        "resourceType": "Role",
        "created": "2023-11-20T23:10:14Z",
        "lastModified": "2023-11-20T23:31:23Z",
        "location": "Roles/Um9sZTo3"
    },
    "name": "Sample custom role",
    "organizationID": "T3JnYW5pemF0aW9uOjE0ODQ1OA==",
    "permissions": [
        {
            "name": "artifact:read",
            "isInherited": true // member 定義済みロールから継承された
        },
        ...
        ...
        {
            "name": "project:update",
            "isInherited": false // 更新前に管理者によって追加された既存のカスタム権限
        },
        {
            "name": "project:delete",
            "isInherited": false // 更新の一部として管理者によって追加された新規のカスタム権限
        }
    ],
    "schemas": [
        ""
    ]
}

カスタムロールメタデータの更新

• エンドポイント: <host-url>/scim/Roles/{id}
• メソッド: PUT
• 説明: W&B 組織内のカスタムロールの名前、説明、または継承ロールを更新します。この操作は、既存の、つまり非継承のカスタム権限には影響しません。
• サポートされているフィールド:

• リクエスト例:

PUT /scim/Roles/abc

{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Role"],
    "name": "Sample custom role",
    "description": "A sample custom role for example but now based on viewer",
    "inheritedFrom": "viewer"
}

• レスポンス例:

(Status 200)

{
    "description": "A sample custom role for example but now based on viewer", // リクエストに応じて説明を変更
    "id": "Um9sZTo3",
    "inheritedFrom": "viewer", // リクエストに応じて変更された定義済みロールを示します
    "meta": {
        "resourceType": "Role",
        "created": "2023-11-20T23:10:14Z",
        "lastModified": "2023-11-20T23:31:23Z",
        "location": "Roles/Um9sZTo3"
    },
    "name": "Sample custom role",
    "organizationID": "T3JnYW5pemF0aW9uOjE0ODQ1OA==",
    "permissions": [
        {
            "name": "artifact:read",
            "isInherited": true // viewer 定義済みロールから継承された
        },
        ... // 更新後に member 定義済みロールにあるが viewer にはない権限は継承されません
        {
            "name": "project:update",
            "isInherited": false // 管理者によって追加されたカスタム権限
        },
        {
            "name": "project:delete",
            "isInherited": false // 管理者によって追加されたカスタム権限
        }
    ],
    "schemas": [
        ""
    ]
}

5 - 高度な IAM 設定

基本的な環境変数に加えて、環境変数を使用して、専用クラウドまたは自己管理インスタンスの IAM オプションを設定できます。

お使いのインスタンスにおける IAM のニーズに応じて、以下の環境変数のいずれかを選んでください。