Looker 26.14 のドキュメントを表示しています。このリンクをクリックすると、最新のドキュメントが表示されます。

Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

管理者設定 - SAML 認証

[管理者] メニューの [認証] セクションにある [SAML] ページで、Security Assertion Markup Language（SAML）を使用してユーザーを認証するように Looker を構成できます。このページでは、そのプロセスについて説明し、SAML グループを Looker のロールと権限にリンクする手順を紹介します。

要件

Looker の [管理者] メニューの [認証] セクションに [SAML] ページが表示されるのは、次の条件が満たされている場合のみです。

管理者ロールがある。
Looker（オリジナル）インスタンスで SAML を使用できるように設定されている。SAML を有効にするには、アカウントエグゼクティブにお問い合わせください。このページは、Looker（Google Cloud コア）インスタンスでデフォルトで有効になっています。

これらの条件を満たしているにもかかわらず [SAML] ページが表示されない場合は、インスタンスで SAML を有効にするためにサポートリクエストを開いてください。

SAML と ID プロバイダ

企業は、Okta や OneLogin などのさまざまな ID プロバイダ（IdP）を使用して SAML との連携を行っています。次の設定手順と UI で使用されている用語は、IdP で使用されている用語と直接一致しない場合があります。設定の注意点については、社内の SAML または認証チームか、Looker サポートまでお問い合わせください。

Looker では、SAML リクエストとアサーションが圧縮されることを前提としています。IdP がこのように構成されていることを確認します。Looker から IdP へのリクエストが署名されていません。

Looker は IdP を起点とするログインをサポートしています。

設定プロセスの一部は、IdP のウェブサイトで完了する必要があります。

Okta は Looker アプリを提供します。これは Looker と Okta を同時に構成する場合に推奨される方法です。

ID プロバイダに Looker を設定する

SAML IdP は、SAML アサーションを POST する宛先の Looker インスタンス URL を知っている必要があります。IdP では、名前には「ポストバック URL」、「受取人」、「宛先」などがあります。

指定する情報は、通常ブラウザを使用して Looker インスタンスにアクセスし、その後に /samlcallback が続く URL です。例: none https://instance_name.looker.com/samlcallback

または

https://looker.mycompany.com/samlcallback

一部の IdP では、インスタンス URL の後に :9999 を追加する必要があります。次に例を示します。

https://instance_name.looker.com:9999/samlcallback

知っておくべきこと

次の点にご注意ください。

Looker には SAML 2.0 が必要
SAML を介して Looker にログインしている間は、代替アカウントログイン設定の場合を除き、SAML 認証を無効にしないでください。そうしないと、アプリからロックアウトされる可能性があります。
Looker では、現在のメールアドレスとパスワードの設定、Google 認証、LDAP、OIDC のいずれかから取得したメールアドレスを使用して、既存のアカウントを SAML に移行できます。既存のアカウントの移行方法は、設定プロセスで構成できます。

ご利用にあたって

Looker インスタンスの SAML 認証を構成するには、[管理者] パネルの [認証] セクションで [SAML] を選択します。[SAML 認証] ページで、[SAML を構成] を選択して、次の構成オプションを表示します。

SAML 認証の設定

Looker では、IdP を認証するために IdP URL、IdP 発行元、IdP 証明書 が必要です。

IdP 側で Looker を構成するプロセス中に、IdP により IdP メタデータ XML ドキュメントが提供されます。このファイルには、SAML 認証設定 セクションでリクエストされたすべての情報が含まれています。このファイルがあれば、[IdP メタデータ] フィールドでアップロードできます。このセクションに、必須項目が入力されます。あるいは、IdP 側の構成中に取得した出力から必須フィールドを入力することもできます。XML ファイルをアップロードする場合は、各項目に入力する必要はありません。

IdP メタデータ: IdP 情報を含む XML ドキュメントの公開 URL を貼り付けるか、ドキュメントのテキスト全体をここに貼り付けます。Looker が対象のファイルを解析し、必要なフィールドに入力します。

IdP メタデータ XML ドキュメントをアップロードまたは貼り付けなかった場合は、代わりに IdP 認証情報を [IdP の URL]、[IdP 発行元]、[IdP 証明書] に入力します。

IdP URL: Looker がユーザーを認証するためのアクセスに使用する URL。これは Okta のリダイレクト URL と呼ばれます。
IdP 発行元: IdP の一意の識別子。これは Okta では「外部キー」と呼ばれます。
IdP 証明書: Looker が IdP レスポンスの署名を検証するための公開鍵。

これら 3 つのフィールドを組み合わせると、Looker は署名済みの SAML アサーションのセットが、信頼できる IdP から送られていることを確認できます。

SP エンティティ/IdP オーディエンス: このフィールドは Looker では必須ではありませんが、多くの IdP では必須です。このフィールドに値を入力すると、その値が認証リクエストで Looker の Entity ID として IdP に送信されます。この場合、Looker はこの値を Audience として持つ認証レスポンスのみを受け入れます。IdP が Audience 値を必要とする場合は、その文字列をここに入力します。

クロックドリフトの許可: 許可されるクロックドリフトの秒数（IdP と Looker のタイムスタンプ間の差）。通常、この値はデフォルトの 0 ですが、一部の IdP では、ログインを成功させるために追加の余裕が必要になる場合があります。

ユーザー属性の設定

次のフィールドで、各フィールドに対応する情報を含む、IdP の SAML 構成の属性名を指定します。SAML 属性名を入力すると、ログイン時にこれらのフィールドをマッピングして情報を抽出する方法が Looker に指示されます。Looker は、このような情報がどのように構成されるかは特に問いません。Looker への入力方法が、IdP で属性が定義される方法と一致することが重要です。Looker は、こうした入力の作成方法についてデフォルトで提案します。

標準の属性

次の標準属性を指定する必要があります。

Email Attr: IdP がユーザーのメールアドレスに使用する属性名。
FName Attr: IdP がユーザーの名に使用する属性名。
LName Attr: IdP がユーザーの姓に使用する属性名。

SAML 属性と Looker ユーザー属性のペアリング

必要に応じて、SAML 属性のデータを使用して、ユーザーがログインするときに Looker のユーザー属性に値を自動的に入力できます。たとえば、データベースにユーザー固有の接続を行うように LDAP を構成した場合、LDAP ユーザー属性を Looker ユーザー属性と組み合わせて、Looker のデータベース接続をユーザー固有にすることができます。

SAML 属性と対応する Looker ユーザー属性をペアリングする手順は次のとおりです。

[SAML 属性] フィールドに SAML 属性の名前を入力し、[Looker ユーザー属性] フィールドにペア設定する Looker ユーザー属性の名前を入力します。
ユーザーのログインを許可するために SAML 属性値を要求する場合は、[必須] をオンにします。
[+] をクリックし、属性のペアを追加するためにこれらの手順を繰り返します。

SAML ユーザー属性と対応する Looker ユーザー属性をペア設定する、または既存のペア設定を管理する手順は次のとおりです。

[ユーザー属性の設定] セクションで、[ペア設定を管理] ボタンをクリックして、[ペア設定を管理] サイドパネルを開きます。
[クレーム] フィールドに、ペア設定する SAML 属性の名前を入力します。各申し立て名は 1 回のみ入力できます。クレームを複数の Looker 属性に関連付ける場合は、[Looker ユーザー属性] フィールドに複数の属性を入力できます。
[Looker ユーザー属性] フィールドに、インスタンスの Looker ユーザー属性のプルダウンリストが表示されます。SAML 属性とペア設定する Looker ユーザー属性の名前を選択します。1 つのクレームに複数の Looker ユーザー属性を選択できますが、少なくとも 1 つの Looker ユーザー属性を選択する必要があります。
ユーザーのサインインを許可するために SAML 属性値を要求する場合は、[必須] チェックボックスをオンにします。
[ペア設定を追加] ボタンをクリックして、リストに別のペア設定行を追加します。この手順を繰り返して、属性ペアを追加します。
ペア設定の各行の右側に、 [ペア設定を削除] アイコンが表示されます。このアイコンをクリックすると、インスタンスから属性ペアリングが削除されます。
[ 閉じる] アイコンをクリックして、[ペア設定の管理] サイドパネルを閉じます。
SAML 構成をテストします。
SAML 設定を確認し、SAML 認証 ページの下部にある SAML 設定を確認しました チェックボックスを選択します。
[Enable SAML] または [Update SAML Settings] ボタンをクリックして、SAML ユーザー属性のペア設定を保存します。

[Manage Pairings] サイドパネルには、次のツールも含まれています。

[フィルタリスト] フィルタメニューと検索バー。これらのツールを使用して、インスタンスにすでに追加されているペア設定を検索します。
[表示] のページネーションプルダウンメニュー。このメニューを使用して、各ページに 10、25、50、100 のペアリングを表示します。

グループとロール

Looker では、外部で管理されている SAML グループを反映するグループを作成し、それらのユーザーに、反映された SAML グループに基づく Looker ロールを割り当てることができます。SAML グループのメンバーシップを変更すると、その変更は、その Looker グループのユーザーが次に Looker にログインするときに適用されます。

SAML グループのミラーリングを使用すると、外部で定義された SAML ディレクトリを使用して Looker のグループとユーザーを管理できます。これにより、Looker などの複数の Software as a Service（SaaS）ツールのグループメンバーシップを 1 か所で管理できます。

[ミラー SAML グループ] をオンにすると、Looker では、システムに導入された SAML グループごとに 1 つの Looker グループが作成されます。これらの Looker グループは、Looker の [管理] セクションの [グループ] ページで確認できます。グループは、グループメンバーへのロールの割り当て、コンテンツアクセス制御の設定、ユーザー属性の割り当てに使用できます。

デフォルトのグループとロール

デフォルトでは、[ミラー SAML グループ] スイッチは無効になっています。この場合は、新しい SAML ユーザーのデフォルトグループを設定できます。[新しいユーザーグループ] と [新しいユーザーロール] のフィールドに、新しい Looker ユーザーが Looker に初めてログインするときに割り当てる Looker グループまたはロールの名前を入力します。

これらのグループとロールは、新しいユーザーの最初のログイン時に適用されます。このグループとロールは既存のユーザーには適用されません。ユーザーの最初のログイン後にユーザーから削除された場合は、再適用されません。

後で SAML ミラーグループを有効にすると、次回ログイン時にそれらのデフォルトが削除され、[ミラー SAML グループ] セクションに割り当てられているロールに置き換えられます。これらのデフォルトのオプションは使用できなくなり、割り当てられなくなります。また、ミラーリングされたグループ構成に完全に置き換えられます。

SAML グループのミラーリングの有効化

Looker（Google Cloud コア）インスタンスを使用している場合は、プライマリ認証方法でのみグループミラーリングを有効にし、バックアップ OAuth 認証ではグループミラーリングを有効にしないことをおすすめします。プライマリ認証方法とセカンダリ認証方法の両方でグループミラーリングを有効にすると、次の動作が発生します。

ユーザーが ID を統合している場合、グループミラーリングでは、ログインに使用された実際の認証方法に関係なく、第 1 の認証方法が照合されます。
ユーザーに統合された ID がない場合、グループミラーリングはログインに使用された認証方法と一致します。

ミラーリングされたグループを有効にする手順

Looker 内で SAML グループをミラーリングする場合は、[ミラー SAML グループ] スイッチをオンにする。Looker に次の設定が表示されます。

グループファインダー戦略: IdP がグループの割り当てに使用するシステムを選択します。これは IdP によって異なります。

次の SAML アサーション（none <saml2:Attribute Name='Groups'> <saml2:AttributeValue >Everyone</saml2:AttributeValue> <saml2:AttributeValue >Admins</saml2:AttributeValue> </saml2:Attribute>）の例のように、ほぼすべての IdP が単一の属性値を使用してグループを割り当てます。この場合、単一の属性値としてグループを選択します。
一部の IdP では、グループごとに個別の属性を使用し、ユーザーがグループのメンバーかどうかを判断するために 2 番目の属性を必要とします。以下に、このシステム（none <saml2:Attribute Name='group_everyone'> <saml2:AttributeValue >yes</saml2:AttributeValue> </saml2:Attribute> <saml2:Attribute Name='group_admins'> <saml2:AttributeValue >no</saml2:AttributeValue> </saml2:Attribute>）を示す SAML アサーションのサンプルを示します。この場合、メンバーシップ値を持つ個別の属性としてグループを選択します。

グループ属性: Looker では、[Group Finder Strategy（グループ検索戦略）] が [単一属性の値としてのグループ] に設定されている場合、このフィールドが表示されます。IdP で使用されるグループ属性の名前を入力します。

グループメンバー値: Looker では、[Group Finder Strategy] が [メンバーシップ値を持つ個別属性としてのグループ] に設定されている場合、このフィールドが表示されます。ユーザーがグループのメンバーであることを示す値を入力します。

[グループを管理] ボタン: このボタンをクリックすると、[グループを管理] サイドパネルが開き、カスタムグループや、Looker で対応するグループに割り当てられているロールを追加、削除、編集できます。[グループを管理] サイドパネルには、次のフィールドが表示されます。

[適用するグループ名] フィールド。このフィールドに、ミラーリングするグループのカスタム名を入力します。これは、Looker の [管理] セクションの [グループ] ページに表示される名前です。
[SAML グループ名] フィールド。このフィールドに SAML グループを入力します。Okta ユーザーの場合は、Okta グループ名を SAML グループ ID として入力します。SAML グループに含まれる SAML ユーザーは、Looker 内のミラーリング対象のグループに追加されます。
[ロール] フィールド。このフィールドで、グループ内の各ユーザーに割り当てる 1 つ以上の Looker ロールを選択します。
マッピングを削除アイコン。このアイコンをクリックすると、Looker インスタンスからミラーリングされたグループが削除されます。グループを削除すると、そのグループは Looker にミラーリングされなくなり、そのメンバーには、グループを介してメンバーに割り当てられた Looker のロールがなくなります。

[グループを管理] サイドパネルには、次のツールも含まれています。

[フィルタリスト] フィルタメニューと検索バー。これらのツールを使用して、インスタンスにすでに追加されているグループを検索します。
[マッピングを追加] ボタン。このボタンをクリックして、インスタンスにカスタムグループを追加します。

ミラーリングされたグループの編集

以前にこの画面で構成したミラーリング対象のグループを編集すると、グループの構成は変更されますが、グループ自体はそのまま残ります。たとえば、グループの Looker グループ名を変更すると、Looker の [グループ] ページでのグループの表示方法は変わりますが、割り当てられたロールやグループメンバーは変更されません。SAML グループ名を変更してもグループ名とロールは維持されますが、グループのメンバーは、新しい SAML グループ名を持つ外部 SAML グループのメンバーであるユーザーに基づいて再割り当てされます。

ミラーリングされたグループに対して行われた編集は、そのグループのユーザーが次に Looker にログインするときに適用されます。

高度なロール管理

[SAML グループのミラーリング] スイッチを有効にしている場合、Looker によってこれらの設定が表示されます。このセクションのオプションは、Looker グループと SAML からミラーリングされたユーザーの構成時に Looker 管理者がどの程度の柔軟性があるかを決定します。

たとえば、Looker のグループとユーザーの構成を SAML の構成と厳密に一致させる場合は、これらのオプションをオンにします。最初の 3 つのオプションがすべて有効になっている場合、Looker 管理者はミラーリングされたグループメンバーを変更できず、SAML のミラーリングされたグループを介したユーザーのみにロールを割り当てることができます。

Looker 内でグループをより柔軟にカスタマイズする場合は、これらのオプションをオフにします。Looker グループは引き続き SAML 構成をミラーリングしますが、Looker 固有のグループに SAML ユーザーを追加することや、SAML ユーザーに Looker のロールを直接割り当てるなど、Looker 内で追加のグループやユーザー管理機能を使用することができます。

新しい Looker インスタンス、またはミラーリングされたグループをまだ構成していないインスタンスの場合、これらのオプションはデフォルトで無効になっています。

ミラーリング対象のグループが設定されている既存の Looker インスタンスの場合、これらのオプションはデフォルトでオンになっています。

[高度なロール管理] には、次のオプションがあります。

個々の SAML ユーザーが直接ロールを受け取れないようにする: このオプションをオンにすると、Looker 管理者は Looker ロールを SAML ユーザーに直接割り当てることができなくなります。SAML ユーザーにロールを割り当てることができるのは、グループメンバーのみです。SAML ユーザーがビルトイン（ミラーリングされていない）Looker グループでメンバーシップを許可されている場合でも、ミラーリング対象の SAML グループとビルトイン Looker グループの両方からロールを継承できます。以前にロールが直接割り当てられた SAML ユーザーの場合、次回ログインしたときにそれらのロールが削除されます。

このオプションをオフにすると、Looker 管理者は、Looker で直接構成されたユーザーであるかのように、SAML ユーザーに Looker のロールを直接割り当てることができます。

SAML 以外のグループでダイレクトメンバーシップを禁止する: このオプションをオンにすると、Looker 管理者がビルトイン Looker グループに SAML ユーザーを直接追加できなくなります。ミラーリング対象の SAML グループをビルトイン Looker グループのメンバーにすることが許可された場合、SAML ユーザーは任意の親 Looker グループのメンバーを保持できます。以前に組み込みの Looker グループに割り当てられた LDAP ユーザーは、次回のログイン時にそれらのグループから削除されます。

このオプションをオフにすると、Looker 管理者はビルトイン Looker グループに直接 SAML ユーザーを追加できます。

SAML 以外のグループからのロールの継承を防止: このオプションをオンにすると、ミラーリング対象の SAML グループのメンバーがビルトイン Looker グループからロールを継承できなくなります。以前に親 Looker グループからロールを継承していた SAML ユーザーは、次回のサインイン時にそのロールを失います。

このオプションをオフにした場合、ミラーリングされた SAML グループ、またはビルトイン Looker グループのメンバーとして追加される SAML ユーザーは、親 Looker グループに割り当てられたロールを継承します。

認証にはロールが必要: このオプションがオンの場合、SAML ユーザーにはロールを割り当てる必要があります。ロールが割り当てられていない SAML ユーザーは Looker にログインできません。

このオプションがオフの場合、ロールが割り当てられていない場合でも、SAML ユーザーは Looker に対して認証を行うことができます。ロールが割り当てられていないユーザーは、Looker でデータを表示したり操作したりすることはできませんが、Looker にログインすることはできます。

SAML グループのミラーリングの無効化

Looker 内での SAML グループのミラーリングを停止するには、[ミラー SAML グループ] スイッチをオフにします。スイッチをオフにすると、次のような動作になります。

ユーザーがいない SAML グループのミラーリングはすぐに削除されます。
ユーザーを含むミラーリング対象の SAML グループは、孤立したグループとしてマークされます。このグループのユーザーが 31 日以内にログインしなかった場合、グループは削除されます。孤立した SAML グループに対してユーザーの追加や削除を行うことはできなくなります。

移行オプション

管理者と指定ユーザーの代替ログイン

SAML Auth が有効になっている場合、通常のユーザーに対して Looker のメール / パスワードのログインは常に無効になります。このオプションを使用すると、管理者と login_special_email 権限を持つ指定ユーザーに対する /login/email でメールベースのログインが可能になります。

このオプションをオンにすると、SAML 認証の設定中に SAML 構成に問題が発生した場合や、SAML ディレクトリにアカウントを持っていないユーザーをサポートする必要がある場合に、代替手段として使用できます。/login/email エンドポイントは、完全に無効にしたり非表示にしたりすることはできません。これは、プライマリ SAML 構成が失敗した場合や誤って構成された場合に、管理者がアクセス権を回復できるようにするための重要なフォールバックメカニズムとして機能するためです。管理者が IP 許可リストの設定時に誤ってロックアウトされた場合は、 Google Cloud サポートに復元を依頼してください。

SAML ユーザーの以前のメール認証情報を削除する

SAML 認証が有効になっている場合、Looker UI の通常のユーザーに対して標準の Looker メールとパスワードによるログインは無効になりますが、既存のメール認証情報はユーザーアカウントに関連付けられたままになります。ユーザーアカウントからメール認証情報を完全に削除するには（セキュリティポリシーに準拠するため、または不正なメールログイン試行によってトリガーされる自動通知メールを防ぐためなど）、管理者は Looker API を使用する必要があります。

個々のユーザーのメール認証情報を削除するには、Looker API の DELETE /users/{user_id}/credentials_email エンドポイントを使用します。

メール認証情報を一括で削除するには、Looker API スクリプトまたは一括ユーザー管理ツール（オープンソースの Looker Admin Power Pack など）を使用します。

SAML ユーザーと Looker アカウントのマージに使用する方法を指定する

[Merge Users Using] フィールドに、既存のユーザーアカウントへの最初の SAML ログインの統合方法を指定します。次のシステムのユーザーを統合できます。

Looker のメール / パスワード（Looker（Google Cloud コア）は対象外）
Google
LDAP（Looker（Google Cloud コア）は対象外）
OIDC

複数のシステムを設定している場合は、このフィールドで統合するシステムを複数指定できます。Looker は、リストされているシステムから、指定された順序でユーザーを検索します。たとえば、Looker のメールアドレスとパスワードを使用してユーザーを作成し、LDAP を有効にして、SAML を使用するとします。Looker では、最初にメールとパスワード、次に LDAP で統合されます。

ユーザーが SAML 経由で初めてログインするときに、このオプションは一致するメールアドレスを持つアカウントを見つけることによって、ユーザーを既存のアカウントに接続します。ユーザーに既存のアカウントがない場合は、新規ユーザーアカウントが作成されます。

IdP ドメインの変更の処理

ID プロバイダ（IdP）のドメインが変更された場合、ユーザーが新しいドメインで初めてログインに成功したときに、saml_user_id は新しい値で自動的に上書きされます。Looker 管理者は、Looker でこのシステム管理属性を手動で変更または再構成する必要はありません。

スムーズに移行するには、次の手順に沿って操作します。

Looker ユーザーの [メール] 属性を新しいドメインのメールアドレスに更新します。
[ユーザーの統合に使用する] オプションが、メールによる統合を有効にするように構成されていることを確認します。

Looker（Google Cloud コア）使用時のユーザーのマージ

Looker（Google Cloud コア）と SAML を使用する場合、前のセクションで説明したようにマージが行われます。ただし、次のいずれかの条件を満たしている場合にのみ可能です。

条件 1: ユーザーは SAML プロトコルを介して、Google ID を使用して Looker（Google Cloud コア）に対する認証を行います。
条件 2 マージオプションを選択する前に、次の 2 つの手順を完了しておく必要があります。
- Cloud Identity を使用した Google Cloud 内の連携ユーザーの ID
- 連携ユーザーを使用してバックアップの認証方法として OAuth 認証を設定します。

インスタンスがこの 2 つの条件のいずれかを満たしていない場合、[Merge Users Using] オプションは使用できません。

マージ時に、Looker（Google Cloud コア）はまったく同じメールアドレスを共有するユーザーレコードを検索します。

ユーザー認証をテストする

[テスト] ボタンをクリックして設定をテストします。テストではサーバーにリダイレクトされ、ブラウザタブが開きます。このタブには次の情報が表示されます。

Looker がサーバーと通信して検証できたかどうか。
Looker がサーバーから取得する名前。サーバーが正しい結果を返していることを確認する必要があります。
情報がどのように検出されたかを示すトレース。情報が間違っている場合は、トレースを使用してトラブルシューティングを行ってください。追加情報が必要な場合は、未加工の XML サーバーファイルを読むことができます。

ヒント:

このテストは、SAML が部分的に構成されている場合でも、いつでも実行できます。テストを実行すると、構成中に構成が必要なパラメータを確認できます。
テストでは、[SAML 認証] ページで入力した設定を使用します（これらの設定が保存されていない場合でも）。テストはそのページのどの設定にも影響せず、設定は変更されません。
テスト中に、Looker は SAML RelayState パラメータを使用して情報を IdP に渡します。IdP は、この RelayState 値を変更せずに Looker に返す必要があります。

設定を保存して適用

情報が入力され、すべてのテストに合格したら、[上記の構成を確認しました。グローバルに適用したいと考えています] を選択し、[設定を更新] をクリックして保存します。

ユーザーログイン動作

ユーザーが SAML を使用して Looker インスタンスにログインしようとすると、Looker で [サインイン] ページが表示されます。ユーザーは [認証] ボタンをクリックして、SAML を介して認証を開始する必要があります。

ユーザーにアクティブな Looker セッションがない場合、これがデフォルトの動作です。

IdP がユーザーを認証した後、Looker インスタンスに直接サインインし、ログイン ページをバイパスさせたい場合は、ログイン動作のログインページをバイパスをオンにします。

Looker（オリジナル）を使用している場合は、ログインページのバイパス機能を Looker で有効にする必要があります。この機能のライセンスを更新するには、セールススペシャリストにお問い合わせ Google Cloud いただくか、サポートリクエストを開いてください。Looker（Google Cloud コア）を使用している場合、SAML をプライマリ認証方法として使用する場合は、[ログインページをバイパス] オプションは自動的に使用可能で、フォルトでは無効になっています。

[ログインページのバイパス] が有効になっている場合、ユーザーのログインシーケンスは次のようになります。

ユーザーが Looker URL（例: instance_name.looker.com）に接続しようとします。
Looker は、ユーザーがすでにアクティブなセッションを有効にしているかどうかを判断します。このため、Looker は Cookie AUTH-MECHANISM-COOKIE を使用して、ユーザーが前回のセッションで使用した認証方法を識別します。値は常に saml、ldap、oidc、google、email のいずれかです。
有効なセッションが有効になっている場合は、リクエストされた URL に移動します。
ユーザーがアクティブなセッションを有効にしていない場合、IdP にリダイレクトされます。IdP へのサインインに成功すると、IdP はユーザーを認証します。その後、IdP でユーザーが認証されたことを示す情報とともに、IdP から Looker にユーザーが送信されると、Looker がユーザーを認証します。
IdP での認証に成功すると、Looker は SAML アサーションを検証し、認証を受け入れてユーザー情報を更新し、[ログイン] ページをバイパスして、ユーザーをリクエストされた URL に転送します。
ユーザーが IdP にサインインできない場合、または Looker の使用が IdP から承認されていない場合、IdP によっては、ユーザー IdP のサイトに残るか Looker のログイン ページにリダイレクトされます。

トラブルシューティング

認証に関する問題のトラブルシューティングを行うには、システムアクティビティのユーザーアクティビティダッシュボードを確認します。このダッシュボードには、最近のログイン失敗を表示するタイルがあり、使用された認証方法、返されたエラーメッセージ、試行時間などが表示されます。

SAML JIT プロビジョニングの失敗とマージの競合

埋め込み Looker ビューの SAML ジャストインタイム（JIT）プロビジョニング中に、「そのページは存在しないか、閲覧権限がありません」というエラーが表示されることがあります。[ユーザー] パネルで、これらのユーザーは SAML でログインしたことがなく、認証情報が SAML ではなく メール として表示されることがあります。また、ユーザーとして sudo を実行しようとすると、「アカウントを更新してください」という画面が表示されます。

この問題は、Looker が SAML アサーションと同じメールアドレスを持つ既存のアカウントを特定したときに発生するユーザー統合の競合が原因で発生します。ただし、そのアカウントはメインの認証情報として Email で設定されています。この競合により、Looker はデフォルトでメール認証情報を使用し、SAML で提供された JIT ロールとグループのマッピングを無視します。認証は成功したにもかかわらず、ユーザーには「アクセス権なし」の権限が残ります。

この問題を解決するには、次の回避策を使用します。

Looker の [管理] パネルで、[管理] > [SAML] に移動します。
[新しいユーザーオプション]（Looker のバージョンによっては [移行オプション]）で、[ユーザーの統合に使用] の設定が [Looker のメール/パスワード] に構成されていることを確認します。
影響を受けるユーザーがすでにメールアドレスの認証情報で存在し、重要なコンテンツが関連付けられていない場合は、既存のメールアドレスベースのユーザーアカウントを削除します。この削除により、Looker はユーザーが次にログインしたときに、SAML アサーションのみに基づいて新しいユーザーレコードを作成できます。

SAML レスポンスの上限を超えている

SAML レスポンスのサイズが上限を超えていることを示すエラーが発生する場合は、許可される SAML レスポンスの最大サイズを増やすことができます。

Looker がホストするインスタンスの場合は、サポートリクエストを開いて、SAML レスポンスの最大サイズを更新します。

顧客がホストする Looker インスタンスの場合は、MAX_SAML_RESPONSE_BYTESIZE 環境変数を使用して、SAML レスポンスの最大サイズをバイト数で設定できます。次に例を示します。

export MAX_SAML_RESPONSE_BYTESIZE=500000

SAML レスポンスの最大サイズのデフォルトは 250,000 バイトです。

Okta の SAML グループ属性がない

Okta ID プロバイダアプリケーションは、SAML アサーションに Groups 属性を含めるように構成する必要があります。次の例をご覧ください。

<saml2:Attribute Name='Groups'>

Groups 属性が存在し、形式が正しいことを確認するには、[SAML 認証をテスト] オプションを使用して、Looker で SAML ペイロードを検証します。