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	string	Snowflakeのユーザーの不変で一意の識別子（つまり、 GUID）。 . Snowflakeは、この値を DESCRIBE USER または SHOW USERS の出力に公開しません。 . この属性を含む特定のリクエストパス（例： PATCH）の場合、 id はSnowflakeテーブル rest_event_history にあります。 . IdP ログをチェックして、値が一致していることを確認します。
userName	userName、 loginName	string	ユーザーがログインに使用するユーザー名。
name.givenName	firstName	string	ユーザーの名。
name.familyName	familyName	string	ユーザーの姓。
emails	email	string	1つのメールアドレスのみをサポートします。
displayName	displayName	string	ユーザーインターフェイスに表示されるユーザーの名前。
externalID	N/A	string	プロビジョニングクライアント（例：Azure、Okta）によって設定された一意の識別子。
password	password	string	ユーザーのパスワード。この値は JSON 応答で返されません。
active	disabled	ブール値	false に設定されている場合は、ユーザーを無効にします。
groups	N/A	string	ユーザーが属するグループのリスト。グループのdisplayNameは必須です。ユーザーのグループは読み取り専用であり、メンバーシップは SCIM グループ API で更新する必要があります。
meta.created	createdON	string	ユーザーがSnowflakeに追加された時間。
meta.lastModified	lastModified	string	ユーザーがSnowflakeで最後に変更された時刻。
meta.resourceType	N/A	string	ユーザーにはユーザーの値が必要です。
schemas	N/A	string	名前空間 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 など、 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 "{{ユーザー名}}"	成功した場合、指定された userName と200ステータスコードを持つユーザーアカウントの詳細を返します。
特定のユーザーの詳細を取得する	GET scim/v2/Users/{{ユーザーID}}	成功した場合、指定された user_id と200ステータスコードを持つユーザーアカウントの詳細を返します。
特定のユーザーの詳細を取得する	GET scim/v2/Users?startIndex=0&count=1	成功した場合、 SCIM クライアントがスキーマを読み取れるように、200ステータスコードを持つサンプルユーザーを返します。
ユーザーを作成する	POST scim/v2/Users	Snowflakeでユーザーを作成し、成功すると201ステータスコードを返します。 . ユーザーが既に存在するか、別の競合が発生した場合、Snowflakeは409ステータスコードを返します。
部分的な属性でユーザーを更新する	PATCH scim/v2/Users/{ID}	active キーがfalseに設定されている場合、対応するユーザーを無効にします。現在非アクティブ化されているユーザーをアクティブ化するには、 active をtrueに設定します。 . PATCH には、属性値を置き換えることを示す配列を持つオペレーションキー（つまり、 op）が必要です。 . 成功した場合は200のステータスコードを返し、成功しなかった場合は204（つまり、コンテンツなし）を返します。
ユーザーを更新する	PUT scim/v2/Users/{ID}	指定された id を持つユーザーが存在するかどうかを確認します。不変の属性の変更が要求された場合、この操作は失敗します。 . それ以外の場合は、要求に基づいて読み取り/書き込みまたは書き込み専用属性を置き換えます。 . リクエスト本文の不変の属性値がSnowflakeの値と一致しない場合は、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つを使用する 必要 があります。

注釈

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はこの値を公開しません。Snowflakeテーブル 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 と200ステータスコードを持つグループの詳細を返します。
groupId でグループを取得する	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 には、追加または置換するかどうかを示す配列を持つ操作（つまり、 op）キーが必要です。 . 成功した場合は200のステータスコードを返し、成功しなかった場合は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 は、 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にプロビジョニング、管理、同期できます。

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 統合 の手順に従ってください。

次のトピック:

• SnowflakeとのOkta SCIM 統合
• SnowflakeとAzure SCIM の統合
• Snowflakeとのカスタム SCIM 統合
• SCIM API リクエストの実行