SAML 認証

Looker インスタンスが Looker 22.10 以降に作成された場合は、[管理] メニューの [認証] にデフォルトで [SAML] ページが表示されます。

[Admin] メニューの [Authentication] セクションに [SAML] ページが表示されない場合は、Looker のヘルプセンターで [Contact Us] をクリックしてサポート リクエストを開きます。

[Admin] メニューの [Authentication] セクションにある [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 インスタンスにアクセスする URL の後ろに /samlcallback を付けたものです。例: 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 では、現在のメールアドレスとパスワードの設定、LDAP、または Google 認証から取得したメールアドレスを使用して、既存のアカウントを SAML に移行できます。これはセットアップ プロセスで構成できます。

ご利用にあたって

Looker の [Admin] セクションの [SAML Authentication] ページに移動して、次の構成オプションを確認します。構成オプションの変更は、ページの下部にある設定をテストして保存するまで有効になりません。

SAML 認証の設定

Looker では、IdP の認証に IdP URL、IdP 発行元、IdP 証明書が必要です。

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

IdP メタデータ: * IdP 情報が含まれている XML ドキュメントの公開 URL を貼り付けるか、ドキュメント全体をここに貼り付けます。Looker はそのファイルを解析して必須項目に入力します。

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

  • IdP URL: Looker がユーザーを認証するために使用する URL。これは Okta ではリダイレクト URL と呼ばれます。

  • IdP 発行元: IdP の一意の識別子。これは Okta では「外部キー」と呼ばれます。

  • IdP Certificate: Looker が IdP レスポンスの署名を検証できるようにするための公開鍵です。

これら 3 つのフィールドを組み合わせることで、署名済みの SAML アサーションが実際に信頼できる IdP からのものであることを Looker が確認できるようになります。

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

この値は、IdP に送信されるメッセージの「issuer」フィールドとしても使用されます。そのため、IdP から「発行元」なしでメッセージを受信しているというクレームを受けた場合は、この欄に入力する必要があります。IdP で必要な文字列を使用できます。ほとんどの場合、「Looker」を使用できます。このフィールドが存在する場合、IdP は、Looker に返送するメッセージの「オーディエンス」フィールドとして送信する必要があります。

  • 許可されたクロックのずれ: クロックのずれ（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 ユーザー属性とペアリングするには:

  1. [SAML Attribute] に SAML 属性の名前、[Looker User Attributes] に、ペア設定する Looker ユーザー属性の名前を入力します。
  2. ユーザーにログインを許可するために SAML 属性値を要求する場合は、[必須] をオンにします。
  3. [+] をクリックし、上記の手順を繰り返して属性ペアを追加します。

グループとロール

Looker では、外部で管理する SAML グループを反映するグループを作成し、ミラーリングされた SAML グループに基づいて Looker のロールをユーザーに割り当てることができます。SAML グループ メンバーシップに変更を加えると、その変更は自動的に Looker グループの構成に反映されます。

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

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

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

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

これらのグループとロールは、初回ログイン時に新規ユーザーに適用されます。既存のグループとグループ ロールは既存のユーザーには適用されません。また、初回ログイン後にユーザーおよびグループから削除しても、ロールとロールは再適用されません。

SAML ミラー グループを後で有効にすると、次回ログイン時にこうしたデフォルト設定が削除され、Mirror SAML Groups で割り当てられたロールに置き換えられます。これらのデフォルト設定は使用することも割り当てられず、ミラーリング グループの構成に完全に置き換えられます。

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

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

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

  • 次のすべての SAML アサーションに示すように、ほぼすべての IdP が単一の属性値を使用してグループを割り当てます。none <saml2:Attribute Name='Groups'> <saml2:AttributeValue >Everyone</saml2:AttributeValue> <saml2:AttributeValue >Admins</saml2:AttributeValue> </saml2:Attribute> この場合は、[単一属性の値としてグループ] を選択します。

  • 一部の IdP では、グループごとに別個の属性を使用し、ユーザーがグループのメンバーかどうかを判断するために 2 つ目の属性が必要です。以下は、このシステムを示す SAML アサーションの例です。 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> この場合は、[メンバーシップ値を持つ個別の属性としてグループ] を選択します。

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

Group Member Value: [Group Finder Strategy] が [Groups as single attribute with members value] に設定されている場合、このフィールドが表示されます。ユーザーがグループのメンバーであることを示す値を入力してください。

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

  1. [SAML Group ID] 欄に SAML グループ ID を入力します。SAML グループに含まれる SAML ユーザーは、Looker 内のミラーリング対象のグループに追加されます。

  2. [Custom Name] フィールドにミラーリング対象のグループのカスタム名を入力します。Looker の [Admin] セクションの [Groups] ページに表示される名前です。

  3. [Custom Name] フィールドの右側にあるフィールドで、グループ内の各ユーザーに割り当てる Looker ロールを 1 つ以上選択します。

  4. + をクリックして、別のミラーリング グループを構成するフィールドを追加します。複数のグループを設定済みの場合、グループの設定を削除するには、そのグループ セットの横にある X をクリックします。

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

ミラーリング対象のグループに加えられた編集内容は、そのグループのユーザーが Looker に次回ログインしたときに適用されます。

高度なロール管理

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

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

Looker 内のグループを柔軟にカスタマイズしたい場合は、これらのオプションをオフにします。Looker グループでは引き続き SAML の構成をミラーリングしますが、Looker 内の追加のグループやユーザー管理（SAML ユーザーを Looker 固有のグループに追加する、Looker のロールを 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 グループに割り当てられたロールを継承します。

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

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

移行オプション

Looker では、代替ログインを有効にして、このセクションで説明する統合戦略を提供することをおすすめします。

管理者と指定されたユーザーの予備のログイン

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

このオプションを有効にすると、SAML 認証設定中に SAML 構成の問題が発生したときや、SAML ディレクトリにアカウントを持たないユーザーをサポートする必要が生じた場合にフォールバックできます。

Looker API を使用して代替ログインを有効にするには、代替ログイン オプションを有効にするに関するドキュメント ページをご覧ください。

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

[Merge Users Using] フィールドで、初めての SAML ログインを既存のユーザー アカウントに統合する方法を選択します。[Looker Email/Password]、[LDAP]、[Google] を選択できます。

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

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

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

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

  • Looker がサーバーと通信して検証できたかどうか。
  • Looker がサーバーから取得する名前。サーバーが適切な結果を返すか検証する必要があります。
  • 情報が見つかった方法を示すトレース。トレースを使用して、情報が正しくない場合のトラブルシューティングを行います。追加情報が必要な場合は、未加工の XML サーバー ファイルを読み取ることができます。

テスト結果の一部をよく読みます。テストの一部は失敗しても成功する可能性があるからです。

ヒント:

  • SAML が一部設定されている場合でも、いつでもこのテストを実行できます。構成テストは、構成時に、どのパラメータに構成が必要かを確認する際に役立ちます。
  • テストでは、[SAML 認証] ページで入力された設定を使用していなくても、その設定が使用されます。テストは、そのページの設定に影響を与えたり、変更したりしません。
  • テスト中に、Looker は SAML RelayState パラメータを使用して IdP に情報を渡します。IdP は、この RelayState 値を変更せずに Looker に返す必要があります。

[設定を更新] をクリックする前に、すべてのテストに合格していることを確認してください。SAML 構成情報が正しく設定されていない場合、ご自身や他のユーザーが Looker を使用できなくなる可能性があります。

設定を保存して適用

情報の入力が完了し、すべてのテストに合格したら、[上記の構成を確定しました。この設定をグローバルに適用するには] をオンにし、[設定を更新] をクリックして保存します。

ユーザーのログイン動作

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

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

IdP が認証した後にユーザーが Looker インスタンスに直接ログインし、[ログイン] ページをバイパスするには、[ログイン動作] で [ログインページをバイパス] をオンにします。

ログインページのバイパス機能は、Looker によって有効にする必要があります。この機能のライセンスを更新するには、アカウント マネージャーにお問い合わせいただくか、Looker のヘルプセンターで [お問い合わせ] をクリックしてサポート リクエストを開いてください。

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

  1. ユーザーが Looker の URL（instance_name.looker.com など）に接続しようとしている。

  2. Looker によって、ユーザーがすでにアクティブなセッションを有効にしているかどうかを判断します。

  3. ユーザーがアクティブなセッションを有効にしている場合は、リクエストされた URL にリダイレクトされます。

  4. ユーザーが有効なセッションを有効にしていない場合は、IdP にリダイレクトされます。ユーザーが IdP へのログインに成功すると、IdP によってそのユーザーが認証されます。その後、Looker はユーザーが IdP で認証されたことを示す情報を使用してユーザーを Looker に送り返すときに、ユーザーを認証します。

  5. IdP での認証に成功すると、Looker は SAML アサーションを検証し、認証を受け入れてユーザー情報を更新し、ユーザーを [ログイン] ページをバイパスして、要求された URL に転送します。

  6. ユーザーが IdP にログインできない場合、または IdP による Looker の使用が承認されていない場合、ユーザーは IdP に応じて IdP のサイトのままか、Looker の [ログイン] ページにリダイレクトされます。

SAML レスポンスが上限を超えています

認証を行うユーザーが、SAML レスポンスが最大サイズを超えたことを示すエラーが発生する場合は、SAML レスポンスの最大サイズを引き上げます。

Looker ホスト型のインスタンスの場合は、Looker サポートに連絡して SAML レスポンスの最大サイズを更新してください。Looker のヘルプセンターで [お問い合わせ] をクリックしてサポート リクエストを開きます。

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

export MAX_SAML_RESPONSE_BYTESIZE=500000

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