Differences

This shows you the differences between two versions of the page.

--- abap:autorisations [2013/02/27 14:30] – created ginko
+++ abap:autorisations [2020/01/24 16:59] (current) – [Transactions utiles] ginko
@@ Line 1: / Line 1: @@
 ====== Autorisations (ABAP) ======
+===== Transactions utiles =====
+  * SU01 : Gestion des utilisateurs (notamment onglets Rôles et Profils)
+  * ST01 : Trace des autorisations
+  * PFCG : Gestion des rôles
+  * SU21 : Liste des classes d'objet d'autorisations
+  * SU24 : Objets d'autorisation proposés par tcode
+  * SU53 : Last authorization check log (voir ce qui manque lors d'un refus d'autorisation)
+  * SE54 : Génération dialogue de gestion de tables > accès table/vue > Groupes d'autorisation
+  * SUIM : Navigation/recherche dans le contenu des divers objets d'autorisations
+===== Classes d'objets & objets d'autorisation classiques =====
+  * BC_A/S_TABU_DIS : Gestion de tables (via outils standard tels que SM30)
+  * S_DEVELOP : ABAP Workbench
+  * S_TCODE : Contrôle du code transaction lors lancement transaction
+===== Authority check =====
+Lors d'un authority-check, le noyau vérifie que le profile du user bénéficie d'au moins un set de valeur (un objet d'autorisation avec ses valeurs) compatible avec les valeurs demandées, quelque soit le rôle d'où il vient, y compris si des sets plus restrictifs existent. (Autrement dit, peu importe que la transaction soit affectée à tel ou tel rôle : un authority-check balaie tous les objets d'autorisations portés par le profile, peu importe leur origine.)
+Exemple 1 :
+  * Rôle R1 : Objet O1, Champ C1 = A, Champ C2 = B
+  * Rôle R2 : Objet O1, Champ C1 = C, Champ C2 = B
+=> Authority-check :
+  * Objet O1, C1 = A, C2 = B  => Granted (par combinaison A-B)
+  * Objet O1, C1 = A, C2 = D  => Forbidden (La combinsaison A-D n'existe pas)
+Exemple 2 :
+  * Rôle R1 : Objet O1, Champ C1 = A, Champ C2 = B
+  * Rôle R1 : Objet O1, Champ C1 = C, Champ C2 = D
+  * Rôle R2 : Objet O1, Champ C1 = C, Champ C2 = *
+=> Authority-check :
+  * Objet O1, C1 = A, C2 = B  => Granted (par combinaison A-B)
+  * Objet O1, C1 = A, C2 = D  => Forbidden (La combinsaison A-D n'existe pas)
+  * Objet O1, C1 = C, C2 = B  => Granted (par combinaison C-*, la combinaison C-D n'est pas considérée comme limitante)
+**__NB__ : Cela signifie que si un user porte un mélange de rôles restreint sur un niveau organisationnel et d'autres non limités (avec un ''*''), TOUS les objets portés par les rôles non limités prendront le pas sur leurs équivalents limités.**
+==== Contrôle du code transaction ====
-===== authority check =====
 <code abap>  CALL FUNCTION 'AUTHORITY_CHECK_TCODE'
        EXPORTING
@@ Line 10: / Line 47: @@
             OTHERS = 3.
 </code>
+==== contrôle généraliste ====
+Vérifier que le user à une autorisation sur un objet en particulier (quel qu'il soit).
+<code abap>
+AUTHORITY-CHECK OBJECT 'M_RECH_EKG'
+         ID 'ACTVT' FIELD '02'  "Display
+         ID 'EKGRP' FIELD 'ZZ'. "Purchasing group
+IF SY-SUBRC = 0.
+ " User has correct authority
+ENDIF.</code>
+===== Comment tester techniquement (en dev) les authors =====
+  * Créer un utilisateur dédié (su01, on peut copier un utilisateur existant pour aller vite)
+  * Vider ses rôles et profils (Certains rôles peuvent donner beaucoup de droits, notamment les rôles développeur...)
+  * Créer un rôle dédié avec :
+    * l'objet d'autorisation que l'on souhaite tester
+    * S_TCODE avec la valeur SE38
+    * S_DEVELOP avec l'ACTVT 16
+  * Affecter ce rôle à notre utilisateur dédié
+  * Votre programme, par exemple le programme de test suivant :<code abap>REPORT zdeu_test_authority_check .
+* Afficher
+AUTHORITY-CHECK OBJECT 'S_TABU_DIS'
+  ID 'DICBERCLS' FIELD 'ZWM1'
+  ID 'ACTVT' FIELD '03'.
+WRITE sy-subrc.
+* Modifier
+AUTHORITY-CHECK OBJECT 'S_TABU_DIS'
+  ID 'DICBERCLS' FIELD 'ZWM1'
+  ID 'ACTVT' FIELD '02'.
+WRITE sy-subrc.</code>
+  * Tester le programme avec l'utilisateur dédié.
+===== Démarche design autorisation =====
+Cas d'usage : demande de mise en place d'une nouvelle (restriction d') autorisation.
+  * Commencer à tester en ajoutant la transaction à un profil de test.
+  * Si les critères que l'on recherche ne sont pas dispo, regarder les objets maintenus en SU24.
+  * Si toujours rien, il faudra faire de nouveaux objets d'autorisation.
+===== Bug analysis =====
+Une différence entre la définition des rôles et les accès réels par les users peut avoir 2 origines :
+  * La génération (la transcription d'un rôle en profile - ''PFCG'', ''SUPC'')
+  * L'assignation (l'entrée correspondant au profile dans la user master data ''USRBF2'', ''UST12'' - ''SU01'', ''PFUD'')
+Pour l'analyse, toujours partir du profile utilisateur (''SU01''). Tester en direct. Tracer avec ''ST01''.
+En cas de problème tenace, activer les traces SQL (toujours en ''ST01'').
+NB :
+  * le menu de l'utilisateur est construit à partir des rôles (tables ''AGR*'') il ne dépend pas des profiles.
+  * Au contraire, la ''SUIM'' lit les profiles.
+=> On peut donc se reposer sur une différence entre menu et ''SUIM'' pour détecter un problème de génération/assignation.
+===== Pseudos AUTHORITY-CHECK =====
+Dans certains cas la trace des authority-checks "ment" : la transaction peut remonter des défauts d'authorisations alors que la trace ne montre que des RC=0. En passant par le MF SUSR_USER_AUTH_FOR_OBJ_GET, le programme peut récupérer des autorisations sans AUTHORITY-CHECK. Ex : la restriction sur la division en MI20.