フェデレーション認証と SSO の概要¶
このトピックでは、ユーザーを認証するためのフェデレーション環境を構成するコンポーネント、およびSnowflakeでサポートされる SSO (シングルサインオン)ワークフローについて説明します。
フェデレーション環境とは¶
フェデレーション環境では、ユーザー認証情報の独立した認証を提供する1つ以上の外部エンティティを使用して、ユーザー認証をユーザーアクセスから分離します。その後、認証は1つ以上のサービスに渡され、ユーザーは SSO を介してサービスにアクセスできます。フェデレーション環境は、次のコンポーネントで構成されています。
- サービスプロバイダー(SP):
Snowflakeのフェデレーション環境では、Snowflakeは SPとして機能します。
- IDプロバイダー(IdP):
次のサービスを SP に提供する外部の独立したエンティティ:
ユーザー認証情報およびその他のプロファイル情報の作成と維持。
SSO アクセス( SPへの)のためのユーザー認証。
Snowflakeは、 大半の SAML 2.0準拠ベンダーを IdP としてサポートしています。ただし、特定のベンダーでは、Snowflakeのネイティブサポートが含まれています(詳細については以下を参照)。
サポートされているIDプロバイダー¶
次のベンダーは、 ネイティブ Snowflakeサポートをフェデレーション認証とSSO で提供しています。
Okta
Microsoft Entra ID
Oktaおよび Entra ID が提供するネイティブのSnowflakeサポートに加えて、Snowflakeは 大半の SAML 2.0準拠のベンダーを IdP として使用することをサポートしています。
注釈
IdP としてOktaまたは Entra ID 以外を使用するには、 IdPでSnowflakeのカスタムアプリケーションを定義する必要があります。
Okta、|microsoft-idp-short|または別のSAML2.0準拠ベンダーをSnowflakeのIdPとして構成する方法の詳細については、:doc:`admin-security-fed-auth-configure-idp`をご参照ください。
複数のIDプロバイダーの使用¶
異なるユーザーが異なるIDプロバイダーを使用して認証するようにSnowflakeを構成できます。
すべてのIDプロバイダーを構成 したら、 フェデレーション認証に複数のIDプロバイダーを使用する のガイダンスに従ってください。
注釈
現在、複数のIDプロバイダーの使用をサポートしているのは、Snowflakeドライバーのサブセットのみです。これらのドライバーには、 JDBC、 ODBC、Pythonが含まれます。
サポートされている SSO ワークフロー¶
フェデレーション認証により、次の SSO ワークフローが有効になります。
Snowflakeへのログイン。
Snowflakeからログアウト。
非アクティブによるシステムのタイムアウト。
各ワークフローの動作は、Snowflakeまたは IdP 内でアクションが開始されるかどうかによって決まります。
ログインのワークフロー¶
ユーザーがログインすると、システムの動作は、Snowflakeまたは IdP のどちらからログインが開始されるかによって決まります。
- Snowflakeが開始するログイン:
Snowflakeからログインするには、次の方法があります。
ユーザーはSnowflakeのウェブインターフェイスにアクセスします。
注釈
URL でSnowflakeにアクセスしているユーザーが、認証のためにSnowflakeサインインページを見ることなく IdP にリダイレクトされるように、Snowflakeを構成できます。詳細については、 ALTER ACCOUNT をご参照ください。
ユーザーは、アカウントに構成された IdP (Okta、Entra ID、またはカスタム IdP)を使用してログインすることを選択します。
ユーザーは、 IdP 認証情報(電子メールアドレスやパスワードなど)を使用して IdP で認証します。
認証が成功すると、 IdP は SAML 応答をSnowflakeに送信してセッションを開始し、Snowflakeのウェブインターフェイスを表示します。
- IdP が開始するログイン:
アカウントの IdP からログインするには、次の方法があります。
ユーザーは IdP サイト/アプリケーションにアクセスし、 IdP 認証情報(電子メールアドレスやパスワードなど)を使用して認証します。
IdPで、ユーザーはSnowflakeアプリケーション(Oktaまたは|microsoft-idp-short|を使用している場合)、またはIdPで定義されているカスタムアプリケーション(別のIdPを使用している場合)を選択します。
IdP は SAML 応答をSnowflakeに送信してセッションを開始し、Snowflakeのウェブインターフェイスを表示します。
ログアウトのワークフロー¶
ユーザーがログアウトすると、利用可能なオプションは IdP が グローバル ログアウトをサポートするか、 標準 ログアウトのみをサポートするかによって決まります。
- 標準:
ユーザーが完全に切断するには、 IdP とSnowflakeの両方から明示的にログアウトする必要があります。すべての IdPs は標準ログアウトをサポートしています。
- グローバル:
ユーザーが IdP からログアウトし、その後すべてのSnowflakeセッションをログアウトできるようにします。グローバルログアウトのサポートは IdP に依存しています。
さらに、システムの動作は、Snowflakeまたは IdP のどちらからログアウトを開始するかによって決まります。
- Snowflakeが開始するログアウト:
IdP がサポートするかどうかに関係なく、Snowflake内からのグローバルログアウトはサポートされません。ユーザーがSnowflakeセッションからログアウトすると、そのセッションからのみログアウトします。他のすべてのSnowflakeセッションは、 IdP セッションと同様に開いたままです。その結果、他のセッションで作業を継続したり、 IdPを介して再認証することなく追加のセッションを開始したりできます。
完全に切断するには、ユーザーはSnowflakeと IdP の両方から明示的にログアウトする必要があります。
- IdP が開始したログアウト:
ユーザーが IdPからログアウトするときの動作は、 IdP が標準のログアウトのみをサポートするか、グローバルログアウトもサポートするかによって異なります。
Entra ID は標準ログアウトとグローバルログアウトの両方をサポートします。グローバルログアウトが有効になっている場合、 Entra ID IdP ログインページには、ユーザーがアクセスしたすべてのサイトからサインアウトするためのオプションがあります。このオプションを選択すると、ユーザーは|microsoft-idp-short|およびすべてのSnowflakeセッションからログアウトします。Snowflakeに再度アクセスするには、 |microsoft-idp-short|を使用して再認証する必要があります。
Oktaは標準ログアウトのみをサポートします。ユーザーがOktaからログアウトしても、アクティブなSnowflakeセッションから自動的にログアウトされることはなく、作業を続行できます。ただし、新しいSnowflakeセッションを開始するには、Oktaを介して再度認証する必要があります。
すべてのカスタムプロバイダーは標準ログアウトをサポートしています。グローバルログアウトのサポートはプロバイダーによって異なります。
注釈
ウェブベースのIdPの場合(たとえば、Okta)、ブラウザーのタブ/ウィンドウを閉じてもIdPセッションが終了するとは限りません。ユーザーの IdP セッションがまだアクティブな場合、 IdP セッションがタイムアウトするまでSnowflakeにアクセスできます。
タイムアウトのワークフロー¶
ユーザーのセッションがタイムアウトすると、タイムアウトするのはSnowflakeセッションか IdP セッションかによって動作が決定されます。
- Snowflakeのタイムアウト:
ユーザーが SSO を使用してSnowflakeにログインし、非アクティブのためにSnowflakeのセッションが期限切れになると、Snowflakeのウェブインターフェイスが無効になり、 IdP 認証のプロンプトが表示されます。
期限切れのSnowflakeセッションを引き続き使用するには、ユーザーは IdP を介して再度認証する必要があります。
ユーザーは:extui:`Cancel`ボタンを選択すると、セッションを終了できます。
ユーザーは IdP サイト/アプリケーションに直接移動してSnowflakeを再起動することもできますが、これにより新しいSnowflakeセッションが開始されます。
- IdP タイムアウト:
指定された期間( IdPで定義)後、 IdP のユーザーのセッションは自動的にタイムアウトしますが、これはSnowflakeセッションに影響しません。その時点でアクティブなSnowflakeセッションは開いたままで、再認証を必要としません。ただし、新しいSnowflakeセッションを開始するには、ユーザーは再度 IdP にログインする必要があります。
プライベート接続での SSO¶
Snowflakeは、Amazon Web Services(AWS)、Microsoft Azure、およびGoogle Cloud Platform(GCP)上のSnowflakeアカウント用に、Snowflakeサービスへのプライベート接続を使用した SSO をサポートしています。
現在、任意のSnowflakeアカウントに対し、 SSO は一度に1つのアカウント URL のみで機能します。パブリックアカウント URL か、 AWS、Microsoft Azure、またはGoogle Cloud Platformのプライベート接続サービスに関連付けられた URL のいずれかです。
Snowflakeでは、 組織 での SSO の使用をサポートしており、 SAML2 セキュリティ統合で対応する URL を使用できます。詳細については、 フェデレーション認証を使用するためのSnowflakeの構成 をご参照ください。
Snowflakeへのプライベート接続でSSOを使用するには、SSOを構成する 前 にプライベート接続を構成します。
SnowflakeアカウントがAWSまたはAzureにある場合は、 AWS PrivateLink とSnowflake および Azure Private LinkとSnowflake にリストされているセルフサービスの手順に従ってください。
Snowflakeアカウントが GCP にある場合は、 Snowflakeサポート に連絡し、 Google Cloud Private Service ConnectとSnowflake で使用するSnowflakeアカウント URL を提供する 必要があります。
使用する正しいURLを決定するには、GCPのSnowflakeアカウントで SYSTEM$GET_PRIVATELINK_CONFIG 関数を呼び出します。
SSO 構成を複製する¶
Snowflakeは、ソースアカウントからターゲットアカウントへの SAML2 セキュリティ統合 の複製とフェールオーバー/フェールバックをサポートします。
詳細については、 複数のアカウントにわたるセキュリティ統合とネットワークポリシーの複製 をご参照ください。