FAQ: Authorization Check
1.1 Question: Can I simulate the absence of an authorization?
Answer: A missing authorization can be simulated by initializing the corresponding flag at a suitable place in the debugger. Apart from this - and this method is to be preferred - you can already initialize the corresponding flag in the CNAU at the end of the authorization checks of the respective object (an example for this procedure is described in note 522426).
1.2 Question: Is the calling of a transaction already affiliated with an authorization? If so, with which?
Answer: Transaction codes, for example CJ01 (Project creation), are generally already provided with an authorization. To display the checked authorization object and its required characteristic:
Transaction SM31 with table TSTC
Enter transaction code
1.3 Question: At what time do the authorization checks occur?
Answer: Generally the respective authorizations are already analyzed during the import of master data, that is, the system executes an authorization check with regard to allowed actions (for example, creation, change, display, and so on) for every master data object (for example project definition, WBS element, and so on). Also during the saving the system executes a final check for created, changed and deleted objects. Only in exceptions, for example change of project number for project definition or WBS element, the system executes a further, explicit authorization check.
1.4 Question: Where do the authorization checks occur in the system?
Answer: These checks occur centrally in function group CNAU. For projects the following modules are relevant:
CNAU_AUTHORITY_PROJ authorization check for project definition
CNAU_AUTHORITY_PROJ_MULTI authorization check for project definitions
CNAU_AUTHORITY_PRPS authorization check for WBS element
CNAU_AUTHORITY_PRPS_MULTI authorization check for WBS elements
CNAU_AUTHORITY_PSTX authorization check for PS text
CNAU_AUTHORITY_PSTX_MULTI authorization check for PS texts
CNAU_AUTHORITY_TCD C_PROJ_TCD transaction code authorization
CNAU_AUTHORITY_VERS authorization check for project version
1.5 Question: What is an authorization object?
Answer: An authorization check always occurs against authorization objects. All R/3 authorization objects are found by means of transaction SU03. The authorization objects are generally self-explanatory. You can determine the exact importance of an authorization object and its checked values by navigation with double-click.
Example: C_PRPS_KOK checks against fields 'Controlling area' and 'Action'. For example, actions are here 01 (Create), 02 (Change) and 03 (Display). You find the PS-relevant authorization objects and further information in note 522426, section 9.
1.6 Question: What is an authorization profile?
Answer: The authorizations of the authorization objects are summarized in profiles; the profiles are grouped together to common profiles. Profiles and common profiles can also be created by the Profile Generator. Profiles and common profiles are assigned to the user. If an authorization object is represented in several profiles, the system will user the 'larger' authorization.
Example: For object C_PRPS_KOK the user has a display authorization in profile A and a change authorization in profile B; both profiles are assigned to him. Therefore the user has the change permission for the respective controlling area. Detailed information on authorization profiles is available in note 522426, chapter 9.
1.7 Question: How can I detect in the debugger, whether the system executes an authorization check?
Answer: The debugger stops at such a place if a breakpoint is set for language element AUTHORITY-CHECK. With such a breakpoint you can also generally verify whether an explicit authorization check is actually carried out.
Important: Constructs such as CALL TRANSACTION or SUBMIT generate a new logical unit of work (LUW) in which the breakpoints from the other LUW are not known. The transaction or the report must be 'entered' in the debugger with a single step. The breakpoints must be set again correspondingly in the new LUW.
1.8 Question: It is possible to forbid certain business activities?
Answer: With the SAP authorization concept it is not possible you cannot exclusively forbid specific business activities (for example, Release WBS element). For example, a user may release a WBS element as soon as he has the authorization for changing the WBS element. However, he is not allowed to change the WBS element (release) if he does not have any change authorization.
1.9 Question: Are there authorization checks in standard objects?
Answer: In the standard project there is not individual authorization check in the standard by design. As of Release 4.6C you can however implement a BAdI via note 523162, in which for objects 'Standard project definition' and 'Standard WBS element' you can develop a customer-specific authorization check during the import and saving of the data.
2. Special system behavior
2.1 Question: How can I control the display/ready for input status for fields of the Project definition and the WBS element on the screen?
Answer: The display or ready for input status are controlled with the help of flags in the CJWB:
FLG_INPDF = X authorization for the project change
FLG_OUTDF = X authorization for the project display
The authorization of every individual WBS element is stored in buffer table PSTAB in CJDW.
You will find a detailed description of the system behavior in note 522426.
2.2 Question: How can I control the display/ready for input status on customer-specific screens?
Answer: Generally the fields are displayed as ready for input on the customer-specific screens, independent of the authorizations, the transaction type (display mode, change mode, and so on) as well as the system status (Locked for example) and the user status.
Here, each customer must carry out suitable checks in the PBO of his customer-specific screen. As a template you can use the SAP standard PBO module MODIF_PBO from function group CJWB.
2.3 Question: How are authorizations hierarchically inherited by the network activity from the WBS element?
Answer: If WBS elements and network activities are assigned to each other, the system generates no hierarchical inheritance of the authorizations. In other words: If a user does not have any change authorization for a WBS element, you can not make an assertion whether there is a change authorization or not for the hierarchically subordinate activity. This is exclusively decided due to the authorizations that were assigned to the user concerning the network. Also the network and its activities are generally already checked during the import of the master data in CNAU (see F4 help in transaction SE37 for CNAU_AUTHORITY*).
2.4 Question: Why are - in case of activated customer enhancement (CNEX0002) - authorizations that are available when the Customer enhancement is deactivated?
Answer: In case of an activated customer enhancement, not passed function modules will return value SAP_X_ACTVT = SPACE (initial), and thus no user has the corresponding authorizations. Detailed information on this topic is available in notes 61886, 422558 and 433328.