[管理者] メニューの [認証] セクションにある [SAML] ページで、Security Assertion Markup Language（SAML）を使用してユーザーを認証するように Looker を構成できます。このページでは、そのプロセスについて説明します。また、SAML グループを Looker のロールと権限にリンクする手順も記載しています。
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 認証の設定
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 のユーザー属性に値を自動的に入力できます。たとえば、データベースにユーザー固有の接続を行うように LDAP を構成した場合、LDAP ユーザー属性を 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 に次の設定が表示されます。
Group Finder 戦略: 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 ユーザーの場合は、SAML グループ ID として Okta グループ名を入力します。SAML グループに含まれる SAML ユーザーは、Looker 内のミラーリング対象のグループに追加されます。
[Custom Name] フィールドに、ミラーリングするグループのカスタム名を入力します。これは、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 で直接構成されたユーザーであるかのように、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 グループのミラーリングは、引き続きコンテンツ管理とロール作成で使用できます。ただし、SAML グループのミラーリングにユーザーを追加または削除することはできません。
移行オプション
管理者と指定ユーザーの代替ログイン
SAML Auth が有効になっている場合、通常のユーザーに対して Looker のメール / パスワードのログインは常に無効になります。このオプションを使用すると、管理者と login_special_email 権限を持つ指定ユーザーに対する /login/email でメールベースのログインが可能になります。
このオプションをオンにすると、SAML 認証の設定中に SAML 構成に問題が発生した場合や、SAML ディレクトリにアカウントを持っていないユーザーをサポートする必要がある場合に、代替手段として使用できます。
SAML ユーザーと Looker アカウントのマージに使用する方法を指定する
[Merge Users Using] フィールドに、既存のユーザー アカウントへの最初の SAML ログインの統合方法を指定します。次のシステムのユーザーを統合できます。
- Looker のメール / パスワード（Looker（Google Cloud コア）は対象外）
- 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 つの条件のいずれかを満たしていない場合、[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 レスポンスの上限を超えている
SAML レスポンスのサイズが上限を超えていることを示すエラーが発生する場合は、許可される SAML レスポンスの最大サイズを増やすことができます。
Looker がホストするインスタンスの場合は、サポート リクエストを開いて、SAML レスポンスの最大サイズを更新します。
顧客がホストする Looker インスタンスの場合は、MAX_SAML_RESPONSE_BYTESIZE 環境変数を使用して、SAML レスポンスの最大サイズをバイト数で設定できます。例:
export MAX_SAML_RESPONSE_BYTESIZE=500000
SAML レスポンスの最大サイズのデフォルトは 250,000 バイトです。