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ユーザー属性 |
型 |
説明 |
---|---|---|---|
|
|
string |
Snowflakeのユーザーの不変で一意の識別子(つまり、 GUID)。 . Snowflakeは、この値を DESCRIBE USER または SHOW USERS の出力に公開しません。 . この属性を含む特定のリクエストパス(例: PATCH)の場合、 |
|
|
string |
ユーザーがログインに使用するユーザー名。 |
|
|
string |
ユーザーの名。 |
|
|
string |
ユーザーの姓。 |
|
|
string |
1つのメールアドレスのみをサポートします。 |
|
|
string |
ユーザーインターフェイスに表示されるユーザーの名前。 |
|
N/A |
string |
プロビジョニングクライアント(例:Azure、Okta)によって設定された一意の識別子。 |
|
|
string |
ユーザーのパスワード。この値は JSON 応答で返されません。 |
|
|
boolean |
false に設定されている場合、ユーザーを無効にします。 |
|
N/A |
string |
ユーザーが属するグループのリスト。グループのdisplayNameは必須です。ユーザーのグループは読み取り専用であり、メンバーシップは SCIM グループ API で更新する必要があります。 |
|
|
string |
ユーザーがSnowflakeに追加された時間。 |
|
|
string |
ユーザーがSnowflakeで最後に変更された時刻。 |
|
N/A |
string |
ユーザーにはユーザーの値が必要です。 |
|
N/A |
string |
名前空間 URIs を示す文字列のコンマ区切りの配列。 . urn:ietf:params:scim:schemas:core:2.0:User . urn:ietf:params:scim:schemas:extension:enterprise:2.0:User |
ユーザー APIs¶
Snowflakeは、ユーザーのライフサイクル管理を容易にするために、次の APIs をサポートしています。フィルターを使用してユーザー情報を取得し、ユーザーを作成、更新、非アクティブ化、削除することもできます。
目的 |
メソッドと API |
メモ |
---|---|---|
ユーザーが存在するかどうかを確認する |
GET scim/v2/Users?filter=userName eq "{{ユーザー名}}" |
成功した場合、指定された |
特定のユーザーの詳細を取得する |
GET scim/v2/Users/{{ユーザーID}} |
成功した場合、指定された |
特定のユーザーの詳細を取得する |
GET scim/v2/Users?startIndex=0&count=1 |
成功した場合、 SCIM クライアントがスキーマを読み取れるように、200ステータスコードを持つサンプルユーザーを返します。 |
ユーザーを作成する |
POST scim/v2/Users |
Snowflakeでユーザーを作成し、成功すると201ステータスコードを返します。 . ユーザーが既に存在するか、別の競合が発生した場合、Snowflakeは409ステータスコードを返します。 |
部分的な属性でユーザーを更新する |
PATCH scim/v2/Users/{ID} |
|
ユーザーを更新する |
PUT scim/v2/Users/{ID} |
指定された |
ユーザーを削除する |
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}
ユーザーを更新します。
現在、
"defaultWarehouse"
フィールドと"defaultRole"
フィールドの設定はOktaでのみ可能です。Azure AD では、この構成をサポートしていません。注釈
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": { "defaultWarehouse" : "test_warehouse", "defaultRole" : "test_role" } }
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はこの値を公開しません。Snowflakeテーブル |
|
|
文字列 |
ユーザーインターフェイスに表示されるロールの名前。 |
|
N/A |
文字列 |
ロールのメンバーであるユーザーの userID 値。 |
|
N/A |
文字列 |
名前空間 URIs を示す文字列の配列。 . 例: |
ロール APIs¶
フィルターを使用してロール情報を取得し、ロールの作成、ロールメンバーシップの更新、ロールの削除もできます。Snowflakeは、ロール管理を容易にするために次の APIs をサポートしています。
目的 |
メソッドと API |
メモ |
---|---|---|
表示名でグループを取得する |
GET scim/v2/Groups?filter=displayName="scim_test_group" |
成功した場合、指定された |
|
GET scim/v2/Groups/{グループID} |
成功した場合、指定されたgroupIdと200ステータスコードを持つグループの詳細を返します。 |
サンプルグループを取得する |
GET scim/v2/Groups?startIndex=0&count=1 |
成功した場合、 SCIM クライアントがスキーマを読み取れるように、200ステータスコードを持つサンプルグループを返します。 |
新しいグループを作成する |
POST scim/v2/Groups |
成功した場合、201ステータスコードを持つ新しいグループを作成します。 |
グループを更新する |
PATCH scim/v2/Groups/{ID} |
グループ表示名属性またはグループメンバーシップを更新します。 . PATCH には、追加または置換するかどうかを示す配列を持つ操作(つまり、 |
グループを削除する |
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 は、 rest_event_history
テーブルをクエリして、過去5分間に行われた200リクエストまでの SCIM REST API リクエストを判別する代表的な例です。
use role accountadmin;
use database demo_db;
use schema information_schema;
select * from table(rest_event_history('scim'));
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 統合 の手順に従ってください。
次のトピック: