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은 두 가지 액세스 권한을 정의합니다.

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" 값이 할당된 사용자만 뷰에 액세스할 수 있습니다.

예시

사용자가 department 사용자 속성에 "product_management" 값 또는 "engineering" 값이 있어야 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"]
}

다음 예시에서는 데이터 유형이 날짜/시간인 사용자 속성 start_date를 참조합니다. 사용자 속성에 2020-01-01 값이 있는 사용자에게만 액세스 권한이 부여됩니다.

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

고려사항

액세스 권한이 있는 경우 사용자가 수정할 수 있는 사용자 속성은 허용되지 않습니다.

액세스 권한 부여는 사용자 액세스 수준이 수정인 사용자 속성을 허용하지 않습니다. 사용자는 계정 페이지에서 사용자 액세스 수준이 수정인 사용자 속성의 값을 보고 수정할 수 있습니다. 보안상의 이유로 access_grant에서는 사용자 액세스 수준이 없음 또는 보기인 사용자 속성만 허용됩니다.

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: [] 매개변수는 여러 값을 허용하지만 allowed_values: ["1", "3", "5"] 매개변수의 세 값 중 어느 것도 사용자 속성 값 1, 3, 5와 정확히 일치하지 않으므로 allowed_values: ["1", "3", "5"] 매개변수가 있는 액세스 권한 부여도 이 사용자에게 액세스 권한을 부여하지 않습니다. 이 경우 사용자 속성 값이 1, 3 또는 5인 사용자에게는 액세스 권한이 부여됩니다. 이러한 각 값이 allowed_values: ["1", "3", "5"] 매개변수의 옵션 중 하나와 일치하기 때문입니다.

마찬가지로 access_grant에는 문자열 필터 (고급) 데이터 유형의 사용자 속성과 정확히 일치해야 합니다. 일반적인 Looker 필터 표현식과 달리 allowed_values: [ "Ca%" ] 매개변수를 사용하면 값이 Canada 또는 California인 사용자 속성과 일치하지 않습니다. 정확히 Ca%인 사용자 속성 값만 일치하고 액세스 권한이 부여됩니다.

액세스 권한이 부여되지 않은 사용자는 LookML 구조에 따라 다른 동작을 경험합니다.

액세스 권한이 없는 사용자는 액세스하려고 하는 LookML 구조에 따라 다른 동작을 경험하게 됩니다. 이러한 구조에 대한 액세스가 제한되는 방식에 대한 자세한 내용은 탐색, 조인, 뷰 또는 필드 수준의 required_access_grants 문서 페이지를 참고하세요.

여러 수준의 액세스 권한이 합산됨

액세스 권한을 중첩하면 액세스 권한이 누적됩니다. 예를 들어 뷰의 required_access_grants를 만들고 뷰 내에 필드의 required_access_grants를 만들 수 있습니다. 필드를 보려면 사용자에게 필드 및 뷰에 대한 액세스 권한이 있어야 합니다. 조인의 경우도 마찬가지입니다. 조인의 뷰에 대해 required_access_grants를 만들고 이 두 뷰의 조인에 대해 required_access_grants를 만드는 경우 사용자가 조인된 뷰를 보려면 두 뷰와 조인에 대한 액세스 권한이 있어야 합니다.

제한된 구조를 참조하는 구조에 액세스

사용자는 액세스 권한이 없는 LookML 객체가 포함된 Look 또는 대시보드에 액세스할 수 있습니다. 이러한 상황에서는 Look 또는 대시보드가 해당 LookML 객체가 모델에서 삭제된 것처럼 표시됩니다.

조인 A, 뷰 A, 필드 A가 포함된 Explore A가 있다고 가정해 보겠습니다. 그런 다음 Explore A에 액세스 제한을 적용합니다. 예상대로 조인 A, 뷰 A, 필드 A는 사용자가 Explore A와 상호작용할 때만 해당 제한을 상속합니다. 조인 A, 뷰 A 또는 필드 A가 다른 Explore B에서 사용되는 경우 액세스 제한이 적용되지 않을 수 있습니다. 따라서 LookML 요소를 재사용할 계획이라면 가능한 가장 낮은 수준에서 액세스 제한을 적용하는 것이 좋습니다.