Reference http://sap.iteye.com/blog/156757
When initiating a transaction, a system program performs a series of checks to ensure the user is authorized.
1. The program checks whether the transaction code exists in table TSTC.
2. The program checks whether the transaction code is locked by the administrator (transaction code SM01).
3. The program checks whether the user has the authority to start the transaction. Authorization object S_TCODE (transaction start) contains the authorization field TCD (transaction code). The user must have the appropriate authorization for the transaction code to be started (for example, FK01, Create Vendor).
4. The program checks whether an authorization object is assigned to the transaction code. If this is the case, the program checks whether the user has an authorization for this authorization object. The transaction code/authorization object assignment is stored in table TSTCA.
Note: An SAP program controls steps 1 through 4. It displays an automatic message to the user if an authorization attempt fails in the step.
5. The system performs authorization checks in the ABAP program using the ABAP statement AUTHORITY-CHECK.
There are several ways to get all the required authorization objects associated to a transaction code. But it is not necessary to do so normally because SAP maintained this relationship internally. If you add the TCODE in one role, all the required authorization objects will be pulled to the profile automatically and you can assign or change the values for each authorization field.
1. TCODE: ST01- trace the authorization
2. TCODE: SU24 – Maintain the Assignment of Authorization Objects
3. From the table USOBT(Relation transaction > authorization object) table TSTCA(Values for transaction code authorizations)
Custom TCODE & custom authorization object
If we develop some add-on programs and assign them some custom TCODE. There are authorization checks in the programs. We definitely can add these authorization check manually into the profile, but it will take much time and fallible. The security team might miss some custom authorization objects when building the roles.
It will be a good manner to maintain the relationship between custom TCODE and custom authorization object. When security team build the roles, he/she can simply add the custom TCODE to the role, the required authorization objects will be derived into the profile automatically.
How to…?
Go to TCODE SU24 – Maintain the Assignment of Authorization Objects.
Enter the custom TCODE name and execute the program. In the next screen, add the custom authorization objects to this TCODE.
SAP Firefighter is the old name of Super Privilege Management which is a component of SAP GRC Access Control. It provides user the capability to take responsibility for tasks outside their normal job function. A temporary ID is assigned that grants the user privileged, yet regulated, access. This transfer of privileges from one person or role to another is called firefighting. Such a firefighting event might occur, for example, if an employee is injured and another employee has to perform the injured employee’s duties.
Transaction code for this tool is /VIRSA/VFAT.
Technically, this tool will create/update the RFC destination by program and logon to the Firefighter ID using function module ‘SYSTEM_REMOTE_LOGIN’ by RFC.
call function 'SYSTEM_REMOTE_LOGIN'
exporting
* SYSTEM = ISYSID
* HOST = IHOST
* SERVICE = ISERVICE
destination = idest
importing
error_message = emsg
exceptions
cannot_start = 1
others = 2. Read more…
We need to create the RFC communication user when one SAP system wants to communicate with another SAP system or an external system needs to access the SAP system. These users might be granted SAP_ALL and SAP_NEW profiles. But this method has the potential security issue. This user account can be abused for some other purpose in the production system and doesn’t adhere to the company security policy.
This post will help to guide our audience how to build the minimized role for the RFC communication user.
Read more…
Roles are collections of activities which allow a user to use one or more business scenarios of an organization. The integrity of business data is also ensured by the assignment of roles. SAP application server contains two stacks. One is ABAP and the other one is Java. The two stacks have different role management concepts. Therefore, there are three types of role management in SAP.
- ABAP Authorization Roles
- J2EE / UME Authorization Roles
- Portal Roles
Below landscape shows how these roles locate in different SAP systems.
Read more…
SAP offers a broad range of security mechanisms and services to meet the highest demands for data integrity, protection, and confidentiality – and to support authentication, authorization, and secure information exchange.
From below illustration, there are three types of securities: network security, application security and physical security. SAP covers the first two security topics and part of the third one. The last one will partially rely on data center.
Read more…