authourity checking

Upload: prasad-raju

Post on 10-Apr-2018

219 views

Category:

Documents


0 download

TRANSCRIPT

  • 8/8/2019 Authourity Checking

    1/18

    A programmer wants to make an authorization check before bookings for business

    customers can be changed.

    To do this, the programmer should create authorization fields(ACTVT and CUSTTYPE)

    and assign for each field defined the value to be checked (02, B). Authorization fields

    are created underTools ABAPWorkbenchDevelopmentOthertools Authorization objects Fields (transaction SU20).

    Programmers should also create an authorization object (here S_TRVL_BKS) andassign

    the authorization object to an object class.

    Authorization fields are created

    underTools ABAPWorkbench DevelopmentOther tools Authorization

    objects Objects (transaction SU21). Authorization objects can also be created in theObject Navigator (transaction SE80).

    You program the authorization check using the ABAP statementAUTHORITY-CHECK.

    AUTHORITY-CHECK OBJECT 'S_TRVL_BKS'

    ID 'ACTVT' FIELD '02'

    ID 'CUSTTYPE' FIELD 'B'.

    IF SY-SUBRC 0.

    MESSAGE E...

    ENDIF.

    TheAUTHORITY-CHECKchecks whether a user has the appropriate authorization to

    execute a particular activity.

    When this happens, the system checks the authorization profiles in the users masterrecord for the appropriate authorization object (S_TRVL_BKS). If the authorization is

    found and it contains the correct values, the check is successful.

    The system administrator has defined the following authorizations for the authorization

    object S_TRVL_BKS:

    S_TRVL_CUS1 with the following values:

    * for customer type ( CUSTTYPE field) and

    03 for activity (field:ACTVT).Users with this authorization can display all customer bookings (activity 03 = display).

    S_TRVL_CUS2 with the following values:

    B for customer type ( CUSTTYPE) and

    02 for activity (ACTVT).

    Users with this authorization can change all business customers (activity 02 = change).

    http://help.sap.com/saphelp_nw04/helpdata/en/52/67168c439b11d1896f0000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/52/67168c439b11d1896f0000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/52/6716a6439b11d1896f0000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/52/6716a6439b11d1896f0000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/52/6716a6439b11d1896f0000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/52/6716a6439b11d1896f0000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/52/67168c439b11d1896f0000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/52/6716a6439b11d1896f0000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/52/6716a6439b11d1896f0000e8322d00/content.htmhttp://help.sap.com/saphelp_nw04/helpdata/en/52/6716a6439b11d1896f0000e8322d00/content.htm
  • 8/8/2019 Authourity Checking

    2/18

    When assigning profiles, the system administrator gave different authorizations to

    different users.

    User Miller has been assigned a profile containing both of these authorizations(S_TRVL_CUS1 andS_TRVL_CUS2). Miller can therefore change bookings for

    business customers.

    User Meyers on the other hand, is only authorized to display the records

    (S_TRVL_CUS1) and therefore cannot change bookings.

    Authorization groups

    The access protectionsystemmust ensure that only authorized individuals have access to the systemand to

    particular data. For achieving precise application security concerning authorization and to protect confidential

    data against unauthorized access it is very important to focus on the use of authorization groups.

    The table that contains all authorization objects is TOBJ.

    The table that contains all activities is TACT.

    The table that contains definition of all authorization groups is TBRG.

    TBRG -- Contains all authorization groups and gives information about relation between authorization object and

    authorization group. The description of the authorization groups is defined in table TBRGT.

    The field name for authorization group -- BRGRU -- is used to make additional restrictions on authorizations /e.g.

    for document maintenance/. In authorization objects and authorization checks, there are fields which are checked

    to verify user authorizations. Customizing objects are combined in authorization groups, and the authorization

    group is one of the two authorization fields, for example, in authorization object S_TABU_DIS which is in the

    object class BC_A (Basis - Administration). This object is for displaying or maintaining tables. It controls access

    using the standard table maintenance tool (transaction SM31), enhanced table maintenance (SM30) or the Data

    Browser (SE16), including access in Customizing.

    Authorization object S_TABU_DIS has the following fields: DICBERCLS - Authorization group, maximum field

    length is four characters; and ACTVT - Activity (02: Add, change or delete table entries, 03: Only display table

    contents).

    Generally, SAP standard tables are assigned to authorization groups. Theseassignments can be changed. You can

    then assign tables manually to a suitable authorization group. To do this, start Transaction SM30 for maintenance

    view V_DDAT, and create an entry for each of these tables. In V_DDAT is stored the assignment of Tables/Views

    to Authorization Groups. V_DDAT is cross-client; therefore, it can be viewed and used in all clients.

    http://www.abapcode.info/search/label/Authorizationhttp://www.abapcode.info/search/label/Authorizationhttp://www.abapcode.info/search/label/Authorizationhttp://www.abapcode.info/search/label/Authorizationhttp://www.abapcode.info/search/label/Authorizationhttp://www.abapcode.info/search/label/Authorizationhttp://www.abapcode.info/search/label/Authorization
  • 8/8/2019 Authourity Checking

    3/18

    Note: If you don't make a selection, all tables maintained in Customizing transactions are assigned to

    authorization groups

    From www.sapnet.ru:Credentials in ABAP programs.

    The system of separation of powers in the R / 3 system based on the use of office facilities, which constitute the definition of a structure consist ing of

    simple fields. Object-based reference for you create your own powers, which are collections of specific values for the fields of objects of reference.Example. Object reference F_KNA1_GRP debtors - the authority to account group" consists of two fields:

    - KTOKD - Group Accounts

    - ACTVT - Operation

    For this object reference can be created by the authority

    {Group = Accounts 0004 (branches); Operation = * (all operations)}And this power is assigned to the user.

    In ABAP programs verification of powers made by the operator

    authority-check object

    id {field | dummy}

    id {field | dummy}....

    In the statement lists all the object's field office and provides value for testing, or used the keyword dummy if the value of a particular field we are

    currently not interested.

    Example. In the transaction view of the debtor, we produce first test:authority-check object 'F_KNA1_GRP'

    id 'KTOKD' field '0004 '

    id 'ACTVT' dummy.

    Then, when the user wants to switch to edit mode, perform a more detailed check:

    authority-check object 'F_KNA1_GRP'id 'KTOKD' field '0004 '

    id 'ACTVT' field '02 '.

    All the objects of reference are separated by grade, reflecting their functional purpose. View objects and their authority structures - the transaction SU21.

    When should you use in your programs with authorization, it is best to use ready-reference objects, but objects are not always ready available and they

    have to create.

    For example, try to create an authority that will verify the user's authority to operate on a particular creditor (such a system does not).

    Must first define the field, that will constitute the object. To do this, use transaction SU20. Our facility office will consist of two fields - the code of the

    lender, and operation.

    Initial screen of Transaction SU20:

    http://www.sapnet.ru/http://www.sapnet.ru/
  • 8/8/2019 Authourity Checking

    4/18

    To create your own objects using the Create button.

    All created objects are called on Z. For the generated input field data element (often already existing and defining the essence of the field, in our case -

    Lender), and a table to check the value (in our case, LFA1)

  • 8/8/2019 Authourity Checking

    5/18

    Save the box.

    Second field - "Operation" - use the ready, it is already in the system:

  • 8/8/2019 Authourity Checking

    6/18

    Proceed to create an object reference.Transaction SU21.

  • 8/8/2019 Authourity Checking

    7/18

    "Fallthrough" in a class of objects, the relevant functional area corresponding to the created object

    reference.In our case, this FI.

  • 8/8/2019 Authourity Checking

    8/18

    Create a new object using the Create button.Enter the name of the object and the first field.

  • 8/8/2019 Authourity Checking

    9/18

    Once we introduce a second field - ACTVT - you will see a new button - "Permissible operations."ACTVT field

    office has a special meaning in the system, and after adding the object will need to enter a valid operationfor this object.

  • 8/8/2019 Authourity Checking

    10/18

    On the button "Available Operations" go to the management of values for field ACTVT.Pre prompted to savethe object.

  • 8/8/2019 Authourity Checking

    11/18

    In our case, mark the "Change" and "View", and keep a list of values.Further, the exit of an object reference, because it has already been saved.

    Feature of this transaction - we just do not see we created an object in the list. Needed to complete the transaction, then re-start it - the newly created

    object will appear and you can view and modify if necessary.

    It should also introduce the documentation to an object reference.In order to have superusers, with the authority SAP_ALL also appeared all the powers at your facility, you need to regenerate the profile of reference

    (the button on the toolbar).

    After all this, the program is already possible to check on the powers created by the object:

  • 8/8/2019 Authourity Checking

    12/18

    In order to create your program in the future be included in the user role and bring up the powers should be as follows:- Create a program based on your transaction, if it does not (Tr. SE93)

    - Edit for the transaction list of the objects of reference as follows:

    Start transaction SU24 (performed in the adjust mandante!). Enter the code of your transaction:

  • 8/8/2019 Authourity Checking

    13/18

    The following screen:

  • 8/8/2019 Authourity Checking

    14/18

  • 8/8/2019 Authourity Checking

    15/18

    Add your facility (click Paste). ID verification (green daw) set in the column of PP, as shown:

  • 8/8/2019 Authourity Checking

    16/18

    Save the data. Now for the object reference must be entered value is checked fields (if that makes sense). In our case, it would make sense if we develop

    a transaction changes the lender and therefore for the field ACTVT in this transaction in any case be required to value '02 '.

    Must be entered on the object reference and click on "Change the values of the fields."

  • 8/8/2019 Authourity Checking

    17/18

    A value changes by clicking on the icon "pencil".

    Values of fields that are not known, for example ZLIFNR, leave blank.

    Save the data. This setting is independent of mandanta, so within a single SAP system to carry anything anywhere is not necessary.

    After this, when you turn on the transaction ZTEST01 a user role, in the corresponding profile of reference will be added to the power of ACTVT = '02 'and

    undefined field ZLIFNR (its value is defined as, for example an interval or a value'*').

    How to Create and Use the Authorization Objects in ABAP

    Published by rson.

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

    We could always create our own authorization objects and implement it in our own abap programs. As an example, we will create our own

    authorization field similar to TCD used in S_TCODE Authorization object

    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.

    Steps to create authorization class1. Go to transaction code SU212. 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 object1. 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 isthe 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.

  • 8/8/2019 Authourity Checking

    18/18

    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

    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.

    Now let's implement this authorization in our ABAP program. Let say we have a dialog program (ZCOMM) wherein we have a button on the

    screen that when clicked, the user will go to the Create / Edit screen (1000) if he's authorized. On the other hand, he will go to display only

    screen (2000) if he's not authorized. To do that, simply add the code below on your program.

    Code:

    AUTHORITY-CHECK OBJECT 'Z_TCODE' "authorization object that we've created

    ID 'ACTVT' FIELD '01 '"Activity = 01, authorized to create

    ID 'ZTCODE' FIELD 'ZCOMM'. "Tcodes that we wants to check for authorization

    IF sy-subrc EQ 0.

    CALL SCREEN 1000. "The user is authorized to create

    ELSE.

    CALL SCREEN 2000. "User is not authorized to create (Display only)

    ENDIF.