メインコンテンツへスキップ
SCIM の動作を紹介する動画をご覧ください (12分)

​
概要

このページでは、インスタンス管理者および組織管理者が、System for Cross-domain Identity Management (SCIM) API を使用して W&B のアイデンティティ管理を自動化する方法について説明します。SCIM API を使用すると、W&B App で手動操作する代わりに、アイデンティティ プロバイダまたは CI/CD パイプラインを通じて、ユーザーのプロビジョニングとプロビジョニング解除、チーム メンバーシップの管理、カスタムロールの定義をプログラムで実行できます。SCIM グループは W&B Teams にマッピングされます。 W&B の SCIM API は、Okta や Microsoft Entra などのアイデンティティ プロバイダと互換性があります。Okta、Microsoft Entra、およびその他のアイデンティティ プロバイダでの SSO 設定については、SSO ドキュメントを参照してください。 SCIM API との連携方法を示す実践的な Python の例については、wandb-scim リポジトリを参照してください。

​
サポートされている機能

SCIM API は次の機能をサポートしています。
  • フィルタリング: API は /Users および /Groups エンドポイントのフィルタリングをサポートします。
  • PATCH 操作: リソースの一部更新に PATCH をサポートします。
  • ETag サポート: 競合検出のため、ETag を使用した条件付き更新をサポートします。
  • サービスアカウント認証: 組織のサービスアカウントは API にアクセスできます。
  • サービスアカウントのライフサイクル: チームスコープおよび組織スコープのサービスアカウントのプロビジョニングとプロビジョニング解除を行えます。Multi-tenant Cloud、専用クラウド、および セルフマネージド v0.81.0+ でサポートされます。
複数の Enterprise Multi-tenant Cloud 組織の管理者である場合は、APIキーを使用して行われたリクエストが正しい組織に適用されるよう、SCIM API リクエストの送信先となる組織を設定してください。プロフィール画像をクリックし、User Settings をクリックしてから、Default API organization の設定を確認してください。選択したホスティングオプションによって、このページの例で使用する [HOST-URL] プレースホルダーの値が決まります。例では abc や def などのユーザー ID を使用しています。実際のリクエストと応答では、ユーザー ID にはハッシュ化された値が使用されます。

​
認証

すべての SCIM リクエストは、管理者プリンシパルとして認証される必要があります。組織管理者は、Bearer token または HTTP Basic 認証情報を使用して認証できます。いずれの方式でも、キーを使用する場合は 同じ APIキー文字列 を使用します。次のセクションの主な違いを確認したうえで、ユーザーのアイデンティティまたは組織スコープのサービスアカウントを選択してください。

​
主な違い

次のリストでは、SCIM 認証におけるユーザーの認証情報とサービスアカウントの認証情報を比較します。
  • 使用に適した対象: ユーザーは対話的な単発の管理操作に適しており、サービスアカウントはオートメーションやインテグレーション (CI/CD、プロビジョニングツール) に適しています。
  • 認証情報: ユーザーは Basic 認証でユーザー名とAPIキーを送信します。サービスアカウントは Basic 認証でAPIキーのみを送信します (ユーザー名は不要です) 。Bearer 認証では、ヘッダーにAPIキーのみを送信します (ユーザー名は不要です) 。
  • Bearer と Basic の違い: Bearer は Authorization: Bearer [API-KEY] を使用し、キーをそのまま指定します。Basic は Authorization: Basic <base64(...)> を使用します (ユーザーは username:API-KEY をエンコードし、サービスアカウントは先頭にコロンを付けてユーザー名を空にした :API-KEY をエンコードします) 。
  • スコープと権限: インスタンス管理者または組織管理者ユーザーのAPIキー、または 組織スコープのサービスアカウント のAPIキーを使用してください。チームスコープのサービスアカウント のキーでは SCIM API を認証できません。SCIM で使用するサービスアカウントは 組織スコープ かつヘッドレスであるため、オートメーションの監査証跡をより明確にできます。
  • 認証情報の取得場所: ユーザーは User Settings からAPIキーをコピーします。組織スコープのサービスアカウント のキーは、組織のダッシュボードの Service account タブにあります。
  • Multi-tenant Cloud: 複数の Multi-tenant Cloud 組織にアクセスできる場合は、SCIM API 呼び出しが意図した組織にルーティングされるように、Default API organization を設定する必要があります。

​
Bearer token

APIキーをBearerトークンとして送信します: 
Authorization: Bearer [API-KEY]
[API-KEY] の値は、そのプリンシパルの HTTP Basic 認証でパスワードとして使用する文字列と同じです。Bearer リクエストでは、キーを Base64 エンコードしないでください。
SCIM API の Bearer 認証は、W&B Multi-tenant Cloud、および 専用クラウド と セルフマネージド v0.79.0 以降で利用できます。
以下の例では、プレースホルダーとして [API-KEY] を使用しています。これを、管理者ユーザーまたは組織スコープのサービスアカウントの実際のキーに置き換えてください。 ユーザーを一覧表示 
curl -s -S \
  -H "Authorization: Bearer [API-KEY]" \
  -H "Content-Type: application/scim+json" \
  "[HOST-URL]/scim/Users"
ユーザーの作成 
curl -s -S -X POST \
  -H "Authorization: Bearer [API-KEY]" \
  -H "Content-Type: application/scim+json" \
  "[HOST-URL]/scim/Users" \
  -d '{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
    "userName": "dev-user2",
    "emails": [{"primary": true, "value": "dev-user2@example.com"}]
  }'
詳細は、Create userを参照してください。

​
Users

対話的な管理タスクを実行する際は、個人の管理者用認証情報を使用してください。HTTP Authorization ヘッダーは Basic <base64(username:API-KEY)> の形式で指定します。 たとえば、demo:p@55w0rd として認証する場合: 
Authorization: Basic ZGVtbzpwQDU1dzByZA==

​
サービスアカウント

自動化やインテグレーションには、組織スコープのサービスアカウントを使用してください。HTTP Authorization ヘッダーは Basic <base64(:API-KEY)> の形式で作成します (先頭にコロンがあり、ユーザー名は空である点に注意してください) 。サービスアカウントのAPIキーは、組織ダッシュボードの Service account タブで確認できます。詳細は 組織スコープのサービスアカウント を参照してください。 たとえば、APIキー sa-p@55w0rd を使用して認証します。 
Authorization: Basic OnNhLXBANTV3MHJk

​
Microsoft Entra ID の設定

このセクションは、SCIM API を介して Microsoft Entra ID から W&B へのユーザーとグループの自動プロビジョニングを設定する場合に使用します。 Entra SSO の設定については、Entra で SSO を設定する を参照してください。

​
テナント URL

Entra エンタープライズ アプリケーションのプロビジョニング設定で、Tenant URL には、Entra の機能フラグ用クエリ パラメーター aadOptscim062020 を付加した W&B SCIM のベース URL を設定します。 
[HOST-URL]/scim?aadOptscim062020
たとえば、インスタンスが https://wandb.example.com にある場合は、テナント URL を https://wandb.example.com/scim?aadOptscim062020 に設定します。 aadOptscim062020 パラメーターは、W&B SCIM API で Entra 固有の処理を有効にします。これがない場合、Entra は JSON の真偽値 (false または true) ではなく、string の真偽値 ("False" または "True") を含むユーザー無効化リクエストを送信することがあり、その結果、無効化に失敗する可能性があります。 Secret Token には、組織管理者ユーザーまたは組織スコープのサービスアカウントの APIキーを設定します。Authentication を参照してください。
テナント URL に aadOptscim062020 を追加すると、Microsoft Entra 管理センターの Provision on demand UI からのユーザー無効化が動作しない場合があります。これは、その UI が依然として string の真偽値を送信するためです。無効化を手動でテストするには、active を false に置き換える PatchOp Operations 形式の SCIM PATCH リクエストを送信してください (Deactivate user を参照) 。

​
チーム名

W&B チームに対応付ける Entra グループ名には、ml-platform や data-science のように、小文字とハイフンを使用してください。W&B に同期するグループの表示名では、スペース、アンダースコア、その他の特殊文字は使用しないでください。

​
ユーザー属性マッピング

SCIM ユーザープロビジョニングのために、Entra で次の属性マッピングを設定します。
W&B custom app attributeソース属性 (Entra)このマッピングを適用この属性を使用してオブジェクトを照合
emails[type eq "work"].valuemailAlwaysYes
activeNot([IsSoftDeleted])Always
displayNamedisplayNameAlways
userNamedisplayNameOnly on object creation
Multi-tenant Cloud では、ユーザーのアカウントは組織によって管理されません。W&B は Multi-tenant Cloud で、SCIM による displayName の更新をサポートしていません。詳しくは、ユーザーの表示名を更新する を参照してください。

​
Group 属性マッピング

Entra で SCIM グループ (チーム) をプロビジョニングするために、次の属性マッピングを設定します。
W&B custom app attributeソース属性 (Entra)Apply this mappingこの属性を使用してオブジェクトを照合
displayNamedisplayNameOnly on object creationYes
membersmembersAlways

​
ユーザー管理

SCIM の user リソースは、W&B Users とサービスアカウントに対応します。このセクションの エンドポイント を使用して、組織内のユーザーとサービスアカウントのプロビジョニング、更新、削除を行います。たとえば、新しい従業員の受け入れ、サービス認証情報のローテーション、退職するユーザーのアクセス削除を行う場合です。 サービスアカウントの概念と UI ワークフローについては、サービスアカウントを使用してワークフローを自動化する を参照してください。
SCIM ユーザー JSON をパースするインテグレーションに対する破壊的変更
  • 専用クラウドおよび セルフマネージド v0.80.1+、ならびに 2026 年 4 月 30 日以降の Multi-tenant Cloud deployment では、/scim/Users からの応答 (GET user、GET users、および ユーザー を返す PATCH 応答を含む) で、emails は SCIM 2.0 に準拠し、小文字のフィールド名 (value、primary、および省略可能な type または display) を持つオブジェクトの JSON 配列としてシリアライズされます。
  • それ以前の release の deployment では、emails は PascalCase のキー (Value、Primary など) を持つ単一の JSON オブジェクトとして返されます。
コードで SCIM の responses から emails を読み取る場合は、emails を配列として扱い、primary のエントリ (または先頭の要素) を読み取ってください。ユーザーを作成または更新するための Request body では、すでに配列形式が使われており、変更はありません。list-users のフィルター emails.value eq "..." も変更ありません。

​
ユーザーを取得

ユーザー ID を使用して、組織内の特定のユーザーまたはサービスアカウントの情報を取得できます。メールアドレスを使用してユーザーの情報を取得することもできます。 サービスアカウントの応答には、accountType (チームスコープのサービスアカウントは SERVICE、組織スコープのサービスアカウントは ORG_SERVICE) が含まれます。サービスアカウントには emails は含まれません。

​
エンドポイント

  • URL: [HOST-URL]/scim/Users/{id}
  • method: GET

​
パラメーター

パラメータータイプ必須説明
idstringYesユーザーの一意の ID

​
例

GET /scim/Users/abc

​
Usersを一覧表示する

組織内のすべてのユーザーとサービスアカウントの一覧を取得します。各リソースには accountType (USER、SERVICE、または ORG_SERVICE) が含まれます。

​
Users をフィルター

/Users エンドポイントでは、ユーザー名またはメールアドレスで Users をフィルターできます。
  • userName eq "value": ユーザー名でフィルター。
  • emails.value eq "value": メールアドレスでフィルター。
例
GET /scim/Users?filter=userName eq "john.doe"
GET /scim/Users?filter=emails.value eq "john@example.com"

​
エンドポイント

  • URL: [HOST-URL]/scim/Users
  • Method: GET

​
例

GET /scim/Users

​
ユーザーを作成

組織内に新しいユーザーを作成します。

​
エンドポイント

  • URL: [HOST-URL]/scim/Users
  • method: POST

​
パラメーター

パラメータータイプ必須説明
emailsarrayはいメールオブジェクトの配列。メインメールアドレスを含める必要があります
userNamestringはい新規ユーザーのユーザー名
modelsSeatstringいいえModels のシートレベルです。full、viewer、none のいずれかです。デフォルトは full です。
weaveRolestringいいえWeave のロールレベルです。full、viewer、none のいずれかです。デフォルトは full です。
registryAccessstringいいえRegistry の利用権限です。enabled または none のいずれかです。省略した場合、実効アクセス権は読み取り時に modelsSeat と weaveRole から決定されます。Multi-tenant Cloud で利用できます。

​
例

POST /scim/Users

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

​
レスポンス

(Status 201)

{
    "active": true,
    "displayName": "Dev User 2",
    "emails": [
        {
            "primary": true,
            "value": "dev-user2@example.com"
        }
    ],
    "id": "def",
    "meta": {
        "resourceType": "User",
        "created": "2023-10-01T00:00:00Z",
        "location": "Users/def"
    },
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "modelsSeat": "full",
    "weaveRole": "full",
    "userName": "dev-user2"
}

​
サービスアカウントをプロビジョニング

組織内に、チームスコープまたは組織スコープのサービスアカウントを作成します。このエンドポイントを使用して、オートメーション、CI/CD、または人間のユーザーに紐付けるべきではないインテグレーション向けのヘッドレスIDを作成します。通常のユーザーを作成する場合は、accountType を省略します。Create user を参照してください。
専用クラウド、セルフマネージド v0.81.0+、および Multi-tenant Cloud で利用できます。
  • userName にはサービスアカウント名を設定します。API はアカウントの表示名として userName を使用するため、リクエストボディ内の displayName は無視されます。
  • サービスアカウントでは emails は必須ではありません。
  • modelsSeat と weaveRole は作成時にはサポートされておらず、指定すると 400 Bad Request を返します。
  • サービスアカウントは PATCH または PUT で更新できず、無効化することもできません。また、SCIM を通じて組織、チーム、または Registry のロールを割り当てることもできません。プロビジョニング後に W&B App でAPIキーを作成してください。

​
エンドポイント

  • URL: [HOST-URL]/scim/Users
  • method: POST

​
パラメーター

パラメータータイプ必須説明
userNamestringYesサービスアカウントの一意の名前。
accountTypestringYesチームスコープのサービスアカウント には SERVICE、組織スコープのサービスアカウント には ORG_SERVICE を指定します。
urn:ietf:params:scim:schemas:extension:teams:2.0:UserobjectYesTeams 拡張オブジェクト。
defaultTeamstringYesTeams 拡張のサブフィールドです。既存の W&B Team の名前を指定します。サービスアカウントはこのチームの Member として作成されます。チームスコープのサービスアカウントが参加するチームは、このチームのみです。組織スコープのサービスアカウントは、後から SCIM によって作成されるチームにも自動的に追加されます。
teamsarrayNoMulti-tenant Cloud のみ。 アカウントを追加するチーム名の配列です。このフィールドを使用する場合は、defaultTeam と同じチームも含めてください。

​
例

POST /scim/Users

{
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User",
        "urn:ietf:params:scim:schemas:extension:teams:2.0:User"
    ],
    "userName": "sa-deploy-bot",
    "accountType": "SERVICE",
    "urn:ietf:params:scim:schemas:extension:teams:2.0:User": {
        "defaultTeam": "ml-platform"
    }
}

​
レスポンス

(Status 201)

{
    "accountType": "SERVICE",
    "active": true,
    "displayName": "sa-deploy-bot",
    "id": "xyz",
    "meta": {
        "resourceType": "User",
        "created": "2023-10-01T00:00:00Z",
        "location": "Users/xyz"
    },
    "organizationRole": "member",
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User",
        "urn:ietf:params:scim:schemas:extension:wandb:2.0:User"
    ],
    "teamRoles": [
        {
            "teamName": "ml-platform",
            "roleName": "member"
        }
    ],
    "urn:ietf:params:scim:schemas:extension:wandb:2.0:User": {
        "organizationRole": "member"
    },
    "userName": "sa-deploy-bot"
}
組織スコープのサービスアカウントでは、accountType は ORG_SERVICE です。 セルフマネージド環境では、organizationRole はアカウントタイプに応じて、member ではなく service または org_service になります。 レスポンスで次のいずれかのエラーが返された場合は、リクエストに次のような一般的な問題がないか確認してください。
  • 409 Conflict: リクエストに、同じサービスアカウントに対する重複した userName キーが含まれています。
  • 400 Bad Request: リクエストで defaultTeam が指定されていないか、無効な値が設定されています。

​
サービスアカウントのプロビジョニング解除

サービスアカウントと、その組織へのメンバーシップを完全に削除します。サービスアカウントが不要になった場合 (たとえば、オートメーション パイプラインを廃止した後) は、このエンドポイントを使用してください。これはハード削除であり、SCIM を介してアカウントを再有効化することはできません。
専用クラウド、セルフマネージド v0.81.0+、および Multi-tenant Cloud で利用できます。サービスアカウントの SCIM ユーザー id は、プロビジョニング時のレスポンス、または Get user から取得したものを使用してください。プロビジョニングを解除しても、すでに発行済みの APIキー は削除されません。必要に応じて、W&B App でキーを個別に失効してください。

​
エンドポイント

  • URL: [HOST-URL]/scim/Users/{id}
  • method: DELETE

​
パラメーター

パラメータータイプ必須説明
idstringYesサービスアカウントの一意の IDです。

​
例

DELETE /scim/Users/xyz

​
ユーザーを削除

管理者アクセスを維持するインスタンスまたは組織には、常に少なくとも1人の管理者ユーザーが存在するようにしてください。そうしないと、組織の W&B アカウントを設定または維持できるユーザーがいなくなります。組織で SCIM または別の自動化プロセスを使用して W&B からユーザーのプロビジョニングを解除している場合、その解除処理によって、意図せずインスタンスまたは組織に残っている最後の管理者が削除される可能性があります。運用手順の策定に関する支援、または管理者アクセスの復旧については、サポート にお問い合わせください。
組織からユーザーを完全に削除します。サービスアカウントを削除するには、サービスアカウントのプロビジョニング解除 を参照してください。

​
エンドポイント

  • URL: [HOST-URL]/scim/Users/{id}
  • method: DELETE

​
パラメーター

パラメータータイプ必須説明
idstringはい削除するユーザーの一意の ID

​
例

DELETE /scim/Users/abc
ユーザーを一時的に無効化するには、PATCH エンドポイントを使用する ユーザーの無効化 API を参照してください。

​
ユーザーのメールアドレスを更新する

ユーザーのメインメールアドレスを更新します。 Multi-tenant Cloud ではサポートされていません。この環境では、ユーザーのアカウントは組織によって管理されません。

​
エンドポイント

  • URL: [HOST-URL]/scim/Users/{id}
  • method: PATCH

​
パラメーター

パラメータータイプ必須説明
idstringYesユーザーの一意の ID
opstringYesreplace
pathstringYesemails
valuearrayYes新しいメールオブジェクトを含む配列

​
例

PATCH /scim/Users/abc

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "replace",
            "path": "emails",
            "value": [
                {
                    "value": "newemail@example.com",
                    "primary": true
                }
            ]
        }
    ]
}

​
ユーザーの表示名を更新する

ユーザーの表示名を更新します。 Multi-tenant Cloud ではサポートされていません。この環境では、ユーザーのアカウントは組織で管理されません。

​
エンドポイント

  • URL: [HOST-URL]/scim/Users/{id}
  • method: PATCH

​
パラメーター

パラメータータイプ必須説明
idstringはいユーザーの一意の ID
opstringはいreplace
pathstringはいdisplayName
valuestringはい新しい表示名

​
例

PATCH /scim/Users/abc

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "replace",
            "path": "displayName",
            "value": "John Doe"
        }
    ]
}

​
ユーザーを無効化

組織内のユーザーを無効化します。結果は、デプロイタイプによって異なります。
  • 専用クラウド / セルフマネージド: ユーザーの active フィールドを false に設定します。無効化したユーザーの組織へのアクセスを復元するには、ユーザーを再有効化 を参照してください。
  • Multi-tenant Cloud: 組織からユーザーを削除します。ユーザーのアクセスを復元するには、そのユーザーを組織に再度追加してください。ユーザーを作成 を参照してください。Multi-tenant Cloud では、ユーザーのアカウントは組織では管理されません。
この操作はユーザーにのみ使用でき、サービスアカウントには対応していません。サービスアカウントの無効化はサポートされていません。チームのサービスアカウントは、W&B Team の Settings で管理してください。

​
エンドポイント

  • URL: [HOST-URL]/scim/Users/{id}
  • method: PATCH

​
パラメーター

パラメータータイプ必須説明
idstringはい無効化するユーザーの一意の ID
opstringはいreplace
valueobjectはい{"active": false} を指定したオブジェクト

​
例

PATCH /scim/Users/abc

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

​
レスポンス

(Status 200)

{
    "active": false,
    "displayName": "Dev User 1",
    "emails": [
        {
            "primary": true,
            "value": "dev-user1@example.com"
        }
    ],
    "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"
}

​
ユーザーを再有効化

組織内で以前に無効化したユーザーを再有効化します。
  • ユーザーの再有効化はユーザーに対してのみ可能で、サービスアカウントには対応していません。サービスアカウントの再有効化はサポートされません。サービスアカウントは W&B Team の設定で管理してください。
  • ユーザーの再有効化は Multi-tenant Cloud ではサポートされません。ユーザーのアクセスを復元するには、そのユーザーを組織に再度追加してください。ユーザーを作成 を参照してください。Multi-tenant Cloud では、ユーザーのアカウントは組織によって管理されません。ユーザーを再有効化しようとすると、HTTP 400 エラーが返されます。レスポンス本文の detail フィールドは API からそのまま返されるため、従来のプロダクト用語が引き続き使われている場合があります。 
    {
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:Error"
    ],
    "detail": "User reactivation operations are not supported in SaaS Cloud",
    "status": "400"
}

​
エンドポイント

  • URL: [HOST-URL]/scim/Users/{id}
  • method: PATCH

​
パラメーター

パラメータータイプ必須説明
idstringはい再有効化するユーザーの一意の ID
opstringはいreplace
valueobjectはい{"active": true} を指定したオブジェクト

​
例

PATCH /scim/Users/abc

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

​
組織ロールを割り当てる

ユーザーに組織レベルのロールを割り当てます。
この操作はユーザーに対してのみ使用でき、サービスアカウントには使用できません。サービスアカウントではカスタムロールはサポートされていません。

​
エンドポイント

  • URL: [HOST-URL]/scim/Users/{id}
  • method: PATCH

​
パラメーター

パラメータータイプ必須説明
idstringはいユーザーの一意の ID
opstringはいreplace
pathstringはいorganizationRole
valuestringはいロール名 (admin または member)
組織スコープの viewer ロールは非推奨となっており、UI で割り当てることはできなくなりました。SCIM を使用してユーザーに viewer ロールを割り当てる場合:
  • そのユーザーには、組織内で member ロールが割り当てられます。
  • そのユーザーの modelsSeat は、full ではなく viewer に設定されます。これにより、Models には閲覧専用で、Registry にはフルアクセスできます。利用可能な Models シートがない場合は、Seat limit reached エラーが返されます。シートが利用可能になれば、後で更新できます。
  • そのユーザーの weaveRole は、full ではなく viewer に設定されます。これにより、Weave には閲覧専用でアクセスできます。
  • そのユーザーの既存のすべてのチームおよび project ロールは、viewer に設定されます。
  • 組織レベルで表示されるレジストリでは、Registry の viewer ロールが割り当てられます。
member または admin の組織ロールを割り当てても、ユーザーの modelsSeat や weaveRole は変更されません。

​
例

PATCH /scim/Users/abc

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

​
シートを更新する

ユーザーの シートを更新します。
Multi-tenant Cloud では、Registry へのアクセスは シートと切り離されています。ユーザーが none 以外の weaveRole を持っている場合、modelsSeat を none に設定しても、Registry へのアクセスは取り消されません。これらのデプロイで Registry へのアクセスを取り消すには、Registry access を更新する を使用し、registryAccess を none に設定します。専用クラウド と セルフマネージド では、 Registry へのアクセスは引き続き modelsSeat に紐付いています。これらのリリースで Registry へのアクセスを取り消すには、modelsSeat を none に設定します。

​
エンドポイント

  • URL: [HOST-URL]/scim/Users/{id}
  • method: PATCH

​
パラメーター

パラメータータイプ必須説明
idstringはいユーザーの一意の ID
opstringはいreplace
pathstringはいmodelsSeat
valuestringはいシートレベル (full、viewer、または none)

​
例

PATCH /scim/Users/abc

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

​
Weave ロールを更新する

ユーザーの Weave ロールを更新します。

​
エンドポイント

  • URL: [HOST-URL]/scim/Users/{id}
  • method: PATCH

​
パラメーター

パラメータータイプ必須説明
idstringはいユーザーの一意の ID
opstringはいreplace
pathstringはいweaveRole
valuestringはいロールレベル (full、viewer、または none)

​
例

PATCH /scim/Users/abc

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

​
Registry アクセスを更新する

ユーザーに対して、組織レベルの Registry アクセスを付与または取り消します。この権限は Registry roles (registryRoles) とは別です。registryRoles は、ユーザーに Registry アクセスが付与された後の Registry ごとの権限を制御します。 Multi-tenant Cloud では、 modelsSeat または weaveRole が none 以外のユーザーには、デフォルトで Registry アクセスが付与されます。Models シートや Weave ロールを変更せずに Registry アクセスを取り消すには、registryAccess を none に設定します。 専用クラウド および セルフマネージド では、 Models シートを更新する を使用し、modelsSeat を none に設定して Registry アクセスを取り消します。これらのリリースでは、registryAccess 属性は使用できません。 作成時に registryAccess を省略すると、ユーザーの modelsSeat と weaveRole に基づいて API が有効なアクセス権を導出し、ユーザーの読み取り時にそれを返します。registryAccess を明示的に指定すると、この導出結果よりもそちらが優先されます。組織ロールが請求専用のユーザーには、この導出によって Registry アクセスは付与されません。

​
エンドポイント

  • URL: [HOST-URL]/scim/Users/{id}
  • method: PATCH

​
パラメーター

パラメータータイプ必須説明
idstringはいユーザーの一意の ID
opstringはいreplace
pathstringはいregistryAccess
valuestringはいRegistry の利用権限 (enabled または none)

​
例

PATCH /scim/Users/abc

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

​
チームロールを割り当てる

ユーザーにチームレベルのロールを割り当てます。
この操作はユーザーにのみ適用され、サービスアカウントには対応していません。サービスアカウントではカスタムロールはサポートされていません。

​
エンドポイント

  • URL: [HOST-URL]/scim/Users/{id}
  • method: PATCH

​
パラメーター

パラメータータイプ必須説明
idstringはいユーザーの一意の ID
opstringはいreplace
pathstringはいteamRoles
valuearrayはいteamName と roleName を含むオブジェクトの配列

​
例

PATCH /scim/Users/abc

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "replace",
            "path": "teamRoles",
            "value": [
                {
                    "roleName": "admin",
                    "teamName": "team1"
                }
            ]
        }
    ]
}

​
Registry に追加

割り当てられた Registry レベルのロールを付与して、ユーザーを Registry に追加します。
この操作はユーザーにのみ対応しており、サービスアカウントでは使用できません。サービスアカウントではカスタムロールはサポートされません。

​
エンドポイント

  • URL: [HOST-URL]/scim/Users/{id}
  • method: PATCH

​
パラメーター

パラメータータイプ必須説明
idstringYesユーザーの一意の ID
opstringYesadd
pathstringYesregistryRoles
valuearrayYesregistryName と roleName を含むオブジェクトの配列

​
例

PATCH /scim/Users/abc

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "replace",
            "path": "registryRoles",
            "value": [
                {
                    "roleName": "admin",
                    "registryName": "hello-registry"
                }
            ]
        }
    ]
}

​
Registry から削除

ユーザーを Registry から削除します。
この操作では、ユーザーを特定の Registry から削除します。組織レベルの Registry アクセスは取り消されません。Registry アクセスを完全に取り消すには、Registry アクセスを更新を使用してください。
  • 削除操作は RFC 7644 SCIM プロトコル仕様に従います。特定の Registry からユーザーを削除するには、フィルター構文 "registryRoles[registryName eq \"{registry_name}\"]" を使用します。すべての Registry からユーザーを削除するには、"registryRoles" を使用します。
  • この操作はユーザーに対してのみ有効で、サービスアカウントには対応していません。サービスアカウントを Registry から削除するには、W&B Team の Settings で行ってください。

​
エンドポイント

  • URL: [HOST-URL]/scim/Users/{id}
  • method: PATCH

​
パラメーター

パラメータータイプ必須説明
idstringはいユーザーの一意の ID
opstringはいremove
pathstringはい"registryRoles[registryName eq \"{registry_name}\"]" または "registryRoles"

​
例

PATCH /scim/Users/abc

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "replace",
            "path": "registryRoles[registryName eq \"goodbye-registry\"]"
        }
    ]
}

PATCH /scim/Users/abc

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "replace",
            "path": "registryRoles"
        }
    ]
}

​
グループリソース

SCIM グループリソースは W&B Team にマッピングされます。このセクションのエンドポイントを使用して、チームの作成、チームメンバーシップの管理、さらにアイデンティティプロバイダまたはオートメーションからのチームレベルのストレージ設定 (任意) を行えます。IAM で SCIM グループを作成すると、対応する W&B Team が作成されてマッピングされ、以降の SCIM グループ操作はそのチームに対して行われます。チームの作成時にカスタムストレージを設定するには、リクエストに storageBucket を含めます。

​
サービスアカウント

SCIM を使用して W&B Team を作成すると、サービスアカウントのチームリソースへのアクセスを維持するため、組織レベルのすべてのサービスアカウントが自動的にそのチームに追加されます。

​
グループの絞り込み

/Groups エンドポイントでは、特定のチームを検索するためのフィルタリングをサポートしています。

​
サポートされるフィルター

/Groups エンドポイントでは、次のフィルターがサポートされます:
  • displayName eq "value": チームの表示名でフィルターします。

​
例

GET /scim/Groups?filter=displayName eq "engineering-team"

​
チームを取得

チームの一意の ID を指定して、チームの情報を取得します。

​
エンドポイント

  • URL: [HOST-URL]/scim/Groups/{id}
  • method: GET

​
例

GET /scim/Groups/ghi

​
チームの一覧

チームの一覧を取得します。

​
エンドポイント

  • URL: [HOST-URL]/scim/Groups
  • method: GET

​
例

GET /scim/Groups

​
チーム を作成

新しい チーム リソースを作成します。

​
エンドポイント

  • URL: [HOST-URL]/scim/Groups
  • method: POST

​
サポートされるフィールド

フィールドタイプ必須
displayNameStringはい
members複数値配列はい (value サブフィールドが必須で、ユーザー ID にマッピングされます)
storageBucketObjectいいえ
チーム の作成時に storageBucket オブジェクトを含めることで、チーム レベルの Bring your own bucket (BYOB) を設定できます。省略した場合、チーム はデフォルトまたはインスタンスレベルのストレージを使用します。BYOB ガイドを参照して、バケット (ポリシー、CORS、認証情報) をプロビジョニングし、プロバイダーごとのストレージアドレス形式を確認してください。storageBucket オブジェクトには、次のサブフィールドがあります。
  • 必須: name (バケット名) 、provider (COREWEAVE、AWS、AZURE、GCP、MINIO のいずれか) 。値では大文字と小文字が区別されるため、表示されているとおりに大文字を使用してください。
  • 任意: path (バケット内のパス接頭辞) 、kmsKeyId (暗号化用の KMS キー。AWS などで使用) 、awsExternalId (AWS のクロスアカウントアクセス) 、azureTenantId (Azure テナント ID) 、azureClientId (Azure マネージドアイデンティティのクライアント ID) 。
W&B は、チーム を作成する前に、そのバケットが存在し到達可能であることを検証します。検証に失敗した場合、SCIM リクエストは失敗し、チーム は作成されません。 provider の値が無効な場合は、許可される値を示す SCIM エラーとともに 400 Bad Request が返されます。

​
例

以下の例では、カスタム ストレージを使用しないチーム、および特定のプロバイダーで BYOB ストレージを使用するチームの作成方法を示します。リクエスト例を確認するには目的のストレージ設定のタブを選択し、レスポンス例を確認するには レスポンス タブを選択してください。 
POST /scim/Groups

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

​
チームを更新

既存のチームのメンバー一覧を更新します。

​
エンドポイント

  • URL: [HOST-URL]/scim/Groups/{id}
  • Method: PATCH
  • サポートされる操作: add メンバーの追加、remove メンバーの削除、replace メンバーの置換。
  • remove 操作は RFC 7644 SCIM プロトコル仕様に従います。特定のユーザーを削除するには、フィルター構文 members[value eq "{user_id}"] を使用します。チームからすべてのユーザーを削除するには、members を使用します。 ユーザーの識別: メンバー操作での {user_id} には、次のいずれかを使用できます。
    • W&B ユーザー ID。
    • メールアドレス (例: “user@example.com”) 。
  • これらの操作はユーザーに対してのみ機能し、サービスアカウントには対応していません。チームのサービスアカウントは、W&B Team の設定で更新してください。
リクエスト内の {team_id} は実際のチーム ID に、{user_id} は実際のユーザー ID またはメールアドレスに置き換えてください。

​
チームメンバーの置き換え

チームのすべてのメンバーを新しいリストに置き換えます。
この操作はユーザーにのみ適用され、サービスアカウントには対応していません。サービスアカウントは W&B Team の Settings で管理してください。

​
エンドポイント

  • URL: [HOST-URL]/scim/Groups/{id}
  • Method: PUT
PUT /scim/Groups/{team_id}

{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
    "displayName": "acme-devs",
    "members": [
        {
            "value": "{user_id_1}"
        },
        {
            "value": "{user_id_2}"
        }
    ]
}

​
チームにユーザーを追加する

acme-devs に dev-user2 を追加する場合:
この操作はユーザーにのみ適用され、サービスアカウントには対応していません。サービスアカウントは W&B Team の Settings で管理してください。
PATCH /scim/Groups/{team_id}

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

​
チームから特定のユーザーを削除する

acme-devs から dev-user2 を削除する場合:
この操作はユーザーにのみ有効で、サービスアカウントには使用できません。サービスアカウントは W&B Team の Settings で管理してください。
PATCH /scim/Groups/{team_id}

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "remove",
            "path": "members[value eq \"{user_id}\"]"
        }
    ]
}

​
チームからすべてのユーザーを削除する

acme-devs からすべてのユーザーを削除します:
この操作はユーザーにのみ有効で、サービスアカウントには使用できません。サービスアカウントは W&B Team の Settings で管理してください。
PATCH /scim/Groups/{team_id}

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

​
チームを削除

チームには追加のデータが関連付けられているため、SCIM API ではチームを削除できません。すべての関連データを含めて削除してよいことを確認するには、W&B App からチームを削除してください。

​
Role resource

SCIM のロールリソースは、W&B のカスタムロールに対応しています。このセクションのエンドポイントを使用すると、カスタムロールをプログラムで作成および管理できます (たとえば、ロール定義をアクセスポリシーと同期した状態に保つためです) 。/Roles エンドポイントは公式の SCIM スキーマの一部ではありません。W&B では組織内のカスタムロールを自動管理できるようにするため、/Roles エンドポイントを追加しています。

​
カスタムロール情報を取得

ロールの一意の ID を指定して、カスタムロールの情報を取得します。

​
エンドポイント

  • URL: [HOST-URL]/scim/Roles/{id}
  • Method: GET

​
例

GET /scim/Roles/abc

​
カスタムロールの一覧

W&B 組織内のすべてのカスタムロールの情報を取得します。

​
エンドポイント

  • URL: [HOST-URL]/scim/Roles
  • Method: GET

​
例

GET /scim/Roles

​
カスタムロールを作成

W&B 組織に新しいカスタムロールを作成します。

​
エンドポイント

  • URL: [HOST-URL]/scim/Roles
  • Method: POST

​
サポートされるフィールド

フィールドタイプ必須
nameStringカスタムロール名
descriptionStringカスタムロールの説明
permissionsObject array権限オブジェクトの配列です。各オブジェクトには、値が w&bobject:operation 形式の name 文字列フィールドが含まれます。たとえば、W&B の run に対する delete 操作の権限オブジェクトでは、name は run:delete になります。
inheritedFromStringカスタムロールが継承元とする事前定義ロールです。member または viewer のいずれかを指定できます。

​
例

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

​
カスタムロールを更新する

以下のセクションでは、既存のカスタムロールに権限を追加または削除する方法を説明します。

​
ロールに権限を追加する

既存のカスタムロールに権限を追加します。
エンドポイント
  • URL: [HOST-URL]/scim/Roles/{id}
  • Method: PATCH
PATCH /scim/Roles/{role_id}

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "add",
            "path": "permissions",
            "value": [
                {
                    "name": "project:delete"
                },
                {
                    "name": "run:stop"
                }
            ]
        }
    ]
}

​
ロールから権限を削除する

既存のカスタムロールから権限を削除します。
エンドポイント
  • URL: [HOST-URL]/scim/Roles/{id}
  • Method: PATCH
PATCH /scim/Roles/{role_id}

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "remove",
            "path": "permissions",
            "value": [
                {
                    "name": "project:update"
                }
            ]
        }
    ]
}

​
カスタムロールを置き換える

カスタムロール定義全体を置き換えます。

​
エンドポイント

  • URL: [HOST-URL]/scim/Roles/{id}
  • Method: PUT
PUT /scim/Roles/{role_id}

{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Role"],
    "name": "Updated custom role",
    "description": "Updated description for the custom role",
    "permissions": [
        {
            "name": "project:read"
        },
        {
            "name": "run:read"
        },
        {
            "name": "artifact:read"
        }
    ],
    "inheritedFrom": "viewer"
}

​
カスタムロールを削除

W&B組織内のカスタムロールを削除します。この操作は注意して使用してください。削除前にそのカスタムロールが割り当てられていたすべてのユーザーには、カスタムロールの継承元である事前定義ロールが割り当てられます。

​
エンドポイント

  • URL: [HOST-URL]/scim/Roles/{id}
  • Method: DELETE

​
例

DELETE /scim/Roles/abc

​
高度な機能

以下のセクションでは、SCIM インテグレーションを本番環境で安全に運用するのに役立つオプション機能 (ETag ベースの同時実行制御と標準エラー応答) について説明します。

​
ETag サポート

SCIM API は、同時変更による競合を防ぐため、条件付き更新で ETags をサポートしています。これは、複数の管理者または自動化システムが同じリソースを更新する場合に重要です。1 つの更新によって別の更新が気付かないうちに上書きされるのを防げるためです。ETags は、レスポンスヘッダー ETag と meta.version フィールドで返されます。

​
ETags

ETagを使用するには、次のstepに従います:
  1. 現在のETagを取得: リソースをGETした際に、レスポンスのETagヘッダーを確認します。
  2. 条件付き更新: 更新時に、If-MatchヘッダーにETagを含めます。

​
例

# ユーザーを取得してETagを記録する
GET /scim/Users/abc
# レスポンスに含まれる内容: ETag: W/"xyz123"

# ETagを使用して更新する
PATCH /scim/Users/abc
If-Match: W/"xyz123"

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [
        {
            "op": "replace",
            "path": "organizationRole",
            "value": "admin"
        }
    ]
}
412 Precondition Failed エラーのレスポンスは、取得後にそのリソースが変更されたことを示します。

​
エラー処理

SCIM APIは標準のSCIMエラーレスポンスを返します。
ステータスコード説明
200成功
201作成済み
204No Content (削除成功)
400Bad Request: 無効なパラメーターまたはリクエストボディ
401Unauthorized: 認証に失敗
403Forbidden: 権限不足
404Not Found: リソースが存在しません
409Conflict: リソースはすでに存在します
412Precondition Failed: ETag の不一致
500Internal Server Error

​
デプロイタイプごとの実装の違い

W&B では 2 種類の SCIM API 実装を提供しており、利用できる機能はそれぞれ異なります。SCIM と統合する前に以下の表を確認し、利用している操作がご利用のデプロイタイプで使用可能かどうかを確認してください。
機能Multi-tenant Cloud専用クラウドとセルフマネージド
ユーザーのメールアドレスを更新-✓
ユーザーの表示名を更新-✓
ユーザーの無効化✓✓
ユーザーの再有効化-✓
ユーザーごとに複数のメールアドレス✓-
作成/更新時に modelsSeat を設定✓✓
作成/更新時に weaveRole を設定✓✓
作成/更新時に registryAccess を設定✓-
modelsSeat: none で Registry へのアクセスを取り消す-✓
registryAccess: none で Registry へのアクセスを取り消す✓-

​
制限事項

SCIM インテグレーションを設計する際は、次の制約事項に留意してください:
  • 最大結果数: 1リクエストあたり9,999件。
  • 専用クラウド と セルフマネージド: 1ユーザーにつきメールアドレスは1つのみサポートされます。
  • チーム の削除: SCIM 経由ではサポートされません (W&B の Web インターフェイスを使用してください) 。
  • ユーザー の再有効化: Multi-tenant Cloud 環境ではサポートされません。
  • シート数の制限: 組織のシート数制限に達すると、処理が失敗する場合があります。