access_grant

用途

access_grant: access_grant_name {
  user_attribute: user_attribute_name
  allowed_values: [ "value_1", "value_2" , ... ]
}

階層 モデルファイル access_grant

デフォルト値 なし 許可 user_attribute サブパラメータを含むユーザー属性の名前と、allowed_values サブパラメータを含むユーザー属性値のリスト

定義

アクセス権付与は、モデルファイルで定義された LookML 構造で、他の LookML 構造（特に Explore、結合、ビュー、フィールド）へのアクセスを制御します。access_grant パラメータはアクセス権限を定義します。

access_grant は、user_attribute サブパラメータでユーザー属性の名前を、allowed_values サブパラメータでユーザー属性の許容値のリストを取得します。指定されたユーザー属性に許可された値のいずれかが割り当てられているユーザーのみが、アクセス権限が必要な構造にアクセスできます。

定義したら、Explore、結合、ビュー、フィールド レベルで required_access_grants パラメータを使用して、これらの構造にアクセスするためにアクセス許可を必要とすることができます。

たとえば、次の LookML は、department ユーザー属性に基づく can_view_financial_data というアクセス権限を作成します。department ユーザー属性に値 "finance" または "executive" が割り当てられているユーザーのみに、can_view_financial_data アクセス権限へのアクセス権が付与されます。

access_grant: can_view_financial_data {
  user_attribute: department
  allowed_values: [ "finance", "executive" ]
}

次に、required_access_grants パラメータを使用して、can_view_financial_data アクセス権限を LookML 構造体に関連付けます。

dimension: financial_data_field
  ...
  required_access_grants: [can_view_financial_data]
}

この例では、can_view_financial_data アクセス権限の適切なユーザー属性値を持つユーザーのみが financial_data_field ディメンションを表示できます。

モデルで複数のアクセス権付与を定義できます。また、required_access_grants パラメータを使用して、複数のアクセス権付与を LookML 構造に割り当てることができます。その場合、LookML 構造にアクセスするには、指定されたすべてのアクセス許可が必要です。

たとえば、次の LookML では、2 つの異なるアクセス権付与を定義しています。

access_grant: can_view_financial_data {
  user_attribute: department
  allowed_values: [ "finance", "executive" ]
}

access_grant: can_view_payroll_data {
  user_attribute: view_payroll
  allowed_values: [ "yes" ]
}

ビューファイルでは、required_access_grants パラメータで両方のアクセス許可を指定します。

view: payroll {
  ...
  required_access_grants: [can_view_financial_data, can_view_payroll_data]
}

この場合、department ユーザー属性に値 "finance" または値 "executive" が割り当てられており、かつ view_payroll ユーザー属性に値 "yes" が割り当てられているユーザーのみがビューにアクセスできます。

例

ユーザーが engineering アクセス権限にアクセスするには、department ユーザー属性に値 "product_management" または値 "engineering" のいずれかが必要となるアクセス権限を定義します。

access_grant: engineering {
  user_attribute: department
  allowed_values: [ "product_management", "engineering" ]
}

数値データまたは日時データを取得するユーザー属性を使用してアクセス権限を定義することもできます。これを行うには、文字列の場合と同様に、許容値を二重引用符で囲む必要があります。たとえば、次のアクセス権付与は、number の データ型を持つ id ユーザー属性を参照しています。id の値が 1、2、3、4、5 のユーザーのみにアクセス権が付与されます。

access_grant: user_id {
  user_attribute: id
  allowed_values: ["1", "2", "3", "4", "5"]
}

次の例では、データ型が Date/Time のユーザー属性 start_date を参照しています。ユーザー属性に値 2020-01-01 を持つユーザーのみにアクセス権が付与されます。

access_grant: start_date {
  user_attribute: start_date
  allowed_values: ["2020-01-01"]
}

注意点

アクセス許可ではユーザー編集可能なユーザー属性は使用できません

アクセス権限では、[ユーザー アクセス] レベルが [編集] に設定されているユーザー属性は受け入れられません。ユーザーは、[ユーザー アクセス] レベルが [編集] に設定されているユーザー属性の値をアカウント ページで表示および編集できます。セキュリティ上の理由から、access_grant で許可されるユーザー属性は、[User Access] レベルが [None] または [View] のもののみです。

allowed_values にリストされている値は、ユーザー属性値と完全に一致している必要があります

access_grant は、文字列フィルタ（詳細設定）、数値フィルタ（詳細設定）、日時フィルタ（詳細設定）のデータ型を持つユーザー属性で機能します。ただし、アクセス権限を付与するには、allowed_values パラメータに記載されている値が、ユーザー属性の値と完全に一致している必要があります。

たとえば、データ型が [数値フィルタ（詳細設定）] の numeric_range というユーザー属性を作成した場合、Looker フィルタ式を使用して、[1, 20] などの数値の範囲を入力できます。この例では、ユーザー属性の Looker フィルタ式は 1 ～ 20 の範囲の数値を返します。ただし、access_grant では完全一致が必要なため、パラメータ allowed_values: ["10"] を使用してもアクセス権は付与されません。アクセス権を付与するには、allowed_values: ["[1, 20]"] を使用する必要があります。

複数の値を持つユーザー属性についても同様です。たとえば、データ型が [数値フィルタ（詳細設定）] のユーザー属性に値 1, 3, 5 が指定されている場合、パラメータ allowed_values: ["1, 3, 5"] を含むアクセス権限にのみ一致します。同様に、パラメータ allowed_values: ["1"] を含むアクセス権限では、ユーザー属性に複数の値を持つユーザーにアクセス権が付与されません。また、allowed_values: ["1", "3", "5"] パラメータを含むアクセス権限も、このユーザーにアクセス権限を付与しません。allowed_values: [] パラメータは複数の値を受け入れることができますが、allowed_values: ["1", "3", "5"] パラメータの 3 つの値のいずれも、ユーザー属性値 1, 3, 5 と完全に一致しないためです。この場合、ユーザー属性の値が 1、3、5 のいずれかのユーザーにはアクセス権が付与されます。これらの値はそれぞれ allowed_values: ["1", "3", "5"] パラメータのオプションのいずれかに一致するためです。

同様に、access_grant では、データ型が 文字列フィルタ（詳細設定） のユーザー属性と完全に一致する必要があります。一般的な Looker フィルタ式とは異なり、パラメータ allowed_values: [ "Ca%" ] を使用しても、ユーザー属性と値 Canada または California が一致することはありません。ユーザー属性値が Ca% と完全に一致する場合にのみ、アクセス権が付与されます。

アクセス権が付与されていないユーザーは、LookML の構造に応じて異なる動作を経験する

アクセス権付与へのアクセス権がないユーザーは、アクセスしようとしている LookML 構造に応じて異なる動作を経験します。これらの構造へのアクセスを制限する方法については、Explore、結合、ビュー、フィールド レベルの required_access_grants ドキュメント ページをご覧ください。

複数のレベルのアクセス権が付与されている場合、それらのアクセス権が合算される

アクセス権付与をネストすると、アクセス権付与は加算的になります。たとえば、ビューの required_access_grants を作成し、ビュー内にフィールドの required_access_grants を作成できます。フィールドを表示するには、フィールドとビューの両方に対するアクセス権が必要です。結合についても同様です。結合内のビューに対して required_access_grants を作成し、これらの 2 つのビューの結合に対して required_access_grants を作成した場合、結合されたビューを表示するには、ユーザーが両方のビューと結合に対するアクセス権限を持っている必要があります。

制限付き構造体を参照する構造体へのアクセス

ユーザーは、アクセス権のない LookML オブジェクトを含む Look やダッシュボードにアクセスできます。このような場合、Look またはダッシュボードは、これらの LookML オブジェクトがモデルから削除されたかのように表示されます。

Explore A に結合 A、ビュー A、フィールド A が含まれているとします。次に、Explore A にアクセス制限を設定します。予想どおり、結合 A、ビュー A、フィールド A はその制限を継承しますが、ユーザーが Explore A を操作している場合に限ります。結合 A、ビュー A、フィールド A が別の Explore B で使用されている場合、必ずしもアクセス制限が適用されるとは限りません。そのため、LookML 要素を再利用する予定がある場合は、可能な限り低いレベルでアクセス制限を適用することをおすすめします。