SCIM を使用したユーザーとグループの管理

.

関連トピック

• アクセス制御の概要

このトピックでは、以下について説明します。

1. SnowflakeとのSCIM 統合。

2. SnowflakeのSCIM ユースケース。

3. Snowflake SCIM APIs を使用した、IDプロバイダーへのリクエス送信。

SCIM の概要

SCIM は、 RESTful APIsを使用したクラウドアプリケーションでのユーザーIDとグループ（つまり、ロール）の自動管理を容易にするオープン仕様です。

これらの APIs は、 JSON 形式のキーと値のペア属性で一般的なメソッド（例： GET、POST）を使用します。ユーザー属性のセットは、ユーザーに固有です。同様に、グループ属性のセットはグループに固有です

現在、Snowflakeは SCIM 2.0をサポートし、SnowflakeをOktaおよびMicrosoft Azure ADと統合します。これらは両方ともIDプロバイダーとして機能します。Snowflakeは、OktaでもMicrosoft AzureでもないIDプロバイダー（つまり、カスタム）もサポートしています。IDプロバイダーのユーザーとグループは、サービスプロバイダーとして機能するSnowflakeにプロビジョニングできます。

重要

Snowflakeの特定の SCIM ロールは、IDプロバイダーからインポートされるユーザーとロールを所有する必要があります。Snowflake SCIM ロールがインポートされたユーザーまたはロールを所有していない場合、IDプロバイダーの更新はSnowflakeに同期されません。Snowflake SCIM ロールはIDプロバイダー（IdP）に固有であり、次のとおりです。

• Okta SCIM ロール： okta_provisioner

• Azure AD SCIM ロール： aad_provisioner

• カスタム SCIM ロール： generic_scim_provisioner

Snowflake SCIM ロールの使用方法の詳細については、 Okta、 Azure AD、および カスタム SCIM 統合 の SCIM 構成セクションをご参照ください。

IDプロバイダーは SCIM クライアントを使用して、Snowflake SCIM サーバーに RESTful API リクエストを送信します。 API リクエストを検証すると、Snowflakeはユーザーまたはグループに対してアクションを実行します。

認証プロセスは OAuth ベアラートークンを使用し、このトークンは6か月間有効です。お客様は認証トークンを追跡する必要があり、オンデマンドで新しいトークンを生成できます。各 API リクエスト中に、トークンは認証ベアラーパラメーターとしてヘッダーに渡されます。

Snowflake SCIM の初期構成後、Snowflake SCIM API を使用して、次のユースケースに対処できます。

1. ユーザーライフサイクル管理

2. Active DirectoryグループをSnowflakeロールにマップする

ご用心

現在、Snowflake SCIM API により、管理者は お客様のIDプロバイダーからSnowflakeへ のユーザーとグループを管理できます。

したがって、ユーザーとグループのIDおよびアクセス管理にSnowflake SCIM API を使用する場合、 Snowflakeでユーザーとグループの変更を行わないでください （これらの変更はお客様のIDプロバイダーに同期されません）。

SCIM のユースケース

Snowflake SCIM API は、次のユースケースに対処できます。

ユーザーの管理

管理者は、組織のIDプロバイダーからSnowflakeにユーザーをプロビジョニングおよび管理できます。ユーザー管理は、IDプロバイダーからSnowflakeへの1対1のマッピングです。

ロールの管理

管理者は、組織のIDプロバイダーからSnowflakeへのグループ（つまり、ロール）をプロビジョニングおよび管理できます。ロール管理は、IDプロバイダーからSnowflakeへの1対1のマッピングです。

監査

管理者は rest_event_history テーブルをクエリして、IDプロバイダーがSnowflakeに更新（つまり SCIM API リクエスト）を送信しているかどうかを判断できます。

SCIM を使用したユーザーの管理

Snowflakeは、 SCIM APIsによるユーザーライフサイクル管理をサポートしています。ユーザーライフサイクル管理は、ユーザーが組織全体でとる経路と一致する管理アクティビティです。ユーザーのライフサイクルの一般的なイベントには、これらのアクティビティが含まれます。

1. ユーザーの作成とアクティブ化。

2. email または password などのユーザー属性を更新しています。

3. 終了時にユーザーを非アクティブ化します。

Snowflakeでは、 SCIM を使用したユーザーライフサイクルオートメーションでは、 API リクエストの本文でユーザー属性を渡す必要があります。IDプロバイダーからの正常な API リクエストは、ほぼすぐにSnowflakeのユーザーに影響します。

ユーザー属性

ユーザー属性は、ユーザーに関連付けられているキーと値のペアです。これらのペアは、表示名やメールアドレスなど、ユーザーに関する情報です。IDプロバイダーは、 surname、 familyName、または lastName など、属性キーを異なる方法で定義することがあります。これらはすべてユーザーの姓を示します。Snowflakeは、複数値のユーザー属性をサポートしていません。

Snowflake SCIM API は、ユーザー属性を JSON 形式で渡します。これは、対応するユーザー API の例に示されています。

Snowflakeは、ユーザーライフサイクル管理のために次の SCIM 属性をサポートしています。特に明記しない限り、属性は書き込み可能です。

重要

表では、Snowflake userName および loginName 属性は両方とも SCIM 属性 userName にマップされています。Snowflakeは、 userName と loginName のSnowflake属性に対して異なる値をサポートしています。この属性値の分離により、お客様は、Snowflakeへのアクセスに使用できる属性値をより詳細に制御できます。

詳細については、 POST および PATCHのユーザー API の例をご参照ください。

SCIM ユーザー属性	Snowflakeユーザー属性	型	説明
id	id	文字列	Snowflakeにあるユーザーの不変で一意の識別子（つまり、 GUID）。 Snowflakeは、この値を DESCRIBE USER または SHOW USERS 出力では公開しません。 この属性を含む特定のリクエストパス（例: PATCH）の場合、 id は、 REST_EVENT_HISTORY テーブル関数を呼び出すことで見つけることができます。 IdP ログをチェックして、値が一致していることを確認します。
userName	userName、 loginName	文字列	Snowflakeにログインするための識別子。これらのSnowflake属性の詳細については、 CREATE USER をご参照ください。
name.givenName	firstName	文字列	ユーザーの名。
name.familyName	familyName	文字列	ユーザーの姓。
emails	email	文字列	ユーザーのメールアドレス。この値は単一のメールアドレスをサポートします。
displayName	displayName	文字列	ユーザーインターフェイスに表示されるユーザーの名前。
externalID	N/A	文字列	プロビジョニングクライアント（例: Azure、Okta）によって設定された一意の識別子。
password	password	文字列	ユーザーのパスワード。この値は JSON 応答で返されません。 注: SCIM セキュリティ統合 SYNC_PASSWORD プロパティが FALSE に設定され、 SCIM API リクエストが password 属性を指定している場合、Snowflakeは password 属性の値を無視します。API リクエストにある他のすべての属性は、それに応じて処理されます。
active	disabled	ブール値	false に設定されている場合は、ユーザーを無効にします。
groups	N/A	文字列	ユーザーが属するグループのリスト。グループのdisplayNameは必須です。 ユーザーのグループは読み取り専用であり、メンバーシップは SCIM グループ API で更新する必要があります。
meta.created	createdON	文字列	ユーザーがSnowflakeに追加された時間。
meta.lastModified	lastModified	文字列	ユーザーがSnowflakeで最後に変更された時刻。
meta.resourceType	N/A	文字列	ユーザーにはユーザーの値が必要です。
schemas	N/A	文字列	名前空間 URIs を示す文字列のコンマ区切りの配列。サポートされている値には次が含まれます。 urn:ietf:params:scim:schemas:core:2.0:User urn:ietf:params:scim:schemas:extension:enterprise:2.0:User urn:ietf:params:scim:schemas:extension:2.0:User

カスタム属性

Snowflakeは、 defaultRole、 defaultWarehouse および defaultSecondaryRoles など、 RFC 7643 で定義されていないカスタム属性の設定をサポートしています。

現在Snowflakeは、2つの名前空間を使用して、次の POST、 PUT、および PATCH API リクエストのカスタム属性を設定することをサポートしています。

urn:ietf:params:scim:schemas:extension:enterprise:2.0:User

この名前空間は、Snowflakeの元の SCIM 実装の一部であり、Okta SCIM 統合のカスタム属性を設定するためにのみ使用できます。

この名前空間は、Microsoft Azure SCIM 統合またはカスタム SCIM 統合のカスタム属性の設定をサポートして いません。

urn:ietf:params:scim:schemas:extension:2.0:User

この新しい名前空間は、すべての SCIM 統合のカスタム属性を設定するために使用でき、カスタム SCIM 統合またはMicrosoft Azure SCIM 統合のいずれかを使用するカスタム属性に使用する 必要 があります。

ユーザー APIs

Snowflakeは、ユーザーのライフサイクル管理を容易にするために、次の APIs をサポートしています。フィルターを使用してユーザー情報を取得し、ユーザーを作成、更新、非アクティブ化、削除することもできます。

目的	メソッドと API	メモ
ユーザーが存在することを確認します。	GET scim/v2/Users?filter=userName eq "{{user_name}}"	成功した場合は、指定された userName と、 200 の HTTP ステータスコードを持つユーザーアカウントの詳細を返します。
特定のユーザーの詳細を取得する	GET scim/v2/Users/{{user_id}}	成功した場合は、指定された user_id と、 200 の HTTP ステータスコードを持つユーザーアカウントの詳細を返します。
特定のユーザーの詳細を取得する	GET scim/v2/Users?startIndex=0&count=1	成功した場合は、 SCIM クライアントがスキーマを読み取れる、 200 の HTTP ステータスコードを持つサンプルユーザーを返します。
ユーザーを作成します。	POST scim/v2/Users	Snowflakeでユーザーを作成し、成功した場合は HTTP 201 ステータスコードを返します。 ユーザーがすでに存在する場合、または別の競合が発生した場合、Snowflakeは HTTP 409 ステータスコードを返します。
部分的な属性でユーザーを更新します。	PATCH scim/v2/Users/{id}	active キーがfalseに設定されている場合、対応するユーザーを無効にします。 現在非アクティブ化されているユーザーをアクティブ化するには、 active をtrueに設定します。 PATCH 属性値を置き換えることを示す配列を持つ操作キー（つまり、 op）が必要です。 成功した場合は 200 の HTTP ステータスコードを返し、成功しなかった場合は 204 （つまり、コンテンツなし）を返します。
ユーザーを更新します。	PUT scim/v2/Users/{id}	指定された id を持つユーザーが存在するかどうかを確認します。不変の属性の変更がリクエストされた場合は、この操作に失敗します。 それ以外の場合は、リクエストに基づいて読み取り/書き込みまたは書き込み専用の属性を置き換えます。 リクエスト本文の不変の属性値がSnowflakeの値と一致しない場合は、 HTTP ステータスコード 400 を返します。
ユーザーを削除します。	DELETE scim/v2/Users/{id}

SCIM API リクエストの詳細については、 SCIM API リクエストの実行 をご参照ください。

POST scim/v2/Users

同じ 値にマップされた userName と loginName を持つユーザーを作成します。

{
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User",
        "urn:ietf:params:scim:schemas:extension:2.0:User"
        ],
    "userName": "test_user_1",
    "password": "test",
    "name": {
        "givenName": "test",
        "familyName": "user"
        },
    "emails": [{
        "value": "test.user@snowflake.com"
        }
    ],
    "displayName": "test user",
    "active": true
}

異なる 値にマップされた userName と loginName を持つユーザーを作成します。

OktaがIDプロバイダーである場合は、この 手順 に従います。

{
    "active": true,
    "displayName": "test user",
    "emails": [
        {
            "value": "test.user@snowflake.com"
        }
    ],
    "name": {
        "familyName": "test_last_name",
        "givenName": "test_first_name"
    },
    "password": "test_password",
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User",
        "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
    ],
    "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
        "snowflakeUserName": "USER5"
    },
    "userName": "USER5"
}

PATCH scim/v2/Users/{ID}

同じ 値にマップされた userName と loginName を持つユーザーを更新します。

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

異なる 値にマップされた userName と loginName を持つユーザーを更新します。

OktaがIDプロバイダーである場合は、この 手順 に従います。

{
    "Operations": [
        {
            "op": "Replace",
            "path": "userName",
            "value": "test_updated_name"
        },
        {
            "op": "Replace",
            "path": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User.snowflakeUserName",
            "value": "USER5"
        }
    ],
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:PatchOp"
    ]
}

PUT scim/v2/Users/{ID}

"defaultRole" フィールド、 "defaultSecondaryRoles" フィールド、および "defaultWarehouse" フィールドの設定を含め、ユーザーを更新します。

"defaultRole" プロパティ、 "defaultSecondaryRoles" プロパティ、および "defaultWarehouse" プロパティを指定するには、Snowflakeで extension スキーマ の1つを使用する 必要があります。 defaultSecondaryRoles に使用できる値は "ALL" のみであることに注意してください。

注釈

Snowflakeはこれをサポートしていますが、 PATCH 操作よりもコストが高いため、 PUT 操作の使用には注意が必要です。代わりに PATCH 操作を使用してください。

{
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User",
        "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
        ],
    "userName": "test_user_1",
    "password": "test",
    "name": {
        "givenName": "test",
        "familyName": "user"
        },
    "emails": [{
        "primary": true,
        "value": "test.user@snowflake.com",
        "type": "work"
        }
    ],
    "displayName": "test user",
    "active": true,
    "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
        "defaultRole" : "test_role",
        "defaultSecondaryRoles" : "ALL",
        "defaultWarehouse" : "test_warehouse"
    }
}

SCIMを使用したロールの管理

Snowflakeは、 SCIM を使用してOkta、Azure AD 、およびカスタムビルドアプリケーションからロールをインポートすることをサポートしています。これらのロールと、Snowflakeロールとの直接的な1対1のマッピングがあります。

通常、グループと同義のロールは、アクセス権限の論理的なコレクションです。Snowflakeモデルでは、セキュリティ保護可能なオブジェクトへのアクセスは、ロールに割り当てられた権限を介して許可され、その権限は他のロールまたはユーザーに割り当てられます。

ロールに付与されたアクセス許可と権限は、ロールのすべてのメンバー（例: ユーザー）によって自動的に継承されます。詳細については、 アクセス制御の概要 をご参照ください。

ユーザーが組織内でのキャリアパスを進むにつれて、Snowflakeへのアクセス要件が変わる可能性があります。たとえば、ユーザーは、個々のコントリビューターから直接のレポートを使用するマネージャーに変更される場合があります。ロールが変わると、Snowflakeでのアクセスでは、マネージャーのみが使用できるデータセットを許可する必要が生じる可能性があります。

組織内でユーザーのロールメンバーシップが変更されると、組織のロールが対応するSnowflakeロールにマップされた後に、Snowflakeへのアクセスが自動的に変更されます。

ロール属性

Snowflake SCIM API は、ロール属性を JSON 形式で渡します。これは、対応する API の例に示されています。

Snowflakeは、ロールライフサイクル管理のために次の SCIM 属性をサポートしています。特に明記しない限り、属性は書き込み可能です。

SCIM グループ属性	Snowflakeグループ属性	型	説明
id	id	文字列	Snowflakeにあるロールの不変で一意の識別子（つまり、 GUID）。 Snowflakeはこの値を公開しません。これは、Information Schemaテーブル関数 REST_EVENT_HISTORY を呼び出すことで見つけることができます。 IdP ログをチェックして、値が一致していることを確認します。
displayName	name	文字列	ユーザーインターフェイスに表示されるロールの名前。
members.value	N/A	文字列	ロールのメンバーであるユーザーの userID 値。
schemas	N/A	文字列	名前空間 URIs を示す文字列の配列。 例: urn:ietf:params:scim:schemas:core:2.0:Group。

ロール APIs

フィルターを使用してロール情報を取得し、ロールの作成、ロールメンバーシップの更新、ロールの削除もできます。Snowflakeは、ロール管理を容易にするために次の APIs をサポートしています。

目的	メソッドと API	メモ
表示名でグループを取得します。	GET scim/v2/Groups?filter=displayName="scim_test_group"	成功した場合は、指定された displayName と HTTP ステータスコード 200 を持つグループの詳細を返します。
groupId でグループを取得する	GET scim/v2/Groups/{group_id}	成功した場合は、指定された groupId と HTTP ステータスコード 200 を持つグループの詳細を返します。
サンプルグループを取得します。	GET scim/v2/Groups?startIndex=0&count=1	成功した場合は、 SCIM クライアントがスキーマを読み取れる、 200 の HTTPステータスコードを持つサンプルグループを返します。
新しいグループを作成します。	POST scim/v2/Groups	成功した場合は、 201 の HTTP ステータスコードをもつ新しいグループを作成します。
グループを更新します。	PATCH scim/v2/Groups/{id}	グループ表示名の属性またはグループのメンバーシップを更新します。 PATCH には、追加するか置き換えるかを示す配列を持つ操作（つまり、 op）キーが必要です。 成功した場合は 200 の HTTP ステータスコードを返し、成功しなかった場合は 204 （つまり、コンテンツなし）を返します。
グループを削除します。	DELETE scim/v2/Groups/{id}

SCIM API リクエストの詳細については、 SCIM API リクエストの実行 をご参照ください。

POST scim/v2/Groups

{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
    "displayName":"scim_test_group2"
}

PATCH scim/v2/Groups/{ID}

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [{
        "op": "replace",
        "value": {
            "displayName": "updated_name"
            }
        },
        {
            "op" : "remove",
            "path": "members[value eq \"user_id_1\"]"
        },
        {
          "op": "add",
          "value": [{
            "value": "user_id_2"
            }]
        }
    ]
}

SCIM を使用した監査

Snowflakeをクエリして、指定された時間の間隔でどの SCIM API リクエストが行われたかを判断することができます。

たとえば、この情報は、Snowflakeにプロビジョニングする必要がある組織のアクティブなユーザー集団が、Snowflakeにプロビジョニングしたユーザーと一致するかどうかを判断するのに役立ちます。

以下の SQL は、Information Schemaテーブル関数 REST_EVENT_HISTORY を呼び出して、過去5分間にあった SCIM REST API リクエストを最大200件まで判別する代表的な例です。

use role accountadmin;
use database demo_db;
use schema information_schema;
select *
    from table(rest_event_history(
        'scim',
        dateadd('minutes',-5,current_timestamp()),
        current_timestamp(),
        200))
    order by event_timestamp;

このクエリを変更する方法の詳細については、 DATEADD および CURRENT_TIMESTAMP 関数をご参照ください。

サポートされている SCIM 統合

Snowflakeは、次のIDプロバイダーと統合して、ユーザーおよびグループをSnowflakeにプロビジョニング、管理、同期できます。

1. Okta

2. Microsoft Azure Active Directory

3. カスタム

   注釈

   カスタム SCIM 統合により、Snowflakeのユーザーとグループをプロビジョニング、管理、同期するための専用の統合を持たないIDプロバイダーを使用できます。

   現在、OktaでもMicrosoft Azure AD でもないIDプロバイダーには、カスタム SCIM 統合を使用する必要があります。

IDプロバイダーとしてOktaを使用しているお客様は、 SnowflakeとのOkta SCIM 統合 の手順に従ってください。

IDプロバイダーとしてMicrosoft Azure Active Directoryを使用しているお客様は、 SnowflakeとAzure SCIM の統合 の手順に従ってください。

IDプロバイダーとしてOktaまたはMicrosoft Azure Active Directoryを使用していないお客様は、独自の SCIM クライアントを作成し、 Snowflakeとのカスタム SCIM 統合 の手順に従ってください。

SCIM での複製の使用

Snowflakeは、 SCIM セキュリティ統合により、ソースアカウントからターゲットアカウントへの複製とフェールオーバー/フェールバックをサポートします。

詳細については、 複数のアカウントにわたるセキュリティ統合およびネットワークポリシーの複製 をご参照ください。

次のトピック:

• SnowflakeとのOkta SCIM 統合

• SnowflakeとAzure SCIM の統合

• Snowflakeとのカスタム SCIM 統合