Snowflake用のIDプロバイダー（IdP）の構成¶

IdP を構成するタスクは、Snowflakeユーザー用のフェデレーション認証を提供するために、Okta、 AD FS、または別の（つまり、カスタム） SAML 2.0準拠のサービス/アプリケーションを選択するどうかによって異なります。

このトピックの内容：

Oktaの設定
AD FS 設定
カスタム IdP 設定

注釈

これらの IdP 固有のタスクを完了したら、フェデレーション認証を使用するためのSnowflakeの構成をして設定を完了します。

重要

IdP を構成する前に、完全に構成された後にフェデレーション認証を管理する方法と、ユーザーがフェデレーション認証を介してSnowflakeにアクセスする方法を検討してください。

たとえば、ユーザーがパブリック URL を介してSnowflakeにアクセスするか、AWSPrivateLink またはAzure Private Linkに関連付けられた URL を介してアクセスするかを決定します。詳細については、フェデレーション認証の管理/使用をご参照ください。

Oktaの設定¶

Oktaをフェデレーション認証の IdP として使用するには、Oktaで次のタスクを実行する必要があります。

会社または組織のOktaアカウントを作成します。
管理者権限を持つユーザーとしてOktaアカウントにログインし、Snowflakeへのアクセスが必要なユーザーごとにユーザーを作成します。ユーザーを作成するときは、各ユーザーのメールアドレスが必須です。OktaのユーザーとSnowflakeの対応するユーザーをマップするにはメールアドレスが必須です。

注釈

Okta値に入力するメールアドレスがSnowflakeの login_name 値と SAML NameID 属性にマップされていることを確認してください。

詳細については、フェデレーション認証を使用するためのSnowflakeの構成のステップ1をご参照ください。
OktaでSnowflakeアプリケーションを作成します。
- アプリケーションの Label フィールドでは、任意の名前を指定できます。
- アプリケーションの SubDomain フィールドに、Snowflakeアカウントの名前（Snowflakeが提供）を入力します。
- お住まいの地域が US 西部ではない場合は、 SubDomain フィールドに地域を含める必要があります。
作成したOktaユーザーをOktaのSnowflakeアプリケーションに割り当てます。
作成したSnowflakeアプリケーションのサインオン方法として SAML 2.0を構成します。次のステップフェデレーション認証を使用するためのSnowflakeの構成で SSO URL 値と証明書が必要になります。
- Sign On タブで、 View Setup Instructions をクリックします。
- 設定手順から必要な情報を収集します。
  - SSO URL （Snowflakeが SAML リクエストを送信する IdP URL エンドポイント）
  - 証明書（ IdP とSnowflake間の通信を確認するために使用）

AD FS 設定¶

AD FS をフェデレーション認証の IdP として使用するには、 AD FSで次のタスクを実行する必要があります。

前提条件¶

AD FS 3.0がWindows Server 2012 R2にインストールされ、動作していることを確認します。
Snowflakeへのアクセスが必要な利用者ごとに、ユーザーが AD FS に存在することを確認します。ユーザーを作成するときは、各ユーザーのメールアドレスが必須です。 AD FS のユーザーをSnowflakeの対応するユーザーに接続するには、メールアドレスが必須です。

注釈

他のバージョンの AD FS およびWindows Serverも使用できます。ただし、構成手順は異なる場合があります。

ステップ1：Snowflake用の証明書利用者信頼を追加する¶

AD FS 管理コンソールで、 Add Relying Party Trust Wizard を使用して、新しい証明書利用者の信頼を AD FS 構成データベースに追加します。

プロンプトが表示されたら、 Enter data about the relying party manually ラジオボタンを選択します。
次の画面で、証明書利用者の表示名を入力します（例：「Snowflake」）。
次の画面で、 AD FS profile ラジオボタンを選択します。
次の画面をスキップします（オプションのトークン暗号化証明書を指定するため）。

次の画面：

Enable support for the SAML 2.0 WebSSO protocol チェックボックスを選択します。

証明書利用者 SAML 2.0 SSO サービス URL フィールドに、Snowflakeアカウントの SSO URL を入力します。 URL の形式は、アカウントが置かれている地域によって異なります。

US 西部（AWS）: https://<アカウント名>.snowflakecomputing.com/fed/login
その他の地域: https://<アカウント名>.<地域ID>.snowflakecomputing.com/fed/login
AWS PrivateLink を使用: https://<アカウント名>.<地域ID>.privatelink.snowflakecomputing.com/fed/login
Azure Private Linkでの使用: https://<アカウント名>.<地域ID>.privatelink.snowflakecomputing.com/fed/login

<アカウント名> はアカウントの名前（Snowflakeが提供）で、 <地域ID> は次のとおりです。

地域	地域 ID	メモ
Amazon Web Services（AWS）
US 西部（オレゴン）	`us-west-2`	US 西部のアカウントに AWS PrivateLink を設定する場合にのみ必要です。
US 東部（オハイオ）	`us-east-2.aws`
US 東部（バージニア北部）	`us-east-1`
US 東部（商業組織、バージニア政府北部）	`us-east-1-gov.aws`	Business Critical（またはそれ以上）のアカウントでのみ使用できます。Snowflakeがまだサポートしていない独立した専用クラウドである、 AWS GovCloud （US）には位置していません。
カナダ（中部）	`ca-central-1.aws`
EU （アイルランド）	`eu-west-1`
ヨーロッパ（ロンドン）	`eu-west-2.aws`
EU （フランクフルト）	`eu-central-1`
アジア太平洋（東京）	`ap-northeast-1.aws`
アジア太平洋（ムンバイ）	`ap-south-1.aws`
アジア太平洋（シンガポール）	`ap-southeast-1`
アジア太平洋（シドニー）	`ap-southeast-2`
Google Cloud Platform（GCP）
US 中央部1（アイオワ）	`us-central1.gcp`
ヨーロッパ西部2（ロンドン）	`europe-west2.gcp`
ヨーロッパ西部4（オランダ）	`europe-west4.gcp`
Microsoft Azure
西 US 2（ワシントン）	`west-us-2.azure`
東 US 2（バージニア）	`east-us-2.azure`
US 政府バージニア	`us-gov-virginia.azure`	Business Critical（またはそれ以上）のアカウントでのみ利用可能です。
カナダ中央部（トロント）	`canada-central.azure`
西ヨーロッパ（オランダ）	`west-europe.azure`
スイス北部（チューリッヒ）	`switzerland-north.azure`
東南アジア（シンガポール）	`southeast-asia.azure`
オーストラリア東部（ニューサウスウェールズ）	`australia-east.azure`

次の画面の Relying party trust identifier フィールドに、Snowflakeのアカウントの URL を入力します。入力した以前の URL と同様に、アカウントのある地域によって形式が異なります。

US 西部（AWS）

https://<アカウント名>.snowflakecomputing.com

その他の地域

https://<アカウント名>.<地域ID>.snowflakecomputing.com

AWS PrivateLink を使用

https://<アカウント名>.<地域ID>.privatelink.snowflakecomputing.com

Azure Private Linkでの使用

https://<アカウント名>.<地域ID>.privatelink.snowflakecomputing.com
次の画面で、 I do not want to configure multi-factor authentication settings for this relying party trust at this time ラジオボタンを選択します。
次の画面で、 Permit all users to access this relying party ラジオボタンを選択します。
次の画面で、証明書利用者信頼の構成を確認します。また、 Advanced タブで、 SHA-256 がセキュアハッシュアルゴリズムとして選択されていることを確認します。
次の画面で Open the Edit Claim Rules dialog for this relying party trust when the wizard closes を選択し、 Close をクリックしてウィザードの構成を完了します。

ステップ2：Snowflake証明書利用者信頼の要求規則を定義する¶

ウィザードを閉じると、 Edit Claim Rules for snowflake信頼名 ウィンドウが自動的に開きます。次をクリックして、 AD FS 管理コンソールからこのウィンドウを開くこともできます。

AD FS » Trust Relationships » Relying Party Trusts » Snowflake信頼の名前 » Edit Claim Rules...

ウィンドウでは、

要求として LDAP 属性を送信するための規則を作成します。
1. Add Rules をクリックして Send LDAP Attributes as Claim を選択します。
2. Edit Rule ダイアログで、
  - 規則の名前を入力します（例：「属性の取得」）。
    - Attribute store を Active Directory に設定します。
    - 規則に2つの LDAP 属性を追加します。
      - 発信要求タイプとして E-Mail-Addresses と E-Mail Address を使用します。
      - 発信要求タイプとして Display-Name と Name を使用します。
3. OK ボタンをクリックして、規則を作成します。
受信要求を変換するための規則を作成します。
1. Add Rules をクリックして Transform an Incoming Claim を選択します。
2. Add Transform Claim Rule Wizard ダイアログで、
  - 要求規則の名前を入力します（例：「名前 ID 変換」）。
  - Incoming claim type を E-Mail Address に設定します。
  - Outgoing claim type を Name ID に設定します。
  - Outgoing name ID format を Email に設定します。
  - Pass through all claim values ラジオボタンを選択します。
3. Finish ボタンをクリックして、規則を作成します。
OK ボタンをクリックして、Snowflake証明書利用者信頼の要求規則の追加を完了します。

重要

上記のとおりに規則の値が入力されていることを確認します。

また、作成した規則が次の順序でリストされていることを確認します。

LDAP 属性
受信要求変換

規則にタイプミスがあるか、規則が正しい順序でリストされていない場合、規則は正しく機能しません。

ステップ3：グローバルログアウトを有効にする --- オプション¶

AD FS でSnowflakeのグローバルログアウトを有効にするには、 AD FS 管理コンソールで次をクリックします。

AD FS » Trust Relationships » Relying Party Trusts » <snowflake_trust_name> » Properties

Properties ダイアログで、

Endpoints タブに移動して、 Add SAML... ボタンをクリックします。
Edit Endpoint ダイアログで、
- Endpoint type を SAML Logout に設定します。
- Binding を POST または REDIRECT に設定します。
- Trusted URL を次のように設定します。
  
  US 西部（AWS）
  
  <アカウント名>.snowflakecomputing.com/fed/logout
  
  その他の地域
  
  <アカウント名>.<地域ID>.snowflakecomputing.com/fed/logout
  
  AWS PrivateLink を使用
  
  <アカウント名>.<地域ID>.privatelink.snowflakecomputing.com/fed/logout
  
  Azure Private Linkでの使用
  
  <アカウント名>.<地域ID>.privatelink.snowflakecomputing.com/fed/logout
- Response URL を空白のままにします。
- OK ボタンをクリックして、変更を保存します。

ステップ4： SSO URL と証明書を取得する¶

AD FS のセットアップを完了するには、 AD FS から SSO URL と証明書を取得します。次のステップでこれら2つの値を使用します。フェデレーション認証を使用するためのSnowflakeの構成。

SSO URL
Snowflakeが SAML リクエストを送信する先の AD FS URL エンドポイント。これは通常、AD FS用のログイン URL で、IP アドレスまたは AD FS サーバーの完全修飾ドメイン名（すなわち FQDN）の末尾に /adfs/ls が追加されているものが一般的です。
認証
AD FS とSnowflake間の通信を確認するために使用されます。 AD FS 管理コンソールからダウンロードします。
1. コンソールで、次をクリックします。
  
  AD FS » Service » Certificates
2. Certificates ページで、 Token-signing エントリを右クリックし、 View Certificate... をクリックします。
3. Certificate ダイアログで、 Details タブを選択します。
4. Copy to File... をクリックして、証明書のエクスポートウィザードを開きます。
5. エクスポートファイル形式については、 Base-64 encoded X.509 (.CER) を選択して Next をクリックします。
6. ファイルをローカル環境のディレクトリに保存します。
7. ファイルを開き、証明書をコピーします。証明書は、次の行の間にある単一行で構成されています。
```
-----BEGIN CERTIFICATE-----
<certificate>
-----END CERTIFICATE-----
```

カスタム IdP 設定¶

SAML 2.0準拠のサービスまたはアプリケーションをフェデレーション認証の IdP として使用するには、次のタスクを実行する必要があります。

サービス/アプリケーションインターフェイスで、Snowflakeのカスタム SHA-256アプリケーションを定義します。カスタムアプリケーションを定義する手順は、 IdP として機能しているサービス/アプリケーション固有です。
インターフェイスで、Snowflakeへのアクセスが必要な利用者ごとにユーザーを作成します。ユーザーを作成するときは、各ユーザーのメールアドレスが必須です。 IdP のユーザーをSnowflakeの対応するユーザーに接続するには、メールアドレスが必須です。
カスタム IdP から SSO URL と証明書を取得します。次のステップフェデレーション認証を使用するためのSnowflakeの構成で SSO URL 値と証明書が必要になります。
- SSO URL （Snowflakeが SAML リクエストを送信する IdP URL エンドポイント）
- 証明書（ IdP とSnowflake間の通信を確認するために使用）

重要

カスタムIDプロバイダーを構成する場合、フィールド値では大文字と小文字が区別されることがよくあります。エラーメッセージまたはエラーコードが表示される場合は、構成プロセスで入力した可能性のある値の大文字と小文字を再確認してください。