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 classique | CDS Access Control |
|---|---|
AUTHORITY-CHECK dans le code | Définition DCL sur la vue |
| Manuellement à chaque accès | Automatique au SELECT |
| Facile à oublier | Toujours actif |
| Code impératif | Règles déclaratives |
| Difficile à maintenir | Dé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: truedefine role ZI_Order { grant select on ZI_Order where ( CompanyCode ) = aspect pfcg_auth( Z_BUKRS, BUKRS, ACTVT = '03' );}Structure d’une DCL
| Élément | Description |
|---|---|
define role | Définit un rôle d’accès |
grant select on | Accorde l’accès en lecture sur la vue |
where | Condition pour l’accès aux données |
aspect | Aspect 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: truedefine 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: truedefine 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: #CHECKdefine 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
| Variable | Description |
|---|---|
$session.user | Utilisateur actuel |
$session.client | Mandant actuel |
$session.system_date | Date système |
$session.system_language | Langue 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: #CHECKdefine view entity ZI_SalesOrder as select from zsalesorder{ key SalesOrderID, SalesOrganization, Customer, NetAmount}Options authorizationCheck
| Valeur | Description |
|---|---|
#CHECK | DCL est vérifiée, avertissement si pas de DCL |
#NOT_REQUIRED | Aucune vérification requise |
#NOT_ALLOWED | DCL ne doit pas exister |
#PRIVILEGED_ONLY | Seul 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 DCLZSALESORDER (Table)Bonne pratique : Stratégie DCL
-- Interface View : Vérification complète des autorisationsdefine 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 Viewdefine 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 :
- Window → Show View → Other → Access Control Trace
- Démarrer la trace
- Interroger la vue
- Analyser la trace
Analyser l’instruction SQL
" Afficher le SQL généré avec les conditions DCLDATA(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 indexdefine role ZI_Order { grant select on ZI_Order where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );}
-- Mauvais : Expressions complexes sans indexdefine 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 courtswhere _Order.CompanyCode = ...
-- Moins performant : Chemins profondswhere _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
| Recommandation | Justification |
|---|---|
| Définir DCL sur l’Interface View | Emplacement central pour la logique d’autorisation |
inherits_all pour les Projections | Autorisations cohérentes |
| Index sur les champs d’autorisation | Performance avec de grands volumes |
| Réutiliser les objets PFCG | Intégration avec la gestion des rôles |
#CHECK par défaut | Sécurité par vérification obligatoire |
| Garder les chemins courts | Meilleure performance |
| Utiliser l’accès privilégié avec parcimonie | Minimiser 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
- Fondamentaux RAP - Concepts de base de RAP
- Fondamentaux des vues CDS - Définitions de vues CDS
- Feature Control & Side Effects - Contrôle dynamique de l’UI