Looker のドキュメントを表示していることに注意してください。Looker Studio のドキュメントについては、https://support.google.com/looker-studio をご覧ください。

管理者設定 - SAML 認証

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

SAML と ID プロバイダ

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

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

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 認証設定

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 Entity/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 のユーザー属性の値を自動的に入力することもできます。たとえば、データベースにユーザー固有の接続を行うように SAML を構成した場合、SAML 属性を Looker ユーザー属性と組み合わせて、Looker のデータベース接続をユーザー固有にすることができます。

SAML 属性を対応する Looker ユーザー属性とペアリングするには:

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

グループとロール

Looker のオプションでは、外部で管理されている SAML グループをミラーリングするグループを作成し、ミラーリングした SAML グループに基づいて Looker のロールをユーザーに割り当てることができます。SAML グループのメンバーシップを変更すると、その変更が自動的に 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 内で 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] が [メンバーシップ値を持つ個別属性としてのグループ] に設定されている場合、このフィールドが表示されます。ユーザーがグループのメンバーであることを示す値を入力します。

優先グループ名 / ロール / SAML グループ ID: この一連のフィールドにより、Looker で対応する SAML グループに割り当てられたカスタムグループ名と 1 つ以上のロールを割り当てることができます。

[SAML グループ ID] フィールドに SAML グループ ID を入力します。Okta ユーザーの場合は、Okta のグループ名を SAML グループ ID として入力します。SAML グループに含まれる SAML ユーザーは、Looker 内のミラーリング対象のグループに追加されます。
ミラーリングされたグループのカスタム名を [カスタム名] フィールドに入力します。これは、Looker の [管理] セクションの [グループ] ページに表示される名前です。
[カスタム名] フィールドの右側にあるフィールドで、グループ内の各ユーザーに割り当てる 1 つ以上の Looker ロールを選択します。
追加のミラーリング対象のグループを構成するフィールドを追加するには、+ をクリックします。複数のグループを構成していて、グループの構成を削除するには、そのグループのフィールドセットの横にある X をクリックします。

以前にこの画面で構成したミラーリング対象のグループを編集すると、グループの構成は変更されますが、グループ自体はそのまま残ります。たとえば、グループのカスタム名を変更すると、Looker の [グループ] ページでのグループの表示方法は変わりますが、割り当てられたロールやグループメンバーは変更されません。[SAML グループ ID] を変更してもグループ名とロールは維持されますが、グループのメンバーは、新しい SAML グループ UD を持つ外部 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 で直接構成されているかのように Looker のロールを SAML ユーザーに直接割り当てることができます。

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

このオプションをオフにすると、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 グループのミラーリングは、引き続きコンテンツ管理とロール作成で使用できます。ただし、SAML グループのミラーリングにユーザーを追加または削除することはできません。

移行オプション

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

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

このオプションをオンにすると、SAML 認証の設定中に SAML 構成に問題が発生した場合や、SAML ディレクトリにアカウントを持っていないユーザーをサポートする必要がある場合に、代替手段として使用できます。

SAML ユーザーを Looker アカウントに統合する方法を指定する

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

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

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

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

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

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

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

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

統合時に、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 は AUTH-MECHANISM-COOKIE 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 レスポンスの上限を超えている

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

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

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

export MAX_SAML_RESPONSE_BYTESIZE=500000

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