外部 OAuth の概要

外部 OAuth は顧客の OAuth 2.0サーバーを統合して、特にSnowflakeに接続するプログラムクライアントアプリケーションのためのシームレスな SSO エクスペリエンスを提供します。外部 OAuth トピックでは、 OAuth 2.0を使用して外部 OAuth を構成し、サポートされている認証サーバー、カスタムクライアント、およびサポートされているパートナーアプリケーションのSnowflakeデータへの安全なプログラムアクセスを促進します。

Snowflakeは、外部 OAuth サーバー3つ、カスタム統合1つ、パートナーアプリケーション1つをサポートしています。

  1. Okta

  2. Microsoft Azure AD

  3. Ping Identity PingFederate

  4. 外部 OAuth カスタムクライアント

  5. Power BI SSO からSnowflakeへ

Snowflakeロールへの必要な OAuth 2.0スコープ マッピングを含む、組織の外部 OAuth サーバーを構成した後、ユーザーは追加の認証または認証要素またはメソッドを入力することなく、Snowflakeに安全かつプログラムで接続できます。Snowflakeデータへのユーザーのアクセスは、ユーザーのロールと、セッションのアクセストークンに統合されるロールの両方に依存しています。詳細については、 スコープ (このトピック内)をご参照ください。

このトピックの内容:

ユースケースおよび利点

  1. Snowflakeは、トークンの発行を専用の認証サーバーに委任して、 OAuth クライアントとユーザーが適切に認証されるようにします。その結果、Snowflakeに発行されるトークンの集中管理を実現できます。

  2. お客様は、認証(例:多要素、サブネット、生体認証など)および許可(例:許可なし、マネージャー許可が必要)などのポリシーを認証サーバーに統合できます。その結果、ユーザーにチャレンジを発行することにより、セキュリティが強化され、より堅牢なデータ保護を実現できます。ユーザーがポリシーチャレンジに合格しない場合、Snowflakeセッションはインスタンス化されず、Snowflakeデータへのアクセスは発生しません。

  3. Snowflakeにアクセスできるプログラムクライアント、および外部 OAuth からのみSnowflakeセッションを開始するユーザーの場合、Snowflakeにおける追加の認証構成(パスワードの設定)は必要ありません。その結果、プログラムアクセスにのみ使用するサービスアカウントまたはユーザーは、外部 OAuth 構成サービスを通過するときにのみSnowflakeデータを使用できます。

  4. クライアントはブラウザーにアクセスせずにSnowflakeに対して認証できるため、外部 OAuth サーバーとの統合が容易になります。

  5. Snowflakeの外部 OAuth サーバーとの統合はクラウドに依存しません。

    • 認証サーバーがクラウドプロバイダーのクラウドに存在するか、認証サーバーがオンプレミスであるかは関係ありません。その結果顧客は、Snowflakeと対話するための認証サーバーの構成に関して多くのオプションを利用できます。

一般的なワークフロー

サポートされている各IDプロバイダーについて、外部 OAuth 認証サーバーに関連する OAuth のワークフローは次のように要約できます。最初のステップは1回だけ実行され、残りのステップはSnowflakeデータへのアクセス試行ごとに実行されることに注意してください。

workflow overview
  1. 環境内の外部 OAuth 認証サーバーとSnowflakeのセキュリティ統合を構成して、信頼を確立します。、

  2. ユーザーは、ビジネスインテリジェンスアプリケーションを介してSnowflakeデータにアクセスしようとし、アプリケーションはユーザーを確認しようとします。

  3. 確認時に認証サーバーは、 JSON ウェブトークン(つまり、 OAuth トークン)をクライアントアプリケーションに送信します。

  4. Snowflakeドライバーは、 OAuth トークンを使用して接続文字列をSnowflakeに渡します。

  5. Snowflakeは OAuth トークンを検証します。

  6. Snowflakeはユーザー検索を実行します。

  7. 確認時にSnowflakeは、ユーザーのロールに基づいてSnowflakeのデータにアクセスするためのセッションをインスタンス化します。

スコープ

認証サーバーのスコープパラメーターは、アクセストークンによって許可される操作とロール、およびSnowflakeセッションのインスタンス化後にユーザーがアクセスできるものを制限します。 ACCOUNTADMIN および SECURITYADMIN の役割はデフォルトでブロックされていることに注意してください。これら2つのロールのいずれかまたは両方を使用する必要がある場合は、Snowflakeサポートにお問い合わせください。

  • Okta、 PingFederate、およびカスタムの場合、次のテーブルのロールスコープパターンを使用します。

  • Azure AD については、 前提条件のステップ:Azure AD で OAuth フローを決定する をご参照ください。

  • 外部 OAuth サーバー内でのSnowflakeロールの管理を望まない場合は、トークンのスコープ属性で SESSION:ROLE-ANY の静的な値を渡します。

次のテーブルは、外部 OAuth スコープをまとめたものです。 スコープを定義しないと、Snowflakeへの接続試行は失敗 します。

スコープ/ロール接続パラメーター

説明

session:role-any

Snowflakeの ANY ロールにマップします。 . Snowflakeでのユーザーの既定のロールが望ましい場合、このスコープを外部 OAuth トークンで渡します。 . 特定の外部 OAuth プロバイダーの ANY ロールを有効にするには、 external_oauth_any_role_mode セキュリティ統合パラメーターを構成する必要があります。 . 構成の詳細については、 OktaAzure ADPingFederate、または カスタム の ANY ロールセクションをご参照ください。

session:role:<カスタムロール>

Snowflakeのカスタムロールにマップします。たとえば、カスタムロールが ANALYST の場合、スコープは session:role:analyst です。

session:role:public

Snowflakeの PUBLIC ロールにマップします。

トラブルシューティング

  • SYSTEM$VERIFY_EXTERNAL_OAUTH_TOKEN 関数を使用して、外部 OAuth アクセストークンが有効であるか、再生成する必要があるかを判断します。