CDS Access Control (DCL) : Autorisations granulaires

Catégorie
CDS
Publié
Auteur
Johannes

CDS Access Control permet de définir des contrôles d’autorisation directement au niveau des vues CDS. Avec le Data Control Language (DCL), les règles d’accès sont définies de manière déclarative et appliquées automatiquement à chaque accès à la vue.

Concept de base

L’Access Control dans CDS déplace la vérification des autorisations de la logique applicative vers la couche base de données :

Vérification classiqueCDS Access Control
AUTHORITY-CHECK dans le codeDéfinition DCL sur la vue
Manuellement à chaque accèsAutomatique au SELECT
Facile à oublierToujours actif
Code impératifRègles déclaratives
Difficile à maintenirDéfini de manière centralisée

Avantages

  • Définition centralisée : Autorisation définie une fois, efficace partout
  • Pas d’oubli : Accès sans autorisation impossible
  • Performance : Optimisation par DB-Pushdown
  • Transparence : Règles visibles directement sur la vue

Définition Access Control

Une définition Access Control est un artefact CDS séparé avec l’extension .dcl :

@EndUserText.label: 'Access Control pour les commandes"
@MappingRole: true
define role ZI_Order {
grant select on ZI_Order
where ( CompanyCode ) = aspect pfcg_auth( Z_BUKRS, BUKRS, ACTVT = '03' );
}

Structure d’une DCL

ÉlémentDescription
define roleDéfinit un rôle d’accès
grant select onAccorde l’accès en lecture sur la vue
whereCondition pour l’accès aux données
aspectAspect d’autorisation (p.ex. PFCG)

Autorisation PFCG

Le cas d’utilisation le plus courant est l’intégration avec les objets d’autorisation PFCG :

@EndUserText.label: 'Sales Order Access"
@MappingRole: true
define role ZI_SalesOrder {
grant select on ZI_SalesOrder
where ( SalesOrganization ) =
aspect pfcg_auth( V_VBAK_VKO, VKORG, ACTVT = '03' );
}

Paramètres de l’aspect pfcg_auth

aspect pfcg_auth(
<ObjetAutorisation>,
<ChampDansObjet>,
<Activité> = '<Valeur>"
)
  • Objet d’autorisation : Nom de l’objet PFCG (p.ex. V_VBAK_VKO)
  • Champ dans l’objet : Champ à vérifier (p.ex. VKORG)
  • Activité : Valeur ACTVT (01=Créer, 02=Modifier, 03=Afficher)

Vérifier plusieurs champs

@MappingRole: true
define role ZI_Material {
grant select on ZI_Material
where ( Plant, MaterialType ) =
aspect pfcg_auth( M_MATE_WRK, WERKS, MTART, ACTVT = '03' );
}

Conditions complexes

Liaison AND

define role ZI_PurchaseOrder {
grant select on ZI_PurchaseOrder
where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' )
and ( PurchasingOrganization ) = aspect pfcg_auth( M_BEST_EKO, EKORG, ACTVT = '03' );
}

Liaison OR

define role ZI_Document {
grant select on ZI_Document
where ( DocumentType ) = aspect pfcg_auth( Z_DOCTYPE, BSART, ACTVT = '03' )
or ( DocumentType ) = 'PUBLIC';
}

Logique combinée

define role ZI_Order {
grant select on ZI_Order
where (
( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' )
and ( ( SalesOrg ) = aspect pfcg_auth( V_VBAK_VKO, VKORG, ACTVT = '03' )
or Status = 'RELEASED' )
);
}

Expressions de chemin pour les associations

Pour les données hiérarchiques, l’autorisation peut être vérifiée via des associations :

@AccessControl.authorizationCheck: #CHECK
define view entity ZI_OrderItem
as select from zorder_item
association [1..1] to ZI_Order as _Order
on $projection.OrderID = _Order.OrderID
{
key OrderID,
key ItemNumber,
Material,
Quantity,
_Order
}

La DCL vérifie via le chemin :

define role ZI_OrderItem {
grant select on ZI_OrderItem
where ( _Order.CompanyCode ) =
aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

Chemins profonds

define role ZI_OrderItemSchedule {
grant select on ZI_OrderItemSchedule
where ( _OrderItem._Order.CompanyCode ) =
aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

Autorisations basées sur les aspects

Aspects d’autorisation personnalisés

En plus de pfcg_auth, des aspects personnalisés peuvent être définis :

@EndUserText.label: 'User Country Aspect"
define abstract entity ZA_UserCountry
{
Country : land1;
}

Utilisation dans DCL :

define role ZI_Customer {
grant select on ZI_Customer
where Country = aspect ZA_UserCountry.Country;
}

Aspect Inherit

L’aspect inherit reprend les autorisations d’une entité de base :

define role ZC_SalesOrder {
grant select on ZC_SalesOrder
where inherits_all;
}

Cela signifie : La vue de projection hérite de la DCL de la vue d’interface sous-jacente.

Autorisations contextuelles

Attributs utilisateur

define role ZI_Employee {
grant select on ZI_Employee
where PersonnelArea IN
aspect pfcg_auth( PLOG, PERSA, ACTVT = '03' )
or EmployeeID = $session.user;
}

Variables système

VariableDescription
$session.userUtilisateur actuel
$session.clientMandant actuel
$session.system_dateDate système
$session.system_languageLangue de connexion
define role ZI_PersonalData {
grant select on ZI_PersonalData
where CreatedBy = $session.user
or Visibility = 'PUBLIC';
}

Activer l’Access Control sur la vue

La vue CDS doit activer la vérification Access Control :

@AccessControl.authorizationCheck: #CHECK
define view entity ZI_SalesOrder
as select from zsalesorder
{
key SalesOrderID,
SalesOrganization,
Customer,
NetAmount
}

Options authorizationCheck

ValeurDescription
#CHECKDCL est vérifiée, avertissement si pas de DCL
#NOT_REQUIREDAucune vérification requise
#NOT_ALLOWEDDCL ne doit pas exister
#PRIVILEGED_ONLYSeul l’accès privilégié est autorisé

Accès privilégié

Pour les opérations système, l’Access Control peut être contourné :

" Avec accès privilégié (DCL est ignorée)
SELECT * FROM zi_salesorder
WITH PRIVILEGED ACCESS
INTO TABLE @DATA(lt_orders).
" Accès normal (DCL est appliquée)
SELECT * FROM zi_salesorder
INTO TABLE @DATA(lt_orders_filtered).

Quand utiliser l’accès privilégié ?

  • Traitement par lots : Jobs en arrière-plan sans contexte utilisateur
  • Intégration système : Appels RFC/API depuis d’autres systèmes
  • Reporting : Évaluations agrégées
  • Administration : Opérations à l’échelle du système

Vues hiérarchiques

Dans les hiérarchies de vues, la DCL est vérifiée à chaque niveau :

ZC_SalesOrder (Projection)
↓ Vérifie sa propre DCL (peut utiliser inherit)
ZI_SalesOrder (Interface View)
↓ Vérifie sa propre DCL
ZSALESORDER (Table)

Bonne pratique : Stratégie DCL

-- Interface View : Vérification complète des autorisations
define role ZI_SalesOrder {
grant select on ZI_SalesOrder
where ( SalesOrg ) = aspect pfcg_auth( V_VBAK_VKO, VKORG, ACTVT = '03' );
}
-- Projection View : Hérite de l'Interface View
define role ZC_SalesOrder {
grant select on ZC_SalesOrder
where inherits_all;
}

Comparaison avec les Authority-Checks classiques

Approche classique

METHOD get_sales_orders.
" Vérifier manuellement l'autorisation
AUTHORITY-CHECK OBJECT 'V_VBAK_VKO"
ID 'VKORG' FIELD lv_sales_org
ID 'ACTVT' FIELD '03'.
IF sy-subrc <> 0.
RAISE EXCEPTION TYPE cx_no_authority.
ENDIF.
" Puis lire les données
SELECT * FROM zsalesorder
WHERE vkorg = @lv_sales_org
INTO TABLE @rt_orders.
ENDMETHOD.

Approche CDS Access Control

METHOD get_sales_orders.
" DCL vérifie automatiquement - seules les données autorisées sont retournées
SELECT * FROM zi_salesorder
INTO TABLE @rt_orders.
ENDMETHOD.

Débogage et analyse

Trace Access Control

Dans ADT, la trace Access Control peut être activée :

  1. Window → Show View → Other → Access Control Trace
  2. Démarrer la trace
  3. Interroger la vue
  4. Analyser la trace

Analyser l’instruction SQL

" Afficher le SQL généré avec les conditions DCL
DATA(lo_sql) = cl_sql_statement=>create_for_cds_entity(
iv_cds_entity = 'ZI_SALESORDER' ).
DATA(lv_sql) = lo_sql->get_native_sql( ).

Aspects de performance

Utilisation des index

Les conditions DCL sont traduites en clauses WHERE. Pour de bonnes performances :

-- Bon : Champ avec index
define role ZI_Order {
grant select on ZI_Order
where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}
-- Mauvais : Expressions complexes sans index
define role ZI_Order {
grant select on ZI_Order
where SUBSTRING( OrderNumber, 1, 2 ) = 'AB';
}

Optimiser les expressions de chemin

-- Performance : Préférer les chemins courts
where _Order.CompanyCode = ...
-- Moins performant : Chemins profonds
where _OrderItem._Order._Customer._Country.Region = ...

Modèles courants

Voir ses propres données

define role ZI_MyDocuments {
grant select on ZI_MyDocuments
where CreatedBy = $session.user
or AssignedTo = $session.user;
}

Données publiques et propres

define role ZI_Announcement {
grant select on ZI_Announcement
where Visibility = 'PUBLIC"
or ( Visibility = 'PRIVATE' and Owner = $session.user );
}

Autorisation temporelle

define role ZI_Campaign {
grant select on ZI_Campaign
where ValidFrom <= $session.system_date
and ValidTo >= $session.system_date;
}

Bonnes pratiques

RecommandationJustification
Définir DCL sur l’Interface ViewEmplacement central pour la logique d’autorisation
inherits_all pour les ProjectionsAutorisations cohérentes
Index sur les champs d’autorisationPerformance avec de grands volumes
Réutiliser les objets PFCGIntégration avec la gestion des rôles
#CHECK par défautSécurité par vérification obligatoire
Garder les chemins courtsMeilleure performance
Utiliser l’accès privilégié avec parcimonieMinimiser les risques de sécurité

Résumé

CDS Access Control avec DCL offre :

  • Autorisations déclaratives : Règles définies directement sur la vue CDS
  • Vérification automatique : Impossible d’oublier les Authority-Checks
  • Intégration PFCG : Utilisation des objets d’autorisation existants
  • Expressions de chemin : Vérifier les autorisations via les associations
  • Performance : Optimisation par DB-Pushdown

DCL est l’approche moderne pour la sécurité des données dans ABAP Cloud et devrait être utilisée pour toutes les vues CDS contenant des données sensibles.

Sujets connexes