Analysis of Authorizations in SAP R/3 - CEUR-WS.org

1 Analysis of Authorizations in SAP R/3 Manuel Lamotte-Schubert and Christoph WeidenbachMax Planck Institute for Informatics, Campus E1 4,D-66123 Saarbr many companies use an ERP (Enterprise ResourcePlanning) system such as SAP R/3 to run their daily business rang-ing from financial issues down to the actual control of a production due to their sheer size, these systems are very complex. In partic-ular, developing and maintaining the authorization setup is a goal of our effort is to automatically analyze the authorization setupof an SAP R/3 system against business policies. To this end weformalizethe processes, authorization setup as well as the business policies in first-order logic. Then, properties can be (dis)proven fully automatically withour theorem proverSpass. We exemplify our approach on the purchaseprocess, a typical constituent of any SAP R/3 IntroductionEnterprise Resource Planning (ERP) systems are built to integrate all facets ofthe business across a company including areas like finance, planning, manufac-turing, sales, or marketing.

2 The broader the functionalityof such a system, thelarger the number of users, the greater the dynamics of a company, the morecomplex is the administration of the Authorizations . In particular, this appliesto the SAP R/3 system offered by SAP [1]. In this paper we investigate theauthorization setup of SAP R/3. Although SAP R/3 is not the newest release,the most recent release SAP ERP actually shares the same approach is depicted in Fig. 1. When a company decides to use an ERPsystem like SAP R/3, it first formulates its business as processes. For example,a typical purchase process starts with the creation of a purchase requisition outof a purchase request, followed by the release of such a requisition, and finallythe transformation of the released requisition into the purchase that is eventu-ally sent to a supplier. The processes directly induce an authorization often each step of a process corresponds to a particularrole of a companyemployee.

3 For our example, the transformation of the released requisition into apurchase is a typical buyer activity. The development of processes and the au-thorization concept is guided by business policies. For ourexample, a business SAP, SAP R/3 and SAP ERP are registered trademarks of SAP AG in Germanyand in several other PoliciesAuthorization SetupSAP R/3 InstanceBusinessProcessFormalizationBusi ness PolicyFormalizationAuthorization FormalizationFirst-Order Formal ModelPropertiesCompanyFig. of Authorizations in SAP R/3policy might require that the activity of creating a requisition and creating apurchase must always be separated, performed by different persons, and there-fore must not be contained in one authorization role. This isa typical rule outof theSegregation/Separation of Duties(SoD) approach. Once the processesand authorization concept are defined, the configuration is implemented into anSAP R/3 instance leading to a corresponding process and authorization to the sheer size of an SAP project, the number of processes, different em-ployee roles and the highly dynamic development of such a system over time,it is practically impossible to guarantee the compliance ofthe business policieswith the process and authorization setup.

4 Furthermore, it is non-trivial to setup new authorization roles for employees following organizational changes in thebusiness without destroying the overall compliance between the authorizationsetup and the business suggest to solve this problem by first-order logic theoremproving. Wemodel the process and authorization setup in first-order logic and automaticallyanalyze it with respect to a first-order formulation of the business terminates for provable (it ends with a proof) and non-provable cases (itends with a saturated set of clauses). The termination ofSpassenables the use ofan abduction principle deriving missing facts. Then, defining new authorizationroles can be solved by saturating abductive queries (Sect. 5). Formulating theprocesses and business policies has to be done by hand ( ). However, the au-thorization setup can be formulated automatically and we suggest a tool pipeline(Sect. ). In practice, the changes to the authorization setup, , caused byorganizational changes in a company, cause the most headache to SAP autho-91rization administrators.

5 Business policies and processesare less likely to changeand if they change this is not done on a daily basis but by additional smallerSAP change/introduction projects. Therefore, our approach offers a reasonableamount of automatization. As an example SAP R/3 instance forstudying theSAP internal process and authorization setup we used the SAPR/3 system runby the Max Planck have been other efforts to address the verification of the authorizationsetup in SAP R/3. SAP itself offers a tool collection for Governance, Risk andCompliance. The main difference to our approach is that thesetools are onlyable to check compliance with respect to the transactions performed duringconcrete runs of the system and are not able to prove the overall complianceof the authorization setup with the business policies. Furthermore, there is notool support for the business policy compliant generation of new authorizationroles available up to now.

6 Other efforts include the general verification of role-based access control principle together with constraints like SoD [2] but theyare neither connected to the SAP R/3 system nor they do incorporate businessprocesses. To the best of our knowledge, there has been no attempt so far toanalyze the Authorizations in SAP R/3 together with the business processes andbusiness paper is organized as follows. After explaining the basic first-order no-tation (Sect. 2) the SAP R/3 internal mechanisms are studiedwith respect toprocesses and Authorizations in Sect. 3, followed by the formalization in first-order logic (Sect. 4). Due to space limitations we only explain important aspectsof the developed first-order theory, hiding details that arenot needed to under-stand the main ideas. Nevertheless, the overall formalization can be obtainedfrom theSpasshomepage ( ) in the prototype and exper-iments section. Our results on experiments are contained in Sect.

7 5 and thepaper ends with a small conclusion and ideas for future work (Sect. 6).2 BackgroundThe formalization of the process, authorization setup and business policies isaccomplished using first-order logic without equality. Thefollowing syntax defi-nition as well as the semantics of the used language is taken from [3].A first-order language is constructed over a signature = (F,R), whereFandRare non-empty, disjoint, in general infinite sets of function and predicatesymbols, respectively. Every function or predicate symbolhas some fixed addition to these sets that are specific for a first-order language, we assumea further, infinite setXof variable symbols disjoint from the symbols in .Then the set of alltermsT(F,X) is defined as usual. A term not containinga variable is aground term. Ift1, .. , tnare terms andR Ris a predicatesymbol with arityn, thenR(t1, .. , tn) is anatom. An atom or the negation ofan atom is calledliteral.

8 Disjunctions of literals areclauseswhere all variablesare implicitly universally recursively constructed overatoms and the operators (implication), (equivalence), (conjunction), 92(disjunction), (negation) and the quantifiers (universal), (existential) asusual. For convenience, we often write x1, .. , xn. instead of x1.. xn. and analogously for the existential quantifier and assume the descending bindingprecedence , , , , , .The formal model uses predicate symbols whose first letter isalways upper-case and the predicate itself is italic, the predicateAccessis used to representthe authorization access relation for a user, the atomAccess(MUELLER,ME51N) ex-presses that userMUELLER holds all rights to perform the transactionME51N, thecreation of a purchase requisition. Constants originatingfrom SAP R/3 are al-ways written in typewriter font, In general, function names startwith a lowercase letter different from x , the functionauthObjis used torepresent an authorization (object).

9 Variables are alwaysprefixed with x andwritten lowercase, for example,xu, we do not explicitly define sorts, our formulae are actually many-sorted. For the explanation of our predicate and function usage we sometimesrefer to these implicit sorts by putting them in square brackets. For example,the declaration Access(<user>,authObj(<auth object name>, <auth field>, <value>))explains that the first argument of anAccessatom is a user term and the secondargument a term representing an authorization (object).3 SAP R/3 Setup and Business Policies in DetailWe use the SAP terminology throughout our work in order to describe therelevant aspects of the SAP R/3 system. The definition of terms adopted fromSAP are written in SAP R/3 authorization architecture is a complexstructure and consists of several components interacting with each other. Thekey data structure is anauthorization, an instance of anauthorization object,that is eventually assigned via aprofileto a user and typically grants the accessto one particular action inside SAP R/3.

10 In order to align Authorizations withprocess steps, they are grouped detail, an authorization object is a named entity that holds one or morenamed authorization fields, similar to a class structure of aprogramming lan-guage. Together with appropriate field values, the authorization object consti-tutes the authorization . An authorization is therefore an instance of an autho-rization object, similar to the instance of a programming language class. Therelation is shown in Fig. aresingleandcomposite rolesfor the grouping of Authorizations avail-able. A single role groups Authorizations whereas composite roles serve as con-tainers for single roles. Single roles have a name and a list of Authorizations . Forexample, Fig. 3 shows the structure of single role with nameZBANFWRKINFEDby means of the concrete authorizationSTCODE with a fieldTCDand the valueME51N. The overall roleZBANFWRKINFED contains all Authorizations requiredto create Auth.