管理者設定 - Google 認証

[管理] メニューの [認証] セクションにある [Google 認証] ページで、Looker 側の Google OAuth を設定できます。

機能の概要

Looker では、Google Workspace で登録したアカウントを持つユーザー向けに、Google OAuth を使用して認証を実行できます。

  • Google Workspace を使用している組織は、Google アカウントを持つ Looker ユーザーを認証できます。
  • ユーザーは自身の Google アカウントで認証することによって Looker にログインします。
  • 新しい Google アカウントには自動的に Looker へのアクセス権が与えられます。別途ユーザーを Looker に招待する必要はありません。新規ユーザーにデフォルト ロールを設定し、機能とデータへのアクセスを制限できる。
  • 組織は、Google グループのミラーリングを構成して、Google グループのメンバーシップに基づいて Looker のロールとグループを自動的に割り当てることができます。
  • 有効にすると、[代替ログイン] オプションを選択しない限り、Google OAuth でのみユーザー認証が行われます（詳しくは、Google 認証が有効な間にメールログインを有効にするの次のセクションをご覧ください）
  • 標準ユーザーのマークの代わりにユーザーの Google アバターがナビゲーション バーに表示されます。
  • Google OAuth を有効にすると、Looker インスタンスは Google に登録されているドメインと既存のユーザー アカウントをマージできますが、メールアドレスがドメインと一致するアカウントに限られます。管理者以外のその他のアカウントではログインできなくなります。
  • 指定されたドメイン内のすべてのユーザーが Looker インスタンスへのアクセス権を取得します。
  • 新しい Google ユーザーの権限は、デフォルトで、指定されたモデルのリストに対する基本アクセス権になります（オプションで、ゼロモデルへのアクセスにすることも可能）。管理者は、アカウントの作成後に権限を更新できます。
  • Google OAuth を使用して認証する新しい Looker アカウントは、Looker インスタンスで OAuth が無効になっている場合でも、パスワード認証に切り替えることはできません。

予備的な要件

Google OAuth を使用するための要件は、以下のとおりです。

Google グループのミラーリングを使用するには、次の追加要件が適用されます。

  • OAuth クライアントを含む Google Cloud プロジェクトで、Cloud Identity API（cloudidentity.googleapis.com）が有効になっている必要があります。
  • セルフホスト型 Looker インスタンスの場合、インスタンス ホストは HTTPS（cloudidentity.googleapis.com:443）経由でアウトバウンド インターネット アクセスできる必要があります。
  • ユーザーには、所属する Google グループに対する VIEW_MEMBERSHIP 権限が必要です。Google グループの設定で、[メンバーを表示できるユーザー] フィールドを [グループ メンバー] に設定します。
  • FIPS 準拠モードの Looker インスタンスでは、Google グループのミラーリングはサポートされていません。

Google OAuth を使用した認証の有効化

Google OAuth を使用した認証を有効にするには、管理者が以降のセクションで説明するように、Google 側と Looker 側の両方で手順を行う必要があります。

Google 側での設定

このセクションでは、Google 側で Google OAuth を有効にする手順について説明します。これらの手順の一般的な説明については、OAuth 2.0 の設定に関する Google サポートページをご覧ください。Google Cloud コンソールのヘルプドキュメントもご覧ください。

  1. Google Cloud コンソールに移動します。

  2. [プロジェクトを選択] プルダウンの下矢印をクリックします。プルダウンに既存のプロジェクトの名前が表示されます。下矢印をクリックすると、新しいプロジェクトを作成するオプションが表示されます。

  3. [プロジェクトを選択] ページで、[新しいプロジェクト] をクリックします。

    Google Cloud コンソールに [新しいプロジェクト] ページが表示されます。

  4. [新しいプロジェクト] ページに情報を入力し、[作成] をクリックします。

    Google Cloud コンソールで新しいプロジェクトの作成が完了すると、 Google Cloud コンソールに戻り、新しいプロジェクトが表示されます。

  5. 省略可: Google グループのミラーリングを使用する場合は、 Google Cloud プロジェクトで Cloud Identity API を有効にします。この API を有効にすると、OAuth 同意画面を構成するときに https://www.googleapis.com/auth/cloud-identity.groups.readonly スコープが表示されます。API を有効にするには、Service Usage 管理者（roles/serviceusage.serviceUsageAdmin）の Identity and Access Management（IAM）ロールが必要です。

    API を有効にする

  6. 左側のメニューで、[API とサービス] > [認証情報] を選択します。

  7. [認証情報] ページで、[認証情報を作成] ボタンをクリックし、プルダウン メニューから [OAuth クライアント ID] を選択します。

    Google Cloud コンソールに [OAuth クライアント ID の作成] ページが表示されます。

  8. Google Cloud コンソールでは、OAuth 同意画面を構成する必要があります。これにより、ユーザーは各自のプライベート データへのアクセス権限を付与する方法を選択でき、組織の利用規約とプライバシー ポリシーへのリンクが表示されます。[同意画面を構成] をクリックします。（以前のプロジェクトで OAuth 同意を構成している場合は、このオプションは表示されません。ステップ 13 に進んでください）。

    Google Cloud コンソールに [OAuth 同意画面] ページが表示されます。

  9. [承認済みドメイン] フィールドに Looker インスタンスのドメインを入力します。たとえば、Looker がインスタンスを https://mycompany.looker.com でホストする場合、ドメインは looker.com です。セルフホスト型の Looker デプロイの場合は、Looker をホストするドメインを入力します。

  10. OAuth 同意画面を設定し、[保存して続行] をクリックします。

  11. [スコープ] ページで、スコープを次のように構成します。

    • Google グループのミラーリングを使用する場合は、[スコープを追加または削除] をクリックします。https://www.googleapis.com/auth/cloud-identity.groups.readonly スコープを見つけて、その横にあるチェックボックスをオンにし、[更新] をクリックします。このスコープが表示されない場合は、Google Cloud プロジェクトで Cloud Identity API が有効になっていることを確認します。
    • Google グループのミラーリングを使用する予定がない場合は、追加のスコープ構成は必要ありません。

    [保存して次へ] をクリックします。

  12. [概要] ページで、[ダッシュボードに戻る] をクリックします。

    Google Cloud コンソールで [OAuth クライアント ID の作成] ページに戻ります。

  13. [アプリケーションの種類] で、[ウェブ アプリケーション] を選択します。

  14. [名前] フィールドに、実際の OAuth クライアント ID の名前を入力します。

  15. [承認済みの JavaScript 生成元] フィールドに、https:// を含む Looker インスタンスの URL を入力します。例:

    • Looker がインスタンスをホストする場合: https://mycompany.looker.com
    • セルフホスト型 Looker インスタンスがある場合: https://looker.mycompany.com
    • Looker インスタンスにポート番号が必要な場合: https://looker.mycompany.com:9999

  16. [承認済みのリダイレクト URI] に、Looker インスタンスの URL と、続けて /oauth2callback を入力します。たとえば、https://mycompany.looker.com/oauth2callback や https://looker.mycompany.com:9999/oauth2callback です。

  17. [作成] をクリックします。

  18. クライアント ID とクライアント シークレットの値をコピーします。これらは Looker を構成する際に必要になります。

Looker 側での設定

Looker 側で Google OAuth を有効にする手順は次のとおりです。

  1. Looker アプリケーションから、管理者としてログインした状態で、[管理] プルダウンをクリックして [管理] メニューを開きます。

  2. [Authentication] グループで [Google] をクリックします。Looker に [Google 認証システム] ページが表示されます。

  3. [Enabled] をクリックすると、Google OAuth 設定の表示と編集を行えます（この操作を行っても、Google 認証が直ちに有効になるわけではありません。後で選択を確定する必要があります）。

  4. Google Auth Settings を入力します。

    • クライアント ID とクライアント シークレット: 上記の Google の設定手順に基づいて、これらの値を Google OAuth クライアント ページからコピーして貼り付けます。
    • ドメイン - Google が管理する組織のドメイン名。指定されたドメイン内の Google ユーザーが Looker インスタンスにログインできます。複数の Google ドメインを管理している場合は、それらをカンマで区切って入力できます。

  5. [移行オプション] を入力します。これにより、Google OAuth へ移行中の Looker インスタンスの動作を制御します。

    • 管理者と指定ユーザーの代替ログイン - 管理者と指定ユーザーは、メールアドレスとパスワードを使用して引き続きログインできます。この設定により、Looker OAuth クライアントをホストしている Google Cloud プロジェクトが削除または無効化された場合（プロジェクトの復元後でも 401 deleted_client エラーが発生する可能性があります）、または Google OAuth が他の理由で失敗した場合に、完全なロックアウトを防ぐための重要なフォールバック方法が有効になります。この設定は強く推奨されており、Google Auth が有効な場合のメールログインを有効にするで詳しく説明しています。
    • Merge Users Using - 指定されたドメイン内のメールアドレスを使用する既存のユーザーを、次回ログイン時に Google OAuth を使用するように変換します（Looker のメール / パスワードなど）。この設定をおすすめします。
    • 新規ユーザーのロール - 管理者以外のユーザーが持つ機能とモデルアクセスを指定します。このリストは後で更新できます。空白のままにした場合は、管理者がアカウントにロールを追加するまで、Google 認証済みの新規ユーザーは Looker プラットフォーム内で機能が制限されます。Google ドメイン内のすべてのユーザーが Looker にログインできるため、アクセスを適切に制限するための新規ユーザー用のデフォルトのロールを指定することを検討します。

  6. [Groups & Roles] を構成して、必要に応じて Google グループを Looker グループにミラーリングし、ロールを自動的に割り当てます。

    管理対象の Google グループがある場合、Looker は Google グループのメンバーシップをミラーリングする Looker グループを作成できます。つまり、Looker でユーザーを直接設定する必要はなく、Google グループのメンバーシップを管理することでユーザー アクセスを管理できます。また、Looker グループを使用して、グループ メンバーへのロールの割り当て、コンテンツ アクセス制御の設定、機能とデータアクセスの制御、ユーザー属性の割り当てを行うこともできます。

    グループ ミラーリングが正しく機能するには、ユーザーが所属する Google グループに対する VIEW_MEMBERSHIP 権限が必要です。これにより、Looker はログイン時にグループ メンバーシップを確認できます。Google グループの設定でこの権限を付与するには、[メンバーを表示できるユーザー] フィールドを [グループ メンバー] に設定します。

    グループ ミラーリングを有効にする手順は次のとおりです。

    1. [Google グループをミラーリングする] をオンにします。
    2. [グループを管理] をクリックして、グループ マッピング構成を開きます。
    3. ミラーリングする Google グループごとに、次の項目を入力します。
      • Looker グループ名: Looker グループの名前を入力します。この名前は、Looker の [グループ] ページに表示されます。
      • Google グループ ID: ミラーリングする Google グループの名前またはメールアドレスを入力します。
      • ロール: グループのメンバーに割り当てる 1 つ以上の Looker ロールを選択します。

    Looker は、構成に追加した Google グループごとに 1 つの Looker グループを作成します。これらのグループは、Looker の [グループ] ページで確認できます。

    Looker は、ユーザーが Looker インスタンスにログインするときに、ミラーリングされた Looker グループ（および関連するロールとアクセス権）を適用します。Google グループのグループ メンバーシップの変更は、各ユーザーの次回のログイン時に更新されます。

Google グループをミラーリング

Google グループのミラーリングを構成したら、ミラーリングされたグループを編集または無効にできます。また、次のセクションで説明するように、高度なロール管理オプションを構成できます。

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

Google グループのメンバーシップを変更すると、その変更はミラーリングされた Looker グループのメンバーシップに自動的に反映され、各ユーザーの次回のログイン時に検証されます。

[Google 認証] ページでグループに割り当てられた [Looker グループ名] または [ロール] を編集すると、[グループ] ページでのミラーリング対象のグループの表示方法や、グループに割り当てられたロールは変更されますが、グループ メンバーは変更されません。

[Google グループ ID] フィールドの名前またはメールアドレスを新しい Google グループ ID に変更すると、ミラーリングされた Looker グループのメンバーが新しい Google グループのメンバーに変更されます。ただし、[Google 認証] ページで定義されたグループ名とロールは維持されます。

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

ミラーリングされたグループの無効化

Looker 内での Google グループのミラーリングを停止するには、[Google 認証] ページの [Google グループのミラーリング] をオフにします。この切り替えを無効にすると、次のようになります。

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

高度なロール管理

[Google グループのミラーリング] が有効になっている場合、[高度なロール管理] セクションには、Looker 管理者が Google からミラーリングされた Looker グループとユーザーをどの程度厳密に構成できるかを決定するオプションが表示されます。

Looker のグループとユーザーの構成を Google グループの構成と厳密に一致させる場合は、[高度なロール管理] オプションをすべて選択します。すべてのオプションを有効にすると、Looker 管理者はミラーリングされたグループ メンバーを直接変更できず、Google グループを介したユーザーにのみロールを割り当てることができます。

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

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

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

  • Google 以外のグループ内で直接メンバーシップを防止する: このオプションをオンにすると、Looker 管理者は、ミラーリングされたグループのメンバーを、[Google 認証] ページでミラーリングされたグループ構成に含まれていないビルトイン Looker グループに直接追加できなくなります。

    このオプションを選択すると、以前に組み込みの Looker グループに割り当てられた Google ユーザーは、次回のログイン時にそれらのグループから削除されます。

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

  • Google 以外のグループからのロールの継承を防止する: このオプションをオンにすると、ミラーリングされたグループのメンバーがビルトイン Looker グループからロールを継承できなくなります。ミラーリングされた Google グループを組み込みの Looker グループのメンバーにできる場合、Google ユーザーは組み込みの Looker グループのメンバーシップを保持できます。ただし、以前に組み込みグループからロールを継承していた Google ユーザーは、次回のログイン時にそのロールを失います。

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

  • Auth にはロールが必要: このオプションがオンの場合、Google ユーザーに Looker ロールが割り当てられている必要があります。このオプションがオンの場合、Looker にログインするには、Google ユーザーに Looker のロールが割り当てられている必要があります。

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

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

  1. [Google 認証をテストする] をクリックして、現在の設定を使用して、新しいウィンドウで現在のブラウザの認証を試みます。この操作では、現在の設定の保存や、Looker インスタンスへの適用は行われません。

    Google にログインしていない場合は、ログインを求められ、Google アカウント情報を使用することへの同意を求められます。このフローでは、Google 側の設定で使用したカスタムの同意画面の設定が使用されます。

    成功すると、[ユーザー情報] セクションには、名前、メールアドレス、ドメインが表示されます。また、アカウントで検出されたミラーリングされた Google グループも表示されます。この [ユーザー情報] セクションがある場合、このユーザーは Looker によって正常に認証されたことを示します。

    失敗すると、エラーの説明が表示されます。一般的な問題としては、次のようなものがあります。

    • クライアント ID またはクライアント シークレットが誤ってコピーされました。これらは完全な形で、注意しながらコピーして貼り付ける必要があります。
    • ユーザーがドメイン外です。[個人情報] セクションが表示されているのに [ユーザー情報] が表示されない場合は、指定したドメインにユーザーがいない可能性があります。これは、そのユーザーが Google に対して正しく認証されているものの、Looker インスタンスへのアクセスを許可するために選択した Google アカウントを使用していないことを示します。
    • Google で Looker インスタンスに対する Looker URL またはリダイレクト URL が正しく設定されていません。
    • Google グループの読み込みに失敗した場合は、 Google Cloud プロジェクトで Cloud Identity API が有効になっていること、https://www.googleapis.com/auth/cloud-identity.groups.readonly スコープが追加されていること、ユーザーに Google グループに対する VIEW_MEMBERSHIP 権限があることを確認します。

  2. 変更を保存して適用するには、[上記の構成を確認しました。グローバルに適用したいと考えています] を選択します。[更新] をクリックします。

API を使用して Google 認証を構成する

管理者は、Looker API の google_config エンドポイントを使用して、Google 認証設定とグループ ロール マッピングをプログラムで読み取り、更新できます。詳細については、Looker API リファレンスをご覧ください。

ヒント

  • 完全な認証サイクルを試す場合は、Google からログアウトして、Looker にログインしようとするときに Google から再度ログインするよう求められることを確認します。

  • Google では、個人のプルダウン（Google Workspace ページの右上にあるメールアドレスの横）の [アカウント] をクリックして、個人のアカウントを管理することができます。

    その管理ページには [セキュリティ] タブがあり、ここに [アカウント権限] セクション含まれています。[アプリとウェブサイト]、[すべて表示] をクリックすると、（ユーザーとして）権限を付与したサービスとアプリを表示および管理できます。

    ログインするために付与した Looker 権限をクリックすると、以前にカスタマイズした同意画面でユーザーに表示される詳細を確認できます。また、[アクセスを取り消す] をクリックすると、次に Looker にログインする際、または承認をテストする際に、同意画面が再度表示されます。このワークフローを使用して、同意画面をカスタマイズし、ユーザーに表示される内容を確認できます。

トラブルシューティング

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

  • ユーザーがログインに失敗した場合は、まず、そのユーザーの Google アカウントに姓と名の両方が設定されていることを確認します。ユーザーが Google アカウントから姓または名のいずれかを削除した場合は、Looker が Google OAuth でユーザーを認証できない可能性があります。

  • ユーザーがログインに失敗し、Looker で User not in the authorized domain などのエラーが表示される場合は、JSON レスポンスの hd フィールドを確認します。hd フィールドにドメインが含まれている場合は、ドメインが Google Workspace アカウントに登録されていることを確認します。hd フィールドが空の場合、管理対象に含まれないユーザー用の移行ツールを使用して、ドメイン内の管理対象アカウントにユーザーのアカウントを移行するようにユーザーを案内します。

  • ユーザーがログインに失敗したがLooker にエラー メッセージが表示されない場合は、ユーザーが Google Workspace アカウント名を編集して、姓または名を削除した可能性があります。この場合、Google Workspace アカウント名が管理コンソールにまだ全て表示されており、ユーザーの編集が反映されていない可能性があります。この問題を回避するために、Google Workspace 管理者は [ユーザーにこの設定のカスタマイズを許可] オプションを無効にすることができます。

  • Google 認証で 401 deleted_client エラーが返された場合、このエラーは、Looker OAuth クライアントをホストしている Google Cloud プロジェクトが削除または無効化されていることを示します。その後 Google Cloud プロジェクトが復元されても、OAuth クライアントは deleted_client エラーで失敗し続け、すべてのユーザーが完全にログインできなくなる可能性があります。Google 認証が有効になっている唯一の認証方法である場合、このロックアウトにより、管理者であってもアクセスできなくなります。

    OAuth クライアントの削除や障害が発生した場合に完全にロックアウトされないようにするには、[管理者の代替ログイン] 設定を有効にする必要があります。この設定により、管理者は Looker インスタンスにアクセスして認証設定を更新するためのフォールバック ログイン方式を確保できます。

Google 認証が有効な間にメールログインを有効にする

新しい Google アカウントは Looker に自動的にアクセスできるようになるため、Google ドメイン内のユーザーを追加する必要はありません。

Google Domains にないメールアドレスを持つユーザーを追加するには、次のようにします。

  1. Google Auth ページで [Alternate login for admins and specified users] オプションを有効にする
  2. login_special_email 権限を追加するために、既存のユーザーロールを作成または変更する
  3. ユーザーパネル（/admin/users/new）から [Add Users] に移動します。
  4. 含めたいメールアドレスと、それらのユーザーに付与するロールを追加します。これには、login_special_email 権限を持つロールを含める必要があります。
  5. これらのユーザーは、https://mycompany.looker.com/login/email（非表示 URL）を使用してログインできるようになりました。

有効に設定された場合に Google Auth を無効にする

Looker インスタンスの Google 認証を有効にした後、無効にする場合は、次の点を考慮してください。

  • Google 認証システムが追加される前に作成され、通常のメール ログインとパスワードをすでに設定したユーザーは引き続き機能します。
  • Google 認証システムが追加された後に作成されたユーザーは、ログインできなくなります。アカウントがまだ存在していても、アカウントにはアクセスできず、実質的に孤立しています。

そのため、このルートは使用しないことをおすすめします。この方法を採用する必要がある場合は、Looker API を使用して孤立したアカウントを修正する方法があります。追加のガイダンスについては、Looker サポートまでお問い合わせください。