Downloaded 32 times
6 7-users-authorization
- 1. Users & Authorization Users must be setup and roles assigned to user master records before you can use the SAP System. A user can only log on to the system if he or she has a user master record. A user menu and authorizations are also assigned to the user master record via one or more roles.
- 2. Users in theR/3 Environment Present. Operating System OS User Server R/3 User Application Operating System OS User Server Dispatcher D B V ... Admin. User Database Server Database Operating System OS User Server DB User
- 3. The User MasterRecord All user data required for R/3 System access is stored in the user master record in eight categories
- 5.
- 6. Authorization Concept User master record User master record Profile Profile Authorization Authorization for Task A for Task B Action Action Transaction permitted? Authorizations assigned? Objects needing protection Vendor Material Company code Plant
- 7. Authorization Check SAP GUI Dynpro Authority User Check Context OK? No Message Yes Processing
- 8. Authorization Customer company code: Authorization object Authorization A Object class Object: Customer 0001-0009 company code Financial display, change Company Code Accounting Activity Customer company code: Authorization B * display
- 9. Object Fields Value Meaning User Master 01 Create ACTIVITY Maintenance: 02 Change Authorizations 03 Display (S_USER_AUT) 06 Delete 07 Activate 08 Display change documents 22 Assign authorization profiles 24 Archive AUTH Limited name space for the assignment of authorization names OBJECT Authorization objects
- 11. Central User Administration Withcentral user administration, the creation and maintenance of all user master data is performed in a single R/3 System Client 100 QAS System Client 200 Client 100 Client 200 Client 300 PRD System DEV System Client 100
- 12.
Editor's Notes
- #3 This unit focuses on the R/3 user within the R/3 System. However, it is important for the R/3 System administrator to control access to both the operating system (OS) where the R/3 Systems reside and the database (DB). External user IDs exist both at the OS and DB levels that can be used to disrupt normal operation of the R/3 System. Access to the R/3 System is controlled at the client level. Each R/3 user must have a user master record in the client in which that user will work. In R/3, authorizations are used to restrict access to programs and data. This unit focuses on: The creation of user master records Authorization profiles Controlling access to transactions and data in the R/3 System
- #4 To create and maintain user master records, use transaction SU01 . For each user, the user master record contains all data and settings required for client access for the user. This data is arranged with tabs and includes the following: Address : basic user information such as name, physical location, and telephone number Login date : password information as well as the validity period for the record Defaults : defined default values for start menu, date format, printers, and so on Parameters : defined default values (PIDs) for R/3 fields such as company code 001 Systems : central user administration system information Activity Groups : defined activity groups (with validity period) associated with user Profiles : all profiles assigned to user master record, including standard profiles and profiles generated by the profile generator Groups : all user groups associated with the user master record Tab Systems only appears if central user administration is activated. Current status and change history can be displayed for the current record. To access a detailed change history outlining all change to the user master record, use transaction SUIM .
- #7 In R/3, for each user who requires access in a client, the authorization administrator creates a user master record for that user in that client. The user master record includes one-to-many (1-n) profiles containing all the authorizations needed by the user to perform tasks in the specified client. An authorization provides the permission(s) required to access certain transactions, reports, or data. For each user activity or transaction, an authorization check is performed to see if the required authorizations have been assigned to that user. Authorizations limit access to transactions and objects in the R/3 System that need protection, for example, a company code or vendor. The R/3 authorization concept enables authorizations to be assigned at the transaction level. If a user who is not authorized to perform a certain task attempts to run the corresponding transaction, R/3 sends a message denying access to that transaction. Authorization checks are performed at various points during the execution of a transaction or report to verify that the user has the required authorization(s) for the objects requested. For example, R/3 may check if the user is authorized to access data for company code 001.
- #8 When a user logs on to the R/3 System, all authorizations in the profiles assigned to the corresponding user master record are loaded into the user buffer for the application server to which the user is connected. Once the dispatcher assigns the user request to an available dialog work process, the relevant program is loaded and the user context is checked to see if the user has the necessary authorizations. The user context contains the user authorizations. These are checked against the authorization objects called in the authority check specified in the ABAP code. The user authorizations are checked using OR logic to determine if an exact match exists. If the required authorization exists the user is allowed to proceed and processing continues. If none of the authorizations contain the required combination of field values, a message is sent denying the user access to that object. Once the dialog step has been completed, the user context for the user is rolled out of the dialog process and the process is free to work for another user. The user context remains in the user buffer and is available for use during the next dialog step. To adjust or cancel authorization checks either globally or for individual transactions, the authorization administrator must use transaction SU24 . Checks can be adjusted, for example, if detailed authorization checks are not needed in certain transactions. To adjust or cancel checks, set profile parameter auth/no_check_in _some_cases to value Y (this is the system default value in Release 4.6).
- #9 5 5 To maintain authorizations, run transaction SU03. The initial screen lists various object classifications. An object class is a logical grouping of authorization objects that share a similar purpose or business area. For example, object class Basis: Administration contains authorization objects that control access to Basis transactions. The authorization object is the template from which the authorization is created. It is used in the ABAP code for authorization checks. Each object has up to 10 fields that are checked using AND logic before access is granted to the desired transaction. The authorization administrator creates authorizations from the authorization object. The authorizations contain the field values (permissions) for each field contained in the object. Field values control access to the business area or data addressed by the transaction. To create or change an authorization, enter or change the relevant values in the fields of the authorization. All authorizations are positive, in that they grant permissions to the user.
- #10 The graphic lists the authorization objects that are checked when working with the Profile Generator and when maintaining users: S_USER_AUT (create and change authorizations, enter authorizations in profiles, ...)
- #12 31 Managing users across the system landscape can become a complex task. Central User Administration enables you to maintain user master records in a central repository and easily access: An overview of all users Existing user groups Systems defined within the system group Activity groups Central User Administration allows you to maintain user master records within a single client on the central system and distribute this information to all systems in your landscape. In this context, the central system is defined as an R/3 System that keeps and controls user master data for the entire system landscape. Reasons for using Central User Administration include: The system landscape is complex, with several clients in different systems The same user works in more than one system The same user ID should represent the same individual in all systems An enormous effort is otherwise required to synchronize user data in all systems To access Central User Administration, use transaction SCUM . For more information on Central User Administration, take SAP Basis Class BC305 Advanced Administration.
- #13 The information system provides a basis for conducting detailed analysis of user master records, profiles, authorizations, and activity groups. To access the information system, use transaction SUIM . The information system report tree enables you to access the standard delivered SAP user analysis reports. You can search in these reports using complex search criteria that provide detailed information on: Users Profiles Authorization objects Authorizations Transactions User master record comparisons Change documents To identify pre-delivered reports from SAP for Users and User Administration, call transaction SE38 . Enter RSUSR* in the program field and select the down arrow. This provides a listing of the user reports. To obtain detailed information on a report, select the report and view the documentation written by the developer.