Identity and access management (IAM)

• 1: Authentication
• 1.1: Configure SSO with LDAP
• 1.2: Configure SSO with OIDC
• 1.3: Use federated identities with SDK
• 1.4: Use service accounts to automate workflows
• 2: Access management
• 2.1: Manage your organization
• 2.2: Manage access control for projects
• 3: Automate user and team management
• 4: Manage users, groups, and roles with SCIM
• 5: Advanced IAM configuration

1 - Authentication

1.1 - Configure SSO with LDAP

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

LDAP 接続を構成する

• W&B App
• Environment variable

設定 パラメータ

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

1.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 テナントの構成を支援してください。

• Cognito
• Okta
• Entra

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 をサポートしていません。

1.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 を設定できます。

1.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 もサポートしています。

2 - Access management

組織内の ユーザー と Teams を管理する

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

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

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

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

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

組織管理者と チーム 管理者の両方が、https://wandb.ai/<your-team-name> の チーム ダッシュボード を使用して Teams を管理します。詳細、および チーム のデフォルトのプライバシー 設定 の構成については、Teams の追加と管理を参照してください。

特定の Projects への可視性を制限する

W&B の Project のスコープを定義して、誰が W&B の Runs を表示、編集、および送信できるかを制限します。 チーム が機密 データ を扱う場合、 Project を表示できる ユーザー を制限すると特に役立ちます。

組織管理者、 チーム 管理者、または Project のオーナーは、 Project の可視性を 設定 および編集できます。

詳細については、Project の可視性を参照してください。

2.1 - Manage your organization

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

Team の管理者として、Teams を管理 できます。

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

組織名の変更

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

ユーザーの追加と管理

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

• ユーザーの招待または削除。
• ユーザーの組織ロールの割り当てまたは更新、およびカスタムロールの作成。
• 課金管理者の割り当て。

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

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

シートと料金

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

ユーザーの招待

管理者は、ユーザーを組織、および組織内の特定の Team に招待できます。

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

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

SSO を構成し、SSO プロバイダーが許可している場合、一致するメールアドレスドメインを持つ W&B ユーザーは、シングルサインオン (SSO) で W&B Organization にサインインできます。SSO は、すべてのエンタープライズライセンスで利用できます。

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

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

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

• Dedicated cloud
• Self-managed

カスタムロールの作成

組織管理者は、表示のみまたはメンバーロールに基づいて新しいロールを作成し、追加の権限を追加して、きめ細かいアクセス制御を実現できます。Team 管理者は、Team メンバーにカスタムロールを割り当てることができます。カスタムロールは組織レベルで作成されますが、Team レベルで割り当てられます。

カスタムロールを作成するには:

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

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

ドメインキャプチャ

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

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

ユーザーのロールの割り当てまたは更新

Organization のすべてのメンバーは、W&B Models と Weave の両方に対して組織ロールとシートを持っています。シートのタイプによって、課金ステータスと各製品ラインで実行できるアクションが決まります。

最初にユーザーを組織に招待するときに、ユーザーに組織ロールを割り当てます。ユーザーのロールは後で変更できます。

組織内のユーザーは、次のいずれかのロールを持つことができます。

ユーザーのロールを変更するには:

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

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

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

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

1. SaaS ユーザーの場合は、https://wandb.ai/account-settings/<organization>/settings で組織の設定に移動します。山かっこ (<>) で囲まれた値を組織名に置き換えてください。他の Dedicated および Self-managed デプロイメントの場合は、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. 課金管理者 列で、課金管理者として割り当てるユーザーを選択します。

Team の追加と管理

組織のダッシュボードを使用して、組織内に Team を作成および管理します。組織管理者または Team 管理者は次のことができます。

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

Team の作成

組織のダッシュボードを使用して Team を作成します。

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

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

Team を作成したら、その Team にユーザーを追加できます。

Team へのユーザーの招待

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

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

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

メールでの招待を使用して手動でユーザーを招待するだけでなく、新しいユーザーの メールが組織のドメインと一致する 場合、新しいユーザーを Team に自動的に追加できます。

サインアップ時にメンバーを Team 組織に一致させる

組織内の新しいユーザーがサインアップ時に組織内の Teams を見つけられるようにします。新しいユーザーは、組織の検証済みメールアドレスドメインと一致する検証済みのメールアドレスドメインを持っている必要があります。検証済みの新しいユーザーは、W&B アカウントにサインアップするときに、組織に属する検証済みの Team のリストを表示できます。

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

Team メンバーのロールの割り当てまたは更新

1. Team メンバーの名前の横にあるアカウントタイプのアイコンを選択します。
2. ドロップダウンから、Team メンバーに持たせるアカウントタイプを選択します。

次の表に、Team のメンバーに割り当てることができるロールを示します。

Team からのユーザーの削除

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

1. https://wandb.ai/<team-name> に移動します。
2. 左側のナビゲーションバーで Team の設定 を選択します。
3. ユーザー タブを選択します。
4. 削除するユーザーの名前の横にマウスを移動します。表示されたら、省略記号または 3 つのドットのアイコン (…) を選択します。
5. ドロップダウンから、ユーザーを削除 を選択します。

2.2 - Manage access control for projects

W&B のプロジェクトのスコープを定義して、誰が W&B の run を表示、編集、送信できるかを制限します。

いくつかのコントロールを組み合わせて、W&B の Teams 内のプロジェクトに対するアクセスレベルを設定できます。可視性スコープ は、より高レベルなメカニズムです。これを使用して、どのユーザーグループがプロジェクト内の run を表示または送信できるかを制御します。Team または Restricted の可視性スコープを持つプロジェクトの場合、プロジェクトレベルのロール を使用して、各 ユーザー がプロジェクト内で持つアクセスレベルを制御できます。

可視性スコープ

選択できるプロジェクトの可視性スコープは 4 つあります。最も公開されているものから最もプライベートなものの順に示します。

新規または既存のプロジェクトに可視性スコープを設定する

プロジェクトの可視性スコープは、プロジェクトの作成時、または後で編集するときに設定します。

新しいプロジェクトを作成するときに可視性スコープを設定する

1. SaaS Cloud、 専用クラウド 、またはセルフマネージドインスタンスで、W&B 組織に移動します。
2. 左側のサイドバーの My projects セクションにある Create a new project ボタンをクリックします。または、 Team の Projects タブに移動し、右上隅にある Create new project ボタンをクリックします。
3. 親 Team を選択し、プロジェクトの名前を入力したら、Project Visibility ドロップダウンから目的のスコープを選択します。

Restricted の可視性スコープを選択した場合は、次の手順を完了してください。

4. Invite team members フィールドに、1 人または複数の W&B の チームメンバー の名前を入力します。プロジェクトで共同作業するために不可欠なメンバーのみを追加してください。

既存のプロジェクトの可視性スコープを編集する

1. W&B の プロジェクト に移動します。
2. 左側の列で Overview タブを選択します。
3. 右上隅にある Edit Project Details ボタンをクリックします。
4. Project Visibility ドロップダウンから、目的のスコープを選択します。

Restricted の可視性スコープを選択した場合は、次の手順を完了してください。

5. プロジェクトの Users タブに移動し、Add user ボタンをクリックして、特定の ユーザー を制限付きプロジェクトに招待します。

制限付きスコープに関するその他の重要な注意事項

• 制限付きプロジェクトで Team レベルの サービス アカウント を使用する場合は、その サービス アカウント をプロジェクトに明示的に招待または追加する必要があります。そうしないと、 Team レベルの サービス アカウント はデフォルトで制限付きプロジェクトにアクセスできません。
• 制限付きプロジェクトから run を移動することはできませんが、制限されていないプロジェクトから制限付きプロジェクトに run を移動することはできます。
• Team のプライバシー設定 将来のすべての Team プロジェクトを非公開にする (公開共有は許可されません) に関係なく、制限付きプロジェクトの可視性を Team スコープのみに変換できます。
• 制限付きプロジェクトのオーナーが親 Team の一部でなくなった場合、 Team 管理者はプロジェクトのシームレスな運用を確保するためにオーナーを変更する必要があります。

プロジェクトレベルのロール

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

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

1. W&B の プロジェクト に移動します。
2. 左側の列で Overview タブを選択します。
3. プロジェクトの Users タブに移動します。
4. Project Role フィールドで、関係する ユーザー に現在割り当てられているロールをクリックします。これにより、他の使用可能なロールを一覧表示するドロップダウンが開きます。
5. ドロップダウンから別のロールを選択します。すぐに保存されます。

プロジェクトレベルのロールに関するその他の重要な注意事項

• デフォルトでは、Team または Restricted スコープのプロジェクト内のすべての ユーザー のプロジェクトレベルのロールは、それぞれの Team レベルのロールを 継承 します。
• Team レベルで View-only ロールを持っている ユーザー のプロジェクトレベルのロールを 変更することはできません。
• 特定のプロジェクト内の ユーザー のプロジェクトレベルのロールが Team レベルのロール と同じである 場合、 Team 管理者が Team レベルのロールを変更すると、関連するプロジェクトロールは Team レベルのロールを追跡するように自動的に変更されます。
• 特定のプロジェクト内の ユーザー のプロジェクトレベルのロールを、Team レベルのロール とは異なる ように変更した場合、 Team 管理者が Team レベルのロールを変更しても、関連するプロジェクトレベルのロールはそのままになります。
• プロジェクトレベルのロールが Team レベルのロールと異なる場合に、 ユーザー を restricted プロジェクトから削除し、しばらくしてからその ユーザー をプロジェクトに再度追加すると、デフォルトの動作により Team レベルのロールを継承します。必要に応じて、プロジェクトレベルのロールを再度変更して、 Team レベルのロールと異なるようにする必要があります。

3 - Automate user and team management

SCIM API

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

SCIM API は、特に次のような場合に役立ちます。

• 大規模なユーザーのプロビジョニングとプロビジョニング解除を管理する
• SCIM をサポートする Identity Provider で Users を管理する

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

User SCIM API

User SCIM API を使用すると、User の作成、非アクティブ化、詳細の取得、または W&B organization 内のすべての Users の一覧表示が可能です。この API は、定義済みまたはカスタムロールを organization 内の Users に割り当てることもサポートしています。

Group SCIM API

Group SCIM API を使用すると、organization 内の Teams の作成や削除など、W&B Teams を管理できます。PATCH Group を使用して、既存の Team に Users を追加または削除します。

Custom role API

Custom role SCIM API を使用すると、organization 内のカスタムロールの作成、一覧表示、または更新など、カスタムロールを管理できます。

W&B Python SDK API

SCIM API で User と Team の管理を自動化できるのと同じように、W&B Python SDK API で利用できる メソッド の一部もその目的に使用できます。次の メソッド に注意してください。

4 - Manage users, groups, and roles with SCIM

System for Cross-domain Identity Management（SCIM）API を使用すると、インスタンスまたは organization の管理者は、W&B organization 内の user、グループ、およびカスタムロールを管理できます。SCIM グループは W&B の Teams にマッピングされます。

SCIM API は <host-url>/scim/ でアクセスでき、RC7643 プロトコルにあるフィールドのサブセットを使用して、/Users および /Groups エンドポイントをサポートします。さらに、公式の SCIM スキーマにはない /Roles エンドポイントが含まれています。W&B は、W&B organization でのカスタムロールの自動管理をサポートするために、/Roles エンドポイントを追加します。

認証

organization またはインスタンスの管理者は、 APIキー を使用して基本認証で SCIM API にアクセスできます。HTTP リクエストの Authorization ヘッダーを文字列 Basic に設定し、その後にスペース、次に username:API-KEY の形式で base-64 エンコードされた文字列を設定します。つまり、username と APIキー を : 文字で区切られた value に置き換え、その結果を base-64 エンコードします。たとえば、demo:p@55w0rd として認証するには、ヘッダーを Authorization: Basic ZGVtbzpwQDU1dzByZA== にする必要があります。

User リソース

SCIM の user リソースは W&B の Users にマッピングされます。

User を取得

• エンドポイント: <host-url>/scim/Users/{id}
• メソッド: GET
• 説明: user の一意の ID を指定して、SaaS Cloud organization または Dedicated Cloud あるいは Self-managed インスタンス内の特定の user の情報を取得します。
• リクエストの例:

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"
}

Users をリスト表示

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

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
}

User を作成

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

• リクエストの例:

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"
}

User を削除

• エンドポイント: <host-url>/scim/Users/{id}
• メソッド: DELETE
• 説明: user の一意の ID を指定して、SaaS Cloud organization または Dedicated Cloud あるいは Self-managed インスタンスから user を完全に削除します。必要に応じて、User を作成 API を使用して、user を organization またはインスタンスに再度追加します。
• リクエストの例:

DELETE /scim/Users/abc

• レスポンスの例:

(Status 204)

User を非アクティブ化

• エンドポイント: <host-url>/scim/Users/{id}
• メソッド: PATCH
• 説明: user の一意の ID を指定して、Dedicated Cloud または Self-managed インスタンス内の user を一時的に非アクティブ化します。必要に応じて、User を再アクティブ化 API を使用して、user を再アクティブ化します。
• サポートされているフィールド:

• リクエストの例:

PATCH /scim/Users/abc

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

• レスポンスの例: これにより、User オブジェクトが返されます。

(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"
}

User を再アクティブ化

• エンドポイント: <host-url>/scim/Users/{id}
• メソッド: PATCH
• 説明: user の一意の ID を指定して、Dedicated Cloud または Self-managed インスタンス内の非アクティブ化された user を再アクティブ化します。
• サポートされているフィールド:

• リクエストの例:

PATCH /scim/Users/abc

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

• レスポンスの例: これにより、User オブジェクトが返されます。

(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"
}

User に organization レベルのロールを割り当てる

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

• リクエストの例:

PATCH /scim/Users/abc

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "replace",
            "path": "organizationRole",
            "value": "admin" // user の organization スコープのロールを admin に設定します
        }
    ]
}

• レスポンスの例: これにより、User オブジェクトが返されます。

(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": [  // user が所属するすべての Teams における user のロールを返します
        {
            "teamName": "team1",
            "roleName": "admin"
        }
    ],
    "organizationRole": "admin" // organization スコープにおける user のロールを返します
}

User に Team レベルのロールを割り当てる

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

• リクエストの例:

PATCH /scim/Users/abc

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "replace",
            "path": "teamRoles",
            "value": [
                {
                    "roleName": "admin", // 定義済みのロールの場合、ロール名の大文字と小文字は区別されず、カスタムロールの場合は大文字と小文字が区別されます
                    "teamName": "team1" // Team team1 における user のロールを admin に設定します
                }
            ]
        }
    ]
}

• レスポンスの例: これにより、User オブジェクトが返されます。

(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": [  // user が所属するすべての Teams における user のロールを返します
        {
            "teamName": "team1",
            "roleName": "admin"
        }
    ],
    "organizationRole": "admin" // organization スコープにおける user のロールを返します
}

Group リソース

SCIM のグループリソースは W&B の Teams にマッピングされます。つまり、W&B デプロイメントで SCIM グループを作成すると、W&B の Team が作成されます。他のグループエンドポイントにも同じことが当てはまります。

Team を取得

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

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"
    ]
}

Teams をリスト表示

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

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
}

Team を作成

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

• リクエストの例:

dev-user2 をメンバーとして、wandb-support という Team を作成します。

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"
    ]
}

Team を更新

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

dev-user2 を wandb-devs に追加します

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"
    ]
}

Team を削除

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

Role リソース

SCIM のロールリソースは W&B のカスタムロールにマッピングされます。前述のように、/Roles エンドポイントは公式の SCIM スキーマの一部ではありません。W&B は、W&B organization でのカスタムロールの自動管理をサポートするために、/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", // indicates the predefined role
    "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 // inherited from member predefined role
        },
        ...
        ...
        {
            "name": "project:update",
            "isInherited": false // custom permission added by admin
        }
    ],
    "schemas": [
        ""
    ]
}

カスタムロールをリスト表示

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

GET /scim/Roles

• レスポンスの例:

(Status 200)

{
   "Resources": [
        {
            "description": "A sample custom role for example",
            "id": "Um9sZTo3",
            "inheritedFrom": "member", // indicates the predefined role that the custom role inherits from
            "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 // inherited from member predefined role
                },
                ...
                ...
                {
                    "name": "project:update",
                    "isInherited": false // custom permission added by admin
                }
            ],
            "schemas": [
                ""
            ]
        },
        {
            "description": "Another sample custom role for example",
            "id": "Um9sZToxMg==",
            "inheritedFrom": "viewer", // indicates the predefined role that the custom role inherits from
            "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 // inherited from viewer predefined role
                },
                ...
                ...
                {
                    "name": "run:stop",
                    "isInherited": false // custom permission added by admin
                }
            ],
            "schemas": [
                ""
            ]
        }
    ],
    "itemsPerPage": 9999,
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:ListResponse"
    ],
    "startIndex": 1,
    "totalResults": 2
}

カスタムロールを作成

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

• リクエストの例:

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", // indicates the predefined role
    "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 // inherited from member predefined role
        },
        ...
        ...
        {
            "name": "project:update",
            "isInherited": false // custom permission added by admin
        }
    ],
    "schemas": [
        ""
    ]
}

カスタムロールを削除

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

DELETE /scim/Roles/abc

• レスポンスの例:

(Status 204)

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

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

• リクエストの例:

PATCH /scim/Roles/abc

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "add", // indicates the type of operation, other possible value being `remove`
            "path": "permissions",
            "value": [
                {
                    "name": "project:delete"
                }
            ]
        }
    ]
}

• レスポンスの例:

(Status 200)

{
    "description": "A sample custom role for example",
    "id": "Um9sZTo3",
    "inheritedFrom": "member", // indicates the predefined role
    "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 // inherited from member predefined role
        },
        ...
        ...
        {
            "name": "project:update",
            "isInherited": false // existing custom permission added by admin before the update
        },
        {
            "name": "project:delete",
            "isInherited": false // new custom permission added by admin as part of the update
        }
    ],
    "schemas": [
        ""
    ]
}

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

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

• リクエストの例:

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", // changed the descripton per the request
    "id": "Um9sZTo3",
    "inheritedFrom": "viewer", // indicates the predefined role which is changed per the request
    "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 // inherited from viewer predefined role
        },
        ... // Any permissions that are in member predefined role but not in viewer will not be inherited post the update
        {
            "name": "project:update",
            "isInherited": false // custom permission added by admin
        },
        {
            "name": "project:delete",
            "isInherited": false // custom permission added by admin
        }
    ],
    "schemas": [
        ""
    ]
}

5 - Advanced IAM configuration

基本的な環境変数に加えて、環境変数を使用して、専用クラウドまたはセルフマネージドインスタンスのIAMオプションを構成できます。

IAMのニーズに応じて、インスタンスに対して次のいずれかの環境変数を選択してください。