Utilisation
access_grant: access_grant_name {
user_attribute: user_attribute_name
allowed_values: [ "value_1", "value_2" , ... ]
}
|
Hiérarchie
access_grant |
Valeur par défaut
Aucun
Acceptation
Nom d'un attribut utilisateur avec le sous-paramètre user_attribute et liste des valeurs d'attribut utilisateur avec le sous-paramètre allowed_values
|
Définition
Une autorisation d'accès est une structure LookML définie dans un fichier de modèle qui contrôle l'accès à d'autres structures LookML, en particulier les explorations, les jointures, les vues et les champs. Le paramètre access_grant définit un accès accordé.
access_grant prend le nom d'un attribut utilisateur avec le sous-paramètre user_attribute et une liste de valeurs acceptables pour l'attribut utilisateur avec le sous-paramètre allowed_values. Seuls les utilisateurs auxquels est attribuée l'une des valeurs autorisées dans l'attribut utilisateur spécifié peuvent accéder aux structures pour lesquelles un droit d'accès est requis.
Une fois défini, vous pouvez utiliser le paramètre required_access_grants au niveau de l'exploration, de la jointure, de la vue ou du champ pour exiger l'octroi d'accès à ces structures.
Par exemple, le LookML suivant crée un accès autorisé appelé can_view_financial_data, basé sur l'attribut utilisateur department. Seuls les utilisateurs auxquels sont attribuées les valeurs "finance" ou "executive" dans l'attribut utilisateur department ont accès au droit d'accès can_view_financial_data :
access_grant: can_view_financial_data {
user_attribute: department
allowed_values: [ "finance", "executive" ]
}
Vous associez ensuite l'autorisation d'accès can_view_financial_data à une structure LookML à l'aide du paramètre required_access_grants :
dimension: financial_data_field
...
required_access_grants: [can_view_financial_data]
}
Dans cet exemple, seuls les utilisateurs qui disposent de la valeur d'attribut utilisateur appropriée pour le droit d'accès can_view_financial_data verront la dimension financial_data_field.
Vous pouvez définir plusieurs droits d'accès dans un modèle et en attribuer plusieurs à une structure LookML avec le paramètre required_access_grants. Dans ce cas, un utilisateur doit avoir accès à tous les accès spécifiés pour pouvoir accéder à la structure LookML.
Par exemple, le LookML suivant définit deux accès différents :
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" ]
}
Ensuite, dans le fichier de vue, le paramètre required_access_grants spécifie les deux droits d'accès :
view: payroll {
...
required_access_grants: [can_view_financial_data, can_view_payroll_data]
}
Dans ce cas, seuls les utilisateurs dont l'attribut utilisateur department est défini sur la valeur "finance" et dont l'attribut utilisateur view_payroll est défini sur la valeur "yes" peuvent accéder à la vue."executive"
Exemples
Définissez un droit d'accès qui exige que les utilisateurs disposent de la valeur "product_management" ou "engineering" dans l'attribut utilisateur department pour accéder au droit d'accès engineering :
access_grant: engineering {
user_attribute: department
allowed_values: [ "product_management", "engineering" ]
}
Vous pouvez également définir des droits d'accès avec des attributs utilisateur qui acceptent les données numériques ou de date/heure. Pour ce faire, vous devez placer les valeurs autorisées entre guillemets doubles, comme vous le feriez avec une chaîne. Par exemple, l'attribution d'accès suivante fait référence à l'attribut utilisateur id, dont le type de données est number. Seuls les utilisateurs dont la valeur id est égale à 1, 2, 3, 4 ou 5 auront accès à l'application :
access_grant: user_id {
user_attribute: id
allowed_values: ["1", "2", "3", "4", "5"]
}
L'exemple suivant fait référence à l'attribut utilisateur start_date, dont le type de données est Date/Heure. Seuls les utilisateurs dont l'attribut utilisateur a la valeur 2020-01-01 pourront y accéder :
access_grant: start_date {
user_attribute: start_date
allowed_values: ["2020-01-01"]
}
Éléments à prendre en compte
Les attributs utilisateur modifiables par l'utilisateur ne sont pas autorisés avec les autorisations d'accès
Les attributions d'accès ne peuvent pas accepter les attributs utilisateur dont le niveau d'accès Utilisateur est défini sur Modifier. Les utilisateurs peuvent voir et modifier les valeurs des attributs utilisateur dont le niveau d'accès utilisateur est défini sur Modifier sur la page de leur compte. Pour des raisons de sécurité, seuls les attributs utilisateur dont le niveau d'accès utilisateur est défini sur Aucun ou Afficher sont autorisés avec access_grant.
Les valeurs listées dans allowed_values doivent correspondre exactement aux valeurs des attributs utilisateur.
access_grant fonctionne avec les attributs utilisateur dont le type de données est Filtre de chaîne (avancé), Filtre numérique (avancé) ou Filtre de date/heure (avancé). Toutefois, pour accorder l'accès, les valeurs listées dans le paramètre allowed_values doivent correspondre exactement à la valeur de l'attribut utilisateur.
Par exemple, si vous avez créé un attribut utilisateur appelé numeric_range avec le type de données Filtre numérique (avancé), vous pouvez utiliser une expression de filtre Looker pour saisir une plage de nombres, comme [1, 20]. Dans cet exemple, l'expression de filtre Looker dans l'attribut utilisateur renverra une plage de nombres comprise entre 1 et 20 (inclus). Toutefois, comme access_grant nécessite une correspondance exacte, l'utilisation du paramètre allowed_values: ["10"] n'accorderait pas l'accès. Pour accorder l'accès, vous devez utiliser allowed_values: ["[1, 20]"].
Cela vaut également pour les attributs utilisateur comportant plusieurs valeurs. Par exemple, un attribut utilisateur avec le type de données Filtre numérique (avancé) et la valeur 1, 3, 5 ne correspondra qu'à un accès accordé avec le paramètre allowed_values: ["1, 3, 5"]. De même, un droit d'accès avec le paramètre allowed_values: ["1"] n'accorderait pas l'accès à l'utilisateur avec plusieurs valeurs dans l'attribut utilisateur. Une autorisation d'accès avec le paramètre allowed_values: ["1", "3", "5"] n'accorderait pas non plus l'accès à cet utilisateur, car, bien que le paramètre allowed_values: [] puisse accepter plusieurs valeurs, aucune des trois valeurs du paramètre allowed_values: ["1", "3", "5"] ne correspond exactement à la valeur de l'attribut utilisateur 1, 3, 5. Dans ce cas, un utilisateur dont la valeur de l'attribut utilisateur est 1, 3 ou 5 aurait accès, car chacune de ces valeurs correspond à l'une des options du paramètre allowed_values: ["1", "3", "5"].
De même, access_grant nécessite une correspondance exacte avec les attributs utilisateur de type de données Filtre de chaîne (avancé). Contrairement aux expressions de filtre Looker classiques, l'utilisation du paramètre allowed_values: [ "Ca%" ] ne correspond pas à un attribut utilisateur avec les valeurs Canada ou California. Seule une valeur d'attribut utilisateur correspondant exactement à Ca% sera acceptée et permettra d'accorder l'accès.
Les utilisateurs auxquels l'accès n'est pas accordé rencontrent un comportement différent selon la structure LookML.
Un utilisateur qui n'a pas accès à une autorisation d'accès aura un comportement différent selon la structure LookML à laquelle il tente d'accéder. Consultez les pages de documentation required_access_grants au niveau Explorer, Rejoindre, Afficher ou Champ pour savoir comment l'accès à ces structures est limité.
Les droits d'accès à plusieurs niveaux sont cumulés.
Si vous imbriquez des autorisations d'accès, elles sont cumulatives. Par exemple, vous pouvez créer required_access_grants pour une vue et required_access_grants pour un champ dans la vue. Pour voir le champ, un utilisateur doit disposer d'autorisations d'accès au champ et à la vue. Il en va de même pour les jointures : si vous créez required_access_grants pour les vues d'une jointure et required_access_grants pour la jointure de ces deux vues, un utilisateur doit disposer d'autorisations d'accès aux deux vues et à la jointure pour pouvoir voir la vue jointe.
Accéder à des structures qui font référence à des structures restreintes
Les utilisateurs peuvent avoir accès à des Looks ou des tableaux de bord contenant des objets LookML auxquels ils n'ont pas accès. Dans ce cas, le Look ou le tableau de bord s'affichent comme si ces objets LookML avaient été supprimés du modèle.
Supposons que nous ayons une exploration A, qui contient la jointure A, la vue A et le champ A. Ensuite, nous allons restreindre l'accès à l'exploration A. Comme prévu, la restriction sera héritée par la jointure A, la vue A et le champ A, mais uniquement lorsque les utilisateurs interagiront avec l'exploration A. Si la jointure A, la vue A ou le champ A sont utilisés dans une autre exploration B, ils ne seront pas nécessairement soumis à des restrictions d'accès. Par conséquent, si vous prévoyez de réutiliser des éléments LookML, nous vous suggérons d'appliquer des restrictions d'accès au niveau le plus bas possible.