Monday, 18 March 2013

What is SAP Security?


Providing proper access to business users with respect to their responsibility.
  (OR)
Providing permissions with respect to Roles.

  • Roles are combination of transactions, Reports, Menus…
  • Profiles are associated with Roles.
  • Profiles are combination of authorization objects.

Authorization:
         An authorization enables you to perform a particular activity in the SAP system, based on a set of authorization object field values.

Authorization Object:
        An authorization object groups up to ten authorization fields.

Authorization field:
       Contains the value that you defined. It is connected to the data elements stored with the ABAP Dictionary.

 Object Class:  Group of relevant authorization objects.

 
            BC-A, BC-B, BC-C  => Object Class
      S-TCODE     S-Programs    S-USR-AUTH       =>  Auth.object

 
Auth.  Object => collection of auth. Fields <=10

  • Field values can be maintained under authorizations.
  • Organization values are used for segregating users as per company codes, plants or purchasing auth.
  • 150 profiles can be included in one Role.
  • All standard authorization objects are stores in USOBT or USOBX.
                                                                           Text             Data

  • After installation need to fill the customer tables USOBT_C and USOST_C

 
SU22/24         -> Maintain authorization objects for T-codes

SU21               -> Maintain object class

SU20               -> Maintain auth. Fields

SU02               -> Manually create profiles

SU03               ->  Manually create auth.


 

How to Create and Use the Authorization Objects in ABAP


Authorization Objects are used to manipulate the current user’s privileges for specific data selection and activities from within a program.

Steps to create authorization field

1. Go to transaction code SU20
2. Click the create new button on the application toolbar.
3. Enter “ZTCODE” in the Field Name and “TCODE” in the Data Element, then hit Enter.
4. Click the save button on the system toolbar.

Next step is to create the authorization class(see #1 in figure 1) and authorization object(see #2 in figure 1).

Steps to create authorization class

1. Go to transaction code SU21
2. Click on the Create button’s drop down icon and select “Object Class”.
3. Enter “ZTRN” on the Object Class field.
4. Give it a description and save it.


Steps to create authorization object

1. Again in SU21, in the list of authorization class(folder icon), click the one that we’ve created(ZTRN).
2. Click on the Create buttodrop down, this time selecting “Authorization Object”.
3. Enter “Z_TCODE” on the Object field and give it a description.
4. On the authorization fields section, enter ACTVT and ZTCODE. ACTVT is used to set and limit the activity of the user, while the ZTCODE is the authorization field that we’ve created earlier which is
responsible for holding a list of tcodes.
5. On the Further Authorization Object Settings, click on “Permitted activities” button. Here we will select the specific activities that we want to be available for our authorization object.
6. As an example, we will select 01(Create), 02(Change), and 03(Display).
7. Save and Exit.


Now we’re done creating our own authorization object, let us now use and assign it to a user.

Steps to create a role(see figure 2)

1. Go to transaction code PFCG.
2. Enter “ZAUTHTEST” on Role field and click the “Single Role” button.
3. Now give it a description, click the save button and click the Authorization tab.
4. Click the “Change Authorization Data” button inside the authorization tab.
5. Then click the “Manually” button on the application toolbar and type in the name of the authorization object that we’ve created earlier(”Z_TCODE”) and press enter.
6. Expand all the nodes, double click on the input field of the Activity and select activity 01 and 02.
7. Enter the tcode of our own abap program in ZTCODE field, in our example I used “ZCOMM” .
8. And also don’t forget to add the S_TCODE authorization object and enter ZCOMM on it’s field.
9. Now Click on the Generate button in the application toolbar and press enter on the pop-up screen.
10. press the back button and assign a specific user on the user tab and click User Comparison button.
11. Now create another role by repeating steps 1 to 9 but this time select activity 03 on step 6.
12. Then assign this 2nd role to another user.

SAP Authorization Concept


The basic SAP authorization concept terms are displayed below, before you specify the authorization field values. The colors of the SAP authorization concept modules are the standard colors in the following hierarchy display.


Explanation of terms:
Object class 1. Object classes have an orange background in the hierarchy display.

2. Authorization objects are divided into classes for comprehensibility. An object class corresponds e.g. to an application (Financial accounting, etc.)

3. The SAP authorization concept object classes are under Tools -->  Administration -->  User maintenance --> Authorizations.
Authorization objects 1. Authorization objects have a green background in the hierarchy display.

2. You may need several authorizations to perform an operation in the SAP System. The resulting contexts can be complex. The SAP authorization concept, based on authorization objects, has been realized to provide an understandable and simple procedure. Several system elements which are to be protected form an authorization object.

3. An authorization object allows complex tests of an Authorization for multiple conditions. Authorizations allow users to execute actions within the system. An authorization object groups up to ten fields that related by AND.

4. For an authorization check to be successful, all field values of the authorization object must be maintained in the user master.

5. You get the authorization object documentation by double-click on an authorization object. The documentation describes how you maintain the authorization values.
Authorizations Authorizations have a yellow background in the hierarchy display.
Authorization fields are light blue and their values are white.

An authorization enables you to perform a particular activity in the SAP System, based on a set of authorization object field values.

The programmer of a function decides whether, where and how authorizations are to be checked. The program determines whether the user is authorized to perform an activity by comparing the specified authorization object field values in the program with the authorization values in the user master record.

T_9092029701 is an authorization for the authorization object F_KNA1_BUK with the following values:
*           for company code and
01,02     activity

Use of an authorization
: Specifies permissible authorization object field values.

Contents:
One or more values for each field.
Authorizations allow you to specify any number of values or value ranges for a field. You can also allow all values, or allow an empty field as a permissible value.

Changes:
All users with this authorization in their authorization profile are affected.
You can maintain authorizations manually with reference to the authorization object documentation or by double-click on a value field. You can select individual field values or choose Full Authorization.
Profile User authorizations are not usually assigned directly to user master records, but grouped together in authorization profiles.

Authorizations can be collected in authorization profiles to reduce the maintenance effort which would be required to enter individual authorizations in the user master record. Access authorization changes affect all users with the profile in their master record.

You can create profiles manually, but you should use the Profile generator.

Use:
Specifies authorizations in user master records

Contents:
Specific access rights, identified by an object name and a corresponding authorization name.

Changes only take effect when the user next logs on. Users who are logged on when the change takes place are not affected in their current session.

In the example, T_58000097 is an authorization profile containing company code authorizations.
User Master Record These enable the user to log onto the SAP System and allow access to the functions and objects in it within the limits of the specified authorization profiles.

Changes only take effect when the user next logs on. Users who are logged on when the change takes place are not affected in their current session.

In the example a user whose user master record contains the profile T_58000097 can perform the activities in the profile authorizations. 

Saturday, 16 March 2013

Performing Authorization Traces in 4.6 Using ST01



Preliminary Steps

                Before starting this process it is important to make sure that you and the user are logged onto the same system.  In a logon load balanced environment it may be possible that you and the user may be on different application servers. Due to the buffers within SAP it is best to run on the same system to perform the trace.

           Steps to align your logon application server to the user:

1.    Execute transaction AL08 - List of all logged on users
2.    This will produce a list of all users logged on to all systems. 
3.    List of all logged on users. To find the user, do the following:
4.    From the menu select System > List > Find

         

5.    Once found then identify the application server (active instance) that the user is logged into.

           Switch to users application server

1.    Run transaction SM51 – List of SAP Servers.


2.    Select the correct instance by selecting it (clicking once).
3.    Select menu item Goto, then Remote logon:


4.    You will immediately be logged onto the requested instance.
5.    Now you can begin the trace process.

How to Run System Trace
                The trace should be done in the Integration/Test environment.  If you are tracing a CPIC or Batch user id, then the id should have been assigned SAP_ALL and SAP_NEW prior to running the trace. This is to allow the user to run the job without any authorization check failure.
Running the trace transaction (ST01) will impact system performance. Use it sparingly and be sure to stop the trace when finished.
Follow the step-by-step instruction below to execute system trace.

           Setting Up Trace Parameters
1.    Go to transaction ST01.
2.    Put a check next to the Authorization check item:      


3.    Go to the Edit menu item, and select Write Options:



4.  Check the Write to disk option, then hit the back button:


4.  Next, go to the Edit menu item again, and then Filter, Shared:

    

5.  Enter in the ID that you want to trace, then the Back button.
This is important, because if the trace is not restricted, then all users in the instance will be traced which will cause performance issues.


               
           Performing the Trace

1.    You are now ready to begin the trace.  Have the users tell you when they are ready to begin.  When they are ready, press the Trace On button:



2.  When the user is finished, hit the Trace Off button.

3.  To view the results, click on the File list button.

4.  Double click on the trace file on the first line:



5.  Next, select the Trace for authorization checks checkbox, then hit the Analyze button.  This will reveal each authorization call as shown on Page 9.



 Interpreting the Trace Results
1.    Authorization objects are labeled "AUT" followed by a return code.
2.    Return code "0" means that the authorization check was successful.
3.    Return code "1" means that the authorization check failed.


In order to better analyze the data from the trace, downloading it to an external file is very useful.  To can do this from the trace report screen, go to System > List > Save > Local File

SU24 Concept



•Transaction SU24 maintains the USOBT_C and USOBX_C tables. These tables hold the relationships between the particular transaction and its authorization objects. It is possible to add or subtract the checks performed in the transaction by changing the appropriate flag.
•The benefit of transaction SU24 occurs when transactions are added to or deleted from Role Groups using the Profile Generator.
•When new transactions are added, the Profile Generator will add all authorization values maintained in SU24 for the transaction(s).
•When deleting transaction the Profile Generator will remove all authorization values that are maintained in SU24 for the transaction.
•Activities performed:
•Check/Maintain Authorization Values
•Addition of Authorization Object to tcode
•Deletion of Authorization Object from tcode
Check Ind.
Proposal
Meaning
Explanation
Check
YS
Check /Maintained
The object will be inserted along with the values in the role.  The object will be checked along with the values during runtime of the transaction.
Check
NO
Check
This object will not be inserted into the roles.  A check on the object along with the values will be done during the runtime of the transaction
Do not Check
NO
Do Not Check
The object will not be inserted into the roles and there will not be any check performed
during runtime of the transaction
Status Texts for authorizations
Standard: All field values in the subordinate levels of the hierarchy are unchanged from the SAP defaults
Maintained: At least one field in the subordinate levels of the hierarchy was empty by default and has since been filled with a value
Changed: The proposed value for at least one field in the subordinate levels of the hierarchy has been changed from the SAP default value.
Manual: You maintained at least one authorization in the subordinate hierarchy levels manually (it was not proposed by the Profile Generator).
Effect of SU24 changes in Role Groups
•Authorization objects are maintained in SU24 for a particular transaction code. When a transaction code is added to role, only the authorization objects having check as check indicator value and yes as proposal value, maintained for that tcode will be added into the role group.
1)  Adding Tcodes to a role
When a new Tcode is added to a role
•When a new tcode is added to a role, going in either change authorization data or expert mode provides the same result. All the authorizations maintained for the tcode at SU24 level is added to the role.
•The program adds new standard authorizations for  objects in the roles If the authorization default values contain objects that were previously not existing
Or only had authorizations in the status Changed or Manual
•A new standard authorization is not included
if the authorization fields contain identical authorizations in the status Standard in both authorizations, and the fields maintained in the old authorizations are empty in the new standard authorization.
If there were already authorizations in the status Maintained (active or inactive) or Inactive Standard before the merge, the program compares the values and the maintenance status of all authorization fields to determine whether new standard authorizations must be extended.
Changing SU24 values for a tcode
If the authorization data is changed for any tcode in SU24 and tcode is already present in the role, then going in the expert mode with option “read old data and compare with new data” will only reflect the additional changes. Change authorization data will not pull the new data for the tcode maintained at SU24 level
2) Removing Tcodes from the role
When you remove transactions from the role menu, this has the following effect on the authorizations.
•A standard authorization for which the associated transaction was removed from the role menu is removed during the merge, unless at least one other transaction that remains in the menu uses the same authorization default value. This applies both for active and inactive standard authorizations.
•Authorizations in the statuses Changed and Manual are not affected by the merge. They are therefore always retained.


When to use SU24?

 

To correct authorization objects that are not linked to transaction codes correctly

·     To correct authorization objects that have unacceptable default values.
·     To change default values to ones that will always be appropriate for all roles that will ever use the transaction. This means having blank fields where you need to allow different roles to have different values.