SCIM を使用したユーザーとグループの管理¶
このトピックでは、以下について説明します。
SnowflakeとのSCIM 統合。
SnowflakeのSCIM ユースケース。
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 を使用して、次のユースケースに対処できます。
ユーザーライフサイクル管理
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によるユーザーライフサイクル管理をサポートしています。ユーザーライフサイクル管理は、ユーザーが組織全体でとる経路と一致する管理アクティビティです。ユーザーのライフサイクルの一般的なイベントには、これらのアクティビティが含まれます。
ユーザーの作成とアクティブ化。
email
またはpassword
などのユーザー属性を更新しています。終了時にユーザーを非アクティブ化します。
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ユーザー属性 |
型 |
説明 |
---|---|---|---|
|
|
文字列 |
Snowflakeにあるユーザーの不変で一意の識別子(つまり、 GUID)。 Snowflakeは、この値を DESCRIBE USER または SHOW USERS 出力では公開しません。 この属性を含む特定のリクエストパス(例: PATCH)の場合、 IdP ログをチェックして、値が一致していることを確認します。 |
|
|
文字列 |
Snowflakeにログインするための識別子。これらのSnowflake属性の詳細については、 CREATE USER をご参照ください。 |
|
|
文字列 |
ユーザーの名。 |
|
|
文字列 |
ユーザーの姓。 |
|
|
文字列 |
ユーザーのメールアドレス。この値は単一のメールアドレスをサポートします。 |
|
|
文字列 |
ユーザーインターフェイスに表示されるユーザーの名前。 |
|
N/A |
文字列 |
プロビジョニングクライアント(例: Azure、Okta)によって設定された一意の識別子。 |
|
|
文字列 |
ユーザーのパスワード。この値は JSON 応答で返されません。 注: SCIM セキュリティ統合 |
|
|
ブール値 |
|
|
N/A |
文字列 |
ユーザーが属するグループのリスト。グループのdisplayNameは必須です。 ユーザーのグループは読み取り専用であり、メンバーシップは SCIM グループ API で更新する必要があります。 |
|
|
文字列 |
ユーザーがSnowflakeに追加された時間。 |
|
|
文字列 |
ユーザーがSnowflakeで最後に変更された時刻。 |
|
N/A |
文字列 |
ユーザーにはユーザーの値が必要です。 |
|
N/A |
文字列 |
名前空間 URIs を示す文字列のコンマ区切りの配列。サポートされている値には次が含まれます。
|
カスタム属性¶
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 |
メモ |
---|---|---|
ユーザーが存在することを確認します。 |
|
成功した場合は、指定された |
特定のユーザーの詳細を取得する |
|
成功した場合は、指定された |
特定のユーザーの詳細を取得する |
|
成功した場合は、 SCIM クライアントがスキーマを読み取れる、 |
ユーザーを作成します。 |
|
Snowflakeでユーザーを作成し、成功した場合は HTTP ユーザーがすでに存在する場合、または別の競合が発生した場合、Snowflakeは HTTP |
部分的な属性でユーザーを更新します。 |
|
現在非アクティブ化されているユーザーをアクティブ化するには、 PATCH 属性値を置き換えることを示す配列を持つ操作キー(つまり、 成功した場合は |
ユーザーを更新します。 |
|
指定された それ以外の場合は、リクエストに基づいて読み取り/書き込みまたは書き込み専用の属性を置き換えます。 リクエスト本文の不変の属性値がSnowflakeの値と一致しない場合は、 HTTP ステータスコード |
ユーザーを削除します。 |
|
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グループ属性 |
型 |
説明 |
---|---|---|---|
|
|
文字列 |
Snowflakeにあるロールの不変で一意の識別子(つまり、 GUID)。 Snowflakeはこの値を公開しません。これは、Information Schemaテーブル関数 REST_EVENT_HISTORY を呼び出すことで見つけることができます。 IdP ログをチェックして、値が一致していることを確認します。 |
|
|
文字列 |
ユーザーインターフェイスに表示されるロールの名前。 |
|
N/A |
文字列 |
ロールのメンバーであるユーザーの userID 値。 |
|
N/A |
文字列 |
名前空間 URIs を示す文字列の配列。 例: |
ロール APIs¶
フィルターを使用してロール情報を取得し、ロールの作成、ロールメンバーシップの更新、ロールの削除もできます。Snowflakeは、ロール管理を容易にするために次の APIs をサポートしています。
目的 |
メソッドと API |
メモ |
---|---|---|
表示名でグループを取得します。 |
|
成功した場合は、指定された |
|
|
成功した場合は、指定された |
サンプルグループを取得します。 |
|
成功した場合は、 SCIM クライアントがスキーマを読み取れる、 |
新しいグループを作成します。 |
|
成功した場合は、 |
グループを更新します。 |
|
グループ表示名の属性またはグループのメンバーシップを更新します。 PATCH には、追加するか置き換えるかを示す配列を持つ操作(つまり、 成功した場合は |
グループを削除します。 |
|
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にプロビジョニング、管理、同期できます。
Okta
Microsoft Azure Active Directory
カスタム
注釈
カスタム 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 セキュリティ統合により、ソースアカウントからターゲットアカウントへの複製とフェールオーバー/フェールバックをサポートします。
詳細については、 複数のアカウントにわたるセキュリティ統合とネットワークポリシーの複製 をご参照ください。
次のトピック: