Rôles des applications : Permettre aux consommateurs de partager différentes vues des mêmes données¶

En tant que fournisseur, vous pouvez améliorer l’expérience des consommateurs en incluant des rôles d’application dans votre Declarative Native App. Un rôle d’application est un identifiant créé dans le contexte d’une Declarative Native App. Pour plus d’informations sur les rôles d’application, consultez À propos des rôles d’applications.

Les rôles d’application isolent la sécurité pour l’application, de sorte que les identifiants de connexion de sécurité spécifiques de l’application n’ont pas besoin d’être gérés dans le modèle de sécurité de l’organisation étendu du consommateur. En utilisant les rôles d’application, les fournisseurs peuvent contrôler l’accès aux ressources de l’application de manière simple. Les comptes de consommateur peuvent alors accorder l’accès à la logique d’application et aux données à l’aide de simples instructions SQL GRANT.

Par exemple, si une application utilise un rôle d’application Opérations pour accéder à une table de journal, le consommateur n’a pas besoin de conserver ce rôle d’application en dehors du contexte de l’application ; Il suffit de savoir qu’il peut partager l’application avec son équipe du support à l’aide du rôle d’application Opérations.

À l’aide du fichier manifeste, vous définissez les rôles de l’application et les attribuez au contenu de l’application. Lorsque le consommateur installe l’application, il peut partager le contenu avec les membres de son organisation en attribuant les rôles de l’application à leurs rôles d’organisation et à leurs utilisateurs. Les consommateurs peuvent également créer des hiérarchies de rôles de l’application en attribuant des rôles de l’application à d’autres rôles de l’application.

Les rôles de l’application permettent aux consommateurs de partager des données de différentes manières avec les membres de leur organisation. Par exemple, une application peut inclure deux notebooks pour présenter les données, l’un contenant une vue complète des données et l’autre une vue filtrée.

Le propriétaire de l’application du consommateur peut alors choisir de partager une vue filtrée avec une équipe, tout en ayant toujours accès à la vue complète pour lui-même.

Lorsque vous utilisez des rôles d’application pour autoriser l’accès aux ressources de la base de données, les ressources enfants héritent des rôles de leurs ressources parents. Par exemple, si vous attribuez un rôle d’application à un schéma, toutes les tables et vues de ce schéma héritent du rôle. Si vous attribuez un rôle d’application à une base de données, l’ensemble des schémas, tables et vues de cette base de données héritent du rôle.

Attribuer des rôles d’application au contenu du fichier manifeste¶

Dans le fichier manifeste, dans les champ des rôles de premier niveau, définissez les rôles d’application disponibles, par exemple, sales, marketing, et operations.

roles:
  - sales:
      comment: "The sales role provides access to the filtered view of the sales data."
  - marketing:
      comment: "The marketing role provides access to the filtered view of the marketing data."
  - operations:
      comment: "The operations role provides access to the full view of the data, including logs."

Copy

Attribuez des rôles d’application au contenu du fichier manifeste, à l’aide d’une liste, par exemple, roles: [sales, support] :
```
- customer_table:
  roles: [sales,marketing] # Accessible to sales and marketing, app owners
```
Copy
Pour ajouter une table, ajoutez le rôle à <named table>.roles et à <named schema>.roles où se trouve la table.
```
schemas:
  - sales_table:
    roles: [sales]
tables:
  - sales_table:
    roles: [sales]
```
Copy

Pour ajouter une vue, ajoutez le rôle à <named view>.roles et à <named schema>.roles où se trouve la vue.

schemas:
   - sales_view:
     roles: [sales]
views:
   - sales_view:
     roles: [sales]

Copy

Lors de l’ajout d’une vue filtrée d’une table, n’ajoutez pas la table sous-jacente ; cela empêche les utilisateurs d’accéder aux données non filtrées.

Pour inclure un notebook, ajoutez le rôle à <named notebook>.roles, et ajoutez les tables et les vues (et leurs schémas sous-jacents) référencées dans le notebook.

notebooks:
  - SALES_NB:
    main_file: ALL-DATA.ipynb
     roles: [sales]
     comment: Accessible to sales and app owners, references full view of the sales data

Copy

Lors de l’ajout d’un notebook qui fait référence à une vue filtrée d’une table, n’ajoutez pas la table sous-jacente, car cela empêche les utilisateurs d’accéder aux données non filtrées.
Pour ne donner à un objet aucun rôle d’application, laissez le champ vide ([]) ou omettez-le. Seul le propriétaire et les rôles de l’application avec IMPORTED PRIVILEGES autorisé peuvent accéder à ces objets.

- my_schema:
  roles: [] # Accessible to app owners only

Copy

Exemple de fichier manifeste :

roles:
  - sales:
      comment: "The sales role provides access to the filtered view of the sales data."
  - marketing:
      comment: "The marketing role provides access to the filtered view of the marketing data."
  - operations:
      comment: "The operations role provides access to the full view of the log data."

application_content:
  notebooks:
    - SALES_NB:
        main_file: ALL-DATA.ipynb
        roles: [sales]
        comment: Accessible to sales and app owners, references full view of the sales data

    - MARKETING_NB:
        main_file: FILTERED.ipynb
        roles: [marketing] #
        comment: Accessible to marketing and app owners, references filtered view of the marketing data

shared_content:
  databases:
    - my_database:
        schemas:
          - my_schema:
              roles: [] # Accessible to app owners
              tables:
                - sales_table:
                    roles: [sales] # Accessible to sales, app owners
                - marketing_table:
                    roles: [marketing] # Accessible to marketing, app owners
                - customer_table:
                    roles: [sales,marketing] # Accessible to sales and marketing, app owners
                - logs_table:
                    roles: [operations] # Accessible to operations and app owners
              views:
                - sales_view:
                    roles: [sales]   # Accessible to sales and app owners
                - marketing_view:
                    roles: [marketing] # Accessible to marketing and app owners
                - customer_view:
                    roles: [sales,marketing] # Accessible to sales, marketing, and app owners
                - operations_view:
                    roles: [operations] # Accessible to operations and app owners

Copy

Plus tard, lorsque le consommateur installera l’application, il aura accès aux notebooks, aux tables et aux vues.

Pour partager la vue des opérations avec son équipe de support, il accorde le rôle d’application opérations au rôle d’organisation de son équipe de support.

GRANT APPLICATION ROLE customer_app.operations TO ROLE support_team_west;

Copy

Les membres de l’équipe du consommateur avec le rôle support_team_west peuvent voir la table Journaux, mais ils ne peuvent pas voir les notebooks dans l’onglet Notebooks disponibles dans Snowsight, ou accéder aux tables et vues ventes et clients.

Pour partager la vue des ventes avec leur équipe de vente, ils accordent le rôle d’application ventes à leur rôle d’organisation de ventes.

GRANT APPLICATION ROLE customer_app.sales TO ROLE sales_team_east;

Copy

Les membres de l’équipe du consommateur avec le rôle sales_team_east peuvent voir le notebook dans l’onglet Notebooks disponibles dans Snowsight. Ils ne peuvent pas voir la table journaux, mais peuvent accéder aux tables et vues ventes et clients.

Pour plus d’informations sur la façon dont les consommateurs partagent les rôles, consultez Partager l’accès à l’application.