フェデレーション認証と 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 AD FS （Active Directoryフェデレーションサービス）--- オンプレミスソフトウェア（Windows Serverにインストール）
Oktaおよび AD FS が提供するネイティブのSnowflakeサポートに加えて、Snowflakeは 大半の SAML 2.0準拠のベンダーを IdP として使用することをサポートしています。
注釈
IdP としてOktaまたは AD FS 以外を使用するには、 IdP でSnowflakeのカスタムアプリケーションを定義する必要があります。
Okta、 AD FS、または別の SAML 2.0準拠ベンダーをSnowflakeの IdP として構成する方法の詳細については、 Snowflake用のIDプロバイダー（IdP）の構成 をご参照ください。
複数のIDプロバイダーの使用¶
異なるユーザーが異なるIDプロバイダーを使用して認証するようにSnowflakeを構成できます。
すべてのIDプロバイダーを構成 したら、 フェデレーション認証に複数のIDプロバイダーを使用する のガイダンスに従ってください。
注釈
現在、複数のIDプロバイダーの使用をサポートしているのは、Snowflakeドライバーのサブセットのみです。これらのドライバーには、 JDBC、 ODBC、Pythonが含まれます。
サポートされている SSO ワークフロー¶
フェデレーション認証により、次の SSO ワークフローが有効になります。
Snowflakeへのログイン。
Snowflakeからログアウト。
非アクティブによるシステムのタイムアウト。
各ワークフローの動作は、Snowflakeまたは IdP 内でアクションが開始されるかどうかによって決まります。
ログインのワークフロー¶
ユーザーがログインすると、システムの動作は、Snowflakeまたは IdP のどちらからログインが開始されるかによって決まります。
- Snowflakeが開始するログイン：
Snowflakeからログインするには、次の方法があります。
ユーザーはSnowflakeのウェブインターフェイスにアクセスします。
ユーザーは、アカウントに構成された IdP（Okta、AD FS、またはカスタム IdP）を使用してログインすることを選択します。
ユーザーは、 IdP 認証情報（電子メールアドレスやパスワードなど）を使用して IdP で認証します。
認証が成功すると、 IdP は SAML 応答をSnowflakeに送信してセッションを開始し、Snowflakeのウェブインターフェイスを表示します。
注釈
Snowflakeが開始するログインの場合、Snowflakeログインページには認証用の2つのオプション（IdP またはSnowflake）があります。フェデレーション認証を使用するには、ユーザーは IdP オプションを選択し、プロンプトが表示されたら認証情報を入力する必要があります。Snowflakeオプションを選択すると、フェデレーション認証をバイパスし、Snowflakeのネイティブ認証を使用してユーザーをログインします。
- IdP が開始するログイン：
アカウントの IdP からログインするには、次の方法があります。
ユーザーは IdP サイト/アプリケーションにアクセスし、 IdP 認証情報（電子メールアドレスやパスワードなど）を使用して認証します。
IdP で、ユーザーはSnowflakeアプリケーション（Oktaまたは AD FS を使用している場合）、または 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 が標準のログアウトのみをサポートするか、グローバルログアウトもサポートするかによって異なります。
AD FS は標準ログアウトとグローバルログアウトの両方をサポートします。グローバルログアウトが有効になっている場合、 AD FS IdP ログインページには、ユーザーがアクセスしたすべてのサイトからサインアウトするためのオプションがあります。このオプションを選択して Sign Out をクリックすると、ユーザーは AD FS およびすべてのSnowflakeセッションからログアウトします。Snowflakeに再度アクセスするには、 AD FS を使用して再認証する必要があります。
Oktaは標準ログアウトのみをサポートします。ユーザーがOktaからログアウトしても、アクティブなSnowflakeセッションから自動的にログアウトされることはなく、作業を続行できます。ただし、新しいSnowflakeセッションを開始するには、Oktaを介して再度認証する必要があります。
すべてのカスタムプロバイダーは標準ログアウトをサポートしています。グローバルログアウトのサポートはプロバイダーによって異なります。
注釈
ウェブベースの IdP の場合（例：Okta）、ブラウザーのタブ/ウィンドウを閉じても IdP セッションが終了するとは限りません。ユーザーの IdP セッションがまだアクティブな場合、 IdP セッションがタイムアウトするまでSnowflakeにアクセスできます。
タイムアウトのワークフロー¶
ユーザーのセッションがタイムアウトすると、タイムアウトするのはSnowflakeセッションか IdP セッションかによって動作が決定されます。
- Snowflakeのタイムアウト：
ユーザーが SSO を使用してSnowflakeにログインし、非アクティブのためにSnowflakeのセッションが期限切れになると、Snowflakeのウェブインターフェイスが無効になり、 IdP 認証のプロンプトが表示されます。
期限切れのSnowflakeセッションを引き続き使用するには、ユーザーは IdP を介して再度認証する必要があります。
ユーザーは 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アカウントは一度に1つのアカウント URL で SSO をサポートします。パブリックアカウント URL、または AWS、Microsoft Azure、Google Cloud Platform上のプライベート接続サービスに関連付けられた URL を指定します。
識別子優先のログインフロー を有効にした場合は、2つの SAML2 セキュリティ統合を構成できます。1つはパブリック アカウント URL を使用した統合で、もう1つは 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 セキュリティ統合 の複製とフェールオーバー/フェールバックをサポートします。
詳細については、 複数のアカウントにわたるセキュリティ統合とネットワークポリシーの複製 をご参照ください。