Table of Contents: Authorization framework Overview ................................................................................3 Authorization framework architecture: ........................................................................3 Execution Of Authorization .........................................................................................4 Implementation Approach: ..............................................................................................4 Structure of authorization super class:..........................................................................4 Structure of authorization class for a specific BO: .......................................................5 Adding custom authorization requirement for a BO .....................................................5 Structure of the table MT_AC_ADM...........................................................................6 Additional Hooks ........................................................................................................7 Tips.................................................................................................................................8 DEMO Example:.............................................................................................................8
Authorization framework Overview: The authorization framework delivered by SAP is an enhancement of the old concept of authorization along with:
Service Manager based Authorization Checks Service Manager Plug-In with PRE- and POST-BOPF Methods. Explicit Authorization Checks. Privilege Mode Mapping from Internal IDs from BO Nodes into External IDs of Authority Fields. BO and Node specific “no authorization” messages. Mass enabled Equivalency Groups.
Authorization framework architecture: « in te r fa c e »
/bobf/ if_tra_service_manager
« in te r fa c e »
/BOBF/ IF_TRA_SERV_MGR_TRANSACT
« in te r fa c e »
/BOBF/ IF_TRA_PLUGIN_SERV_MGR
« in te r fa c e »
/BOBF/ IF_TRA_SERV_MGR_COMPL « in te r fa c e »
/BOBF/ IF_TRA_PLUGIN_SM_TRANS /B O B F /C L _ T R A _ S E R V IC E _ M G R O p e r a tio n s //IF _ T R A _ S E R V IC E _ M A N A G E R ~ C H E C K _ A C T IO N //IF _ T R A _ S E R V IC E _ M A N A G E R ~ C H E C K _ A N D _ D E T E R M IN E //IF _ T R A _ S E R V IC E _ M A N A G E R ~ C H E C K _ C O N S IS T E N C Y //IF _ T R A _ S E R V IC E _ M A N A G E R ~ C O N V E R T _ A L T E R N _ K E Y //IF _ T R A _ S E R V IC E _ M A N A G E R ~ D O _ A C T IO N //IF _ T R A _ S E R V IC E _ M A N A G E R ~ M O D IF Y //IF _ T R A _ S E R V IC E _ M A N A G E R ~ R E T R IE V E //IF _ T R A _ S E R V IC E _ M A N A G E R ~ R E T R IE V E _ B Y _ A S S O C IA T IO N //IF _ T R A _ S E R V IC E _ M A N A G E R ~ R E T R IE V E _ P R O P E R T Y //IF _ T R A _ S E R V IC E _ M A N A G E R ~ Q U E R Y //IF _ T R A _ S E R V _ M G R _ T R A N S A C T ~ D O _ S A V E
/S C M T M S /C L _ A C _ P L U G IN
« in te r fa c e »
/S C M T M S /IF _ A C « in te r fa c e »
/S C M T M S /IF _ A C _ B A D I O p e r a tio n s
/S C M T M S /C L _ A C _ S U P E R
B E F O R E _ AU TH C H K_ B A D I A F TE R _ A U T H C H K _ BA D I F IL T E R _ D A T A _ B A D I
A ttr ib u te s -
M T_ A U T H C H K _B U F F E R
+ + + + + + + + + + + + + + + + + + + + # # #
P O S T _ C H E C K _ A C T IO N P R E _ C H E C K _ A C T IO N P O S T _ C H E C K _ A N D _ D E T E R M IN E P R E _ C H E C K _ A N D _ D E T E R M IN E P O S T _ C H E C K _ C O N S IS T E N C Y P R E _ C H E C K _ C O N S IS T E N C Y P O S T _C O N V ER T_ A LT E R N _K E Y P O S T _ D O _ A C T IO N P R E _ D O _ A C T IO N P O S T _ M O D IF Y P R E _ M O D IF Y P O S T _ R E T R IE V E P R E _ R E T R IE V E P O S T _ R E T R IE V E _ B Y _ A S S O C IA T IO N P R E _ R E T R IE V E _ B Y _ A S S O C IA T IO N P O S T _ R E T R IE V E _ P R O P E R T Y P R E _ R E T R IE V E _ P R O P E R T Y P O S T _Q U E R Y PRE_QUERY P O S T _C H EC K_ B E F O R E _S A V E C O N ST R U C T O R C H E C K _ A U T H O R IT Y _ S IN G L E C H E C K _ A U T H O R IT Y
O p e r a tio n s
« in te r fa c e »
/S C M T M S /IF _ A C _ D A T A _ B A D I O p e r a tio n s G E T _ D A TA _ B AD I
/S C M T M S /C L _ A C _ F A C T O R Y O p e r a tio n s G E T _ A C _ IN S T A N C E
/S C M T M S /C X _ A U T H O R IT Y A ttr ib u te s M V_ U S E R M V _ S T A T IC M V _ T R IG G E R M V_ S R V M G R _M ET H M V_ B O _ K EY M V_ N O D E_ K EY M V_ K E Y
/S C M T M S /C L _ A C _ < B O >
Execution Of Authorization:
Authorization Object Instance based Field 1 Instance based Field 2 Instance based Field 3 .. .. Instance based Field 10
Business Object ROOT NODE Field1 Field2 … Field 10
ACTVT
As of now, we can have fields only from the ROOT node of the business object as part of the authority check fields.
Implementation Approach: Structure of authorization super class:
Super class /SCMTMS/CL_AC_SUPER To have AUTHORITY-CHECK object call for all the service manager method execution, the super class methods are implemented for each and every service manager method with appropriate trigger points. Each service manager method is implemented for PRE and POST method. In the standard, all the framework implementation is done in the PRE methods. POST methods are left blank. The constructor of super class implements a BADI call. This BADI is a hook provided by SAP for tweaking authority check as per the requirement. This is discussed in detail below.
Structure of authorization class for a specific BO:
The authorization class for any BO inherits the super class by default. Table: /SCMTMS/I_OBM_BO holds the authorization class for any specific BO. Constructor of each specific class is defined to load all possible authorization checks to be performed during the run of the UI for that specific BO. Eg: for the BO /SCMTMS/FO_SCHEDULE, the class is /SCMTMS/CL_AC_SCH. Constructor snapshot:
The internal table MT_AC_ADM is the key table which holds all the authorization related data. To add custom authorization, create an implicit enhancement of the constructor and populate the MT_AC_ADM table as per the requirement. Adding custom authorization requirement for a BO:
Step1: As discussed above, the current standard authorization framework provides authority check with fields of root node ONLY.
Before starting off, kindly evaluate if the authority check fields are a part of ROOT node or not. Step2: After making sure about the authority check fields, the authorization requirement has to be defined in the authorization class for that BO. Identify the class name from the table /SCMTMS/I_OBM_BO.
Step3: Create implicit enhancement of the constructor method for that specific class. Step4: Adding authority check requirement parameters: The internal table MT_AC_ADM is the key table which is to be filled with our custom requirement. Structure of the table MT_AC_ADM: AC_ID AC_OBJ SRVMGR_METH NODE_KEY FLT_NODE_KEY
Counter for the authority check Authority check object Service manager method name Node key for srvmeth retrieve / rba Node key for filter attribute and value (can be left initial if similar to no de_key)
FLT_NODE_ATT R FLT_ATTR_VAL ACT_KEY
Filter attribute for ac Filter attr. Value for ac Action key for srvmeth do_action
AC_TRIGGER
Trigger points. The possible values are defined in the super class.
Ac equivalency group id -> is at least one ac of a group successful ==> whole group is successful Just one positive result for this ac object leads to overall success of this check Whether the authority check is instance based or static check Whether the authority check should be triggered on save or not?
Message information which would be displayed on failure of the authority check
AC_REQ_TAB
Combination of the fields used for authority check requirements. Discussed in detail in the below table.
AC_REQ_TAB:
BO_ATTR
Authority check field from the root node Xbo node reference Bo node key. To be picked from the constants interface Field name which is the part of authority check
ACT_PARAM
Action parameter if authorization check is on a action
AC_FIELD XBO_NODE_KEY BO_NODE_KEY
QRES_ATTR QRES_NO_ATTR ALPHA_CONVERT AC_VALUE
Pass value to this field if you want to use static authority check. Else, leave it blank.
Additional Hooks:
Additional hooks provided by SAP in authorization framework: There are 2 BADI calls during execution of every service manager method.
BADI 1: /SCMTMS/AC_BADI This BADI is called before and after every authority check object. Provides possibilities to… replace the authorization check do a pre-processing before the standard authorization check do a post-processing after the standard authorization check filter the data after the authorization checks and the data filtering was done
BADI 2: /SCMTMS/AC_DATA_BADI Provides possibilities to… replace the data retrieval for the authorization check filter the data being used for the standard authorization check.
Tips: 1. The BADI call is implemented in the super class, these BADI are called for each authorization subclass (for all the BO’s). The interface of the BADI is given such that we can implement the BADI method for a specific BO (using node key, BO key, etc). We can modify the result of the authority check by just passing the SUBRC value. SUBRC = 0 Check Passed. SUBRC =12 Check failed. 2. In case there is a requirement to add multiple record in the internal table MT_AC_ADM at runtime, then this can be handled in the method: BUILD_MAPPING_TABLES. The interface of this method is such that, it provides the AC runtime table and BO data table at the same time. 3. If you want to have a authority check on the field which not a part of the ROOT NODE, then we can enhance the ROOT node structure using the INCLUDE extension. Fill this new field in the root node using a determination on create. 4. When we create a determination in the BOPF, there is a determination category of type = AUTHORTIY CHECK. This type of determination can be used to fulfill some of your authority check requirements. Kindly read F1 to understand more on this category.
DEMO Example: Requirement: To control the access of users for schedules based on schedule type for all the activities 01, 02 and 03. Solution: Step 1: Identify the business object. Answer: It is /SCMTMS/FO_SCHEDULE
Step 2: Identify the authorization class. Answer: Go to the table /SCMTMS/I_OBM_BO. Put the BO name. We will get the authorization class (/SCMTMS/CL_AC_SCH).
Step 3: All the authorization requirements are maintained in the constructor of this class. Create an implicit enhancement in the constructor.
Populate the internal table MT_AC_ADM. Possible values are 01, 02, 03.
Field name in the AUTHORITY object.
BOPF field name
Counter Authority object name Message that needs to displayed when check authority fails
