Authorization check at diff levels

I need this functionality:
several authorization checks should be implemented.
· Selection on Plant level (authorized yes or no is then taken care within the authorization role)
· When this was successful, check further whether User is authorized for Change, or only for Display mode. When User is only authorized for Display mode, the different buttons e.g. Approve Cancel are not visible at all or great out. (this is as well then on user level maintained via authorization role)
How should we do this using ABAP?
Regards

Check with below link :
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/a92195a9-0b01-0010-909c-f330ea4a585c
Thanks
Seshu

Similar Messages

LDB PNP authorization check at record level - rp_provide_from_last

hi,
i am using LDB PNP,
I am using macro 'rp-provide-from-last' .
I neeed to place a authorization check so that the user of the program should only be allowed to view records of the people which comes under the same personnel area as of the user of the program.
Can you please guide me on how to implement this?
thanks in advance,
akash.

Hi,
(1)
Actually, if you're wirting report with PNP LDB, you do NOT need to do this hard-coded auth checking at all. Because the LDB abap code behind PNP has already do this job for you.
So all you need to do is to ask you HR consultant or Basis consultant to modify the authority config of certain ROLE with t-code PFCG, and then assign that ROLE to certain user with t-code SU01.
ABAP code behind PNP will automatically verify the current user according to his ROLE setting.
(2)
In some case you do not work with LDB report, then you need to do the authority check by yourself. General function AUTHORITY_CHECK is what you need. AUTHORITY_CHECK do the authority check by means of Authority Object.Belows are authority objects used in HR module(you can also see in PFCG if technial name switched on):
P_ORGIN    HR: Master Data
PLOG       Personnel Planning
P_PCLX     HR: Clusters
P_TCODE    HR: Transaction codes
Sample of checking personal area:
CALL FUNCTION 'AUTHORITY_CHECK'
     EXPORTING
          FIELD1              = ' PERSA'
          OBJECT              = 'P_ORGIN'
          USER                = 'SAPSUPPORT1'
          VALUE1              = 'Z001'
     EXCEPTIONS
          USER_DONT_EXIST     = 1
          USER_IS_AUTHORIZED = 2
          USER_NOT_AUTHORIZED = 3
          USER_IS_LOCKED      = 4
          OTHERS              = 5.
IF SY-SUBRC NE 2.
MESSAGE E001(01) RAISING AUTH_FAILED.
ENDIF.
Reward if helpful pls!

Authorization Check on Multiprovider level

hi,
We have following requirement.
1. we have two groups accessing the same reports (A and B).
2. When user from A view the report, he should only see the data from A. Similar for B, he should only see data from B.
3. We also provide ad-hoc query creation in production through Query Designer.
We thought of creating authorization relevant object and include it in query. But the problem is, if they dont include the authorization object in the query, then data will not be filtered and we will get data security issue. We dont have any problem with Canned queries (deliverd by developers). but while creating ad-hoc query, they might remove the authorization relevant field. Hence, this type of authorization may not work for us.
Option 2:
1. While loading the data split the data and load into seperate cubes. That is Cube-A and Cube-B.
2. Apply info provider level security to Cube-A and Cube-B (based on PFCG security roles)
3. Create a multiprovider on top of Cube-A and Cube-B
4. Expose this mutliprovider for ad-hoc and other quries.
But i am not sure about following things.
1. Lets say A tries to access the report created on this multiprovider.
2. As the multiprovider splits the query to Cube-A and Cube-B, will he gets authorization failed error on Cube-B? Or whether multiprovider just ignores data from Cube-B and shows only Cube-A data?
3. Or, will it ignore the authorization at Cube-B and shows all the data?
4. if this model works from authorization perspective, what are the drawbacks we have with this approach.
Please let me know your thoughts on this design and also suggest if you have any other solution.
regards
Raghavendra

Hi,
If the user is restricted to an infoprovider in the role then it works perfectly with out any security leak.If the user tries to acess any other infoprovider then authorisation chk works and throws an error message "No authorisation".
As we do not have control at the query designer level to restrict the user by an authorisation variable(considering adhoc queries) better to restrict the user with infoprovider restriction at role level.
1. Lets say A tries to access the report created on this multiprovider.
User A will be able to view the data from the infoprovider A only.
2. As the multiprovider splits the query to Cube-A and Cube-B, will he gets authorization failed error on Cube-B? Or whether multiprovider just ignores data from Cube-B and shows only Cube-A data?
Multiprovider does not know or able to differentiate A and B its just physical stucture formed by the combination of fields from infoprovider A and B. If the user tries to access the fields from Infoprovider B then he will get an authorisation error as he is not authorised to Cube B.
3. Or, will it ignore the authorization at Cube-B and shows all the data?
Authorisation check will happen as per the infoprovider restriction assigned to the user in the role so it does not show the other values.
4. if this model works from authorization perspective, what are the drawbacks we have with this approach.
The user should be well aware of the fields from A and B, if any of the filed is used for which he is not authorised then it gives an error.If the multiprovider has large number of objects then its slightly difficult for the user to remember the fields from which infoprovider to use and not to use.
Also if u have logically split the data into two infoproviders then why do you need multiprovider ? Let A work on A and B on B. So no complexity of multiprovider.
Let me know if i miss anything.
Regards

Direct database data access without data level authorization check

Hello,
My customer raised issue about direct database data access. Due to the customeru2019s strong security policy, it shouldnu2019t be allowed.
To prevent this kind of illegal data access, customer ask me to list up all the possibilities to display data without data level authorization check.
The things in my mind are
SQL Command Editor (for Oracle based system) : ORASPACE, DB02, ST04
Query Based : SQVI (Quick Viewer), SQ01/SQ02/SQ03 (SAP Query)
Data Browser : SE11, SE12, SE16, SE16N, SE17
Table Maintenance : SM30
Function Module : RFC_READ_TABLE
Function Module : DB_EXECUTE_SQL (DML)
Anyone knows anything which is not listed above?
Thanks

HI,
Generally in production user's should not be given all these authorizations.
Ram.

SM30 Field level authorization check

Hi,
I have a requirement to add the authorization check in SM30 for the company field in the custom table. Please suggest.
Thanks,
Gagan Chodhry

Hi,
I have this requirement for both type of tables i.e. custom as well as standard. Tables has got field profit center.. I need to show the table based on the loggedin user authorization to the profit center.
If it is a custom table then as mentioned by Siva, there is a way I heared that we can check the authorization in PAI event, but when I tried to do a small test, I could get the field symbol with the values, but I was not able to skip that record for disply.
If anyone can send the sample or the way to skip the record based on the check.
Also is there any other way to add the field level authorization to custom and standard tables...
Thanks,
Gagan Chodhry

Cost element group authorization check on controlling area level

Hi!
When maintaining cost element groups (KAH1, KAH2, KAH3) is it possible to run an authorization check on controlling area level?
We have one global chart of account but several controlling areas. When we create a cost element group it is created at chart of account level for all the controlling areas. When someone changes a cost element group it changes in all controlling areas. I cannot restrict user's authorization to be able to change cost element groups only in their own controlling area.
Is it possible somehow?
Thanks for your help.

Hi,
Like how the global chart of accounts is at the client level, the cost element groups are also independent of the controlling areas. Infact, the cost element groups are created at the global COA level.
In such a case, I don't think it is possible to restrict the authorizations to amend the cost element groups at controlling area level.
Thanks and Regards,
Bhuvaneswari.S

Selection screen and authorization check for plant from 2 diff tables?

Hi,
Could anyone help me out?
how to write code for this?
u2022   Fields for selection
Plant : WERKS (one selection) - check authorization access u2013 Mandatory .
Material code MATNR (one selection) - Mandatory
and while doing the authorization check how should i check it ? here iam taking the table as t001w for werks and for selection screen iam taking it from another Z table......i should take 2 different tables here.....for selection and for authorization.
my code is pasted below:
                 Data Declarations                                  *
data: s_werks type t001w-werks.
                 Selection Screen                                    *
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE text-h01.
PARAMETER : p_werks like Ztable-werks OBLIGATORY,
              p_matnr like mara-matnr OBLIGATORY.
SELECTION-SCREEN END OF BLOCK b1.
                 Start-of-Selection                                  *
START-OF-SELECTION.
**-Get Plants for Authorization check.
   SELECT werks
          FROM t001w
          INTO TABLE it_werks
      WHERE werks IN s_werks.
    LOOP AT it_werks INTO x_werks.
       v_werks = x_werks.
Regards,
Reddy

Plant : WERKS (one selection)
That means only 1 plant value to be given? Then you can use PARAMETERS instead of SELECT-OPTIONS. And additionally, you'll only have to check that plant value.
Using SELECT-OPTIONS you would indeed retrieve the plants and check each individual selected plant. Your code for that is good enough to start with.
I wouldn't do the check in the START-OF-SELECTION event, but rather in the AT SELECTION_SCREEN event.
To perform an authorisation check; try the ABAP help on AUTHORITY-CHECK. And you will need to know which authorisation object you need to use.
Just noticed you're using PARAMETERS
WHERE werks IN s_werks
should be
WHERE werks eq p_werks
But actually you don't need to select T001W. Just use the value in p_werks.
Edited by: Maen Anachronos on Oct 10, 2008 7:53 PM

Authorization check by Cost centers

Hello all,
I developed a report in Report Painter and the requirement is that the users be able to run it only for their own CCtrs - challenge is that we are trying to not use variants, custom transactions and also modifying / checking authorization at at SU01 level.
Is there any other way to do this and if yes can you pls provide some details.
Thanks,
Richa

hi richa,
Authorizations with Variables
Definition
Instead of using a single value or interval, you can also use variables in authorizations. The Customer Exit is called up for these variables while the authorization check is running. The call is carried out with I_STEP = 0. The intervals of characteristic values or hierarchies for which the user is authorized can be returned here. By doing this, the maintenance load for authorizations and profiles can be reduced significantly.
Every cost center manager should only be allowed to evaluate data for his/her cost center. Within the SAP authorization standard, a role or a profile with the authorization for the InfoObject 0COSTCENTER equal to XXXX (XXXX stands for the particular cost center) would have to be made for every cost center manager X. This then has to be entered in the user master record for the cost center manager.
Using variables reduces the authorization maintenance workload with the InfoObject 0COSTCENTER equal to $VARCOST, as well as with the role or the profile, which is maintained for all cost center managers. The value of the variable VARCOST is then set for runtime during the authorization check by the CUSTOMER-EXIT RSR00001.
Maintaining the authorizations restricts the entries for the values to the length of the existing InfoObject. It is possible, however, to use both limits of the interval. In the example 0COSTCENTER with 4 spaces, the variable VARCOST is, therefore, entered as $VAR COST.
There is a buffer for these variables. If this buffer is switched on, the customer exit is only called up once for a variable with the authorization check. In doing so, you avoid calling up the customer exit for variables over and over, as well as decreasing performance. If you want to call up the customer exit each time, you have to deactivate this buffer in the Setting Up Reporting Authorizations. To do this, go to the main menu and choose Extras ® Compatibility ® Buffer for Variables (Customer-Exit) ® Deactivate..
You can also call up the customer exit for authorizations for hierarchies. There are two ways to do this:
       1.      Enter the variable in the authorization for characteristic 0TCTAUTHH. The customer exit is then called up while the authorization check is running. In the LOW fields of the return table E_T_RANGE, the system anticipates the technical name for the hierarchy authorization that you specified in the authorization maintenance (transaction RSSM).
As a result, all parameters are available for such an authorization. Nevertheless, you must also create a new definition for each node.
       2.      Where many authorizations differ from an authorization for a hierarchy only in respect to the nodes and not to the other authorizations, we suggest the following solution: Different users can be authorized for a specific hierarchy area (subtree). The highest node is different for each user.
Do this by creating an authorization for a hierarchy in the transaction RSSM and enter this in the authorization or role. Instead of specifying a particular node, you specify the variable in the authorization maintenance (transaction RSSM). The customer exit is then called up for the node while the authorization check is running. The return table E_T_RANGE must be filled according to the customer exit documentation (nodes in the LOW field, InfoObject of the node in the HIGH field
Setting Up Reporting Authorizations
Use
Before you are able to set up reporting authorizations, you have to create authorization objects.
As soon as an authorization object is saved, it can be checked when a query is run. The user may not have the appropriate authorizations if he or she has not yet been assigned this authorization object.
Only when the user has been assigned the appropriate authorizations can he/she define and execute a query or navigate in an existing query.
If in the query a characteristic value or a node is excluded, a complete authorization check * is required.
Procedure
Creating an authorization object
       1.      In the SAP Easy Access initial screen of the SAP Business Information Warehouse, choose the path SAP Menu ® Business Explorer ® Authorizations ® Reporting Authorization Objects.
       2.      Choose Authorization Object ® Create. Give the authorization object a technical name and a regular name. Save your entries.
       3.      On the right-hand side of the screen, an overview of all the InfoObjects that are authorization-relevant is displayed.
Only those characteristics that have been flagged as authorization-relevant previously in the InfoObject maintenance screen can be assigned as fields for an authorization object. See also: Creating InfoObjects: Characteristics
       4.      Assign the InfoObject fields to the authorization object:
¡        Select the characteristics for which you want an authorization check of the selection conditions to be carried out.
¡        Select the InfoObject key figure (1KYFNM) if you want to restrict the authorization to a single key figure.
¡        Select the InfoObject (0TCTAUTHH) if you want to check authorizations for a hierarchy.
¡        Include the authorization field activity (ACTVT) in the authorization object if you want to check authorizations for documents.
       5.      Save your entries.
       6.      Go back to the initial screen of the authorization maintenance.
       7.      Choose Check for InfoProviders ® Display to get a list of the InfoProviders that contain the InfoObjects that you selected and are therefore subject to an authorization check (where-used list). In the change mode you can exclude individual InfoProviders from the authorization check for this authorization object by removing the flag.
Authorization object:           S_RSRSAREA
Name:                   Sales area
Fields:                         DIVISION, CUSTGROUP, 1KYFNM
Creating authorizations
Authorizations are created and maintained in the role maintenance screens.
       1.      Choose Authorizations ® Roles ® Change.
       2.      Specify the roles that you want to change and choose Change. This takes you to the role maintenance screen.
       3.      On the Authorizations tabstrip, choose the Expert mode for generating profiles option.
       4.      Choose the Enter Authorization Objects Manually option, and specify the objects that you require. Choose Enter. The authorization object is added to the role.
       5.      Choose Generate.
For more information, see Changing and Assigning Roles.
Result
The user is now able to work with queries
Authorizations to Work with a Query
Use
Authorizations to work with a query are first checked in the dialog box to open a query.
Furthermore, when a query is opened, the authorizations for the individual objects are checked.
See also: Authorization Check When Executing a Query..
Structure
Check in the Open Dialog Box:
When you open a query, you will see four buttons in the dialog box. The History, Favorites and Roles buttons only display your own queries and those queries intended for you per role definition.
The InfoAreas button enables you to look at all queries for which the user has display authorization. If this display authorization is not restricted to queries, the user will see all available queries in the system here. It is possible to hide the InfoAreas button if you do not want the user to see all queries in the system. The authorization object S_RS_FOLD with the field SUP_FOLDER can be used here. In order to hide the InfoArea button, set this field to X when authorizing, otherwise leave the field blank or set it to * (asterisk all authorizations).. The button will be displayed if the authorization check fails.
Authorizations by User
It is also possible to make queries from particular users (= OWNER = query creator) available to other users (= USER) for display or processing. The authorization object S_RS_COMP1 with four fields (COMPID, COMPTYPE, OWNER, ACTVT) is used here.
You can grant this authorization to a particular team or use the variable $USER to give all users the authorization for queries that they created themselves. $USER is replaced by the corresponding user name during the authorization check.
See also the Example for Reporting Authorizations.
Authorizations for the BEx Broadcaster
Using the authorization object S_RS_BCS, you can determine which user is allowed to register broadcasting settings for execution and in which way.
Note:
·        The only authorization necessary for the online execution of broadcasting settings is the authorization for the execution of the underlying reporting objects (for example, the Web template).
·        Every user that has authorization to create background jobs also has authorization for direct scheduling in the background.
·        If you need to work under the name of another user to execute broadcast settings (for example with user-specific precalculations), the authorization object S_BTCH_NAM for background scheduling is also required for the other user. For more information, see Authorizations for Background Processing and Definition of Users for Background Processing
Authorizations for Selection Criteria
Definition
The selection criteria of a query determine which data can be displayed after you have entered it in a workbook.
An authorization check for certain InfoObjects only takes place if an authorization object with this InfoObject was already created in the authorization object class Business Information Warehouse.
As soon as an authorization object is created, only authorized users can select query data.
Use
To decide whether a user should be authorized to work with a query, you should check whether authorization has been given to him/her for all selection criteria.
Essential to the authorization of selection criteria is the authorization object S_RS_ICUBE.
Definitions of authorizations for working with certain InfoCubes must be transported separately.
See: Transporting Additional Information
In general, it is not sufficient to give authorizations for individual InfoObjects (characteristics and key figures), or to check them separately from one another. It more usual that specific authorizations should be given for combinations of characteristics and key figures.
It is therefore feasible that a "Sales Manager" is allowed to view the respective total sales figures for all sales areas, but is only authorized to break down "his/her" area (0001) according to the individual sales personnel. In this case, the following authorizations, which are grouped together, would be created and assigned.
Sales area = *
Sales personnel = :
Key figure = Sales figures
(: represents the authorization to view the values aggregated with the characteristic.
Sales area = 0001
Sales personnel = *
Key figure = Sales figures
The user frequently uses these "multidimensional" authorities in companies that are regional as well as product-oriented (matrix organization). In this way, you could arrange for the person responsible for the combination of a certain division and a certain sales area to have the exact authorization for the output of the relevant values, without him/her necessarily also having access to the data for the whole division or the whole sales area.
Authorizations for the Query Definition
Authorizations can be granted for the following objects for the query definition in the Business Explorer:
The entire query
Structures
Calculated key figures
Restricted key figures
Variables
The activities for the query definition are specified in the authorization object S_RS_COMP (Business Explorer - components). The authorization object has the following fields: InfoArea, InfoCube, component type, component name and activity.
The following values are possible for the component type:
REP: Entire query
STR: Structure
CKF: Calculated key figure
RKF: Restricted key figure
VAR: Variables
By specifying an InfoArea or an InfoCube, you can further restrict the component types. By specifying a component name, you can specify the authorization for individual components in more detail. Components that begin with 0 are delivered by SAP and cannot be changed. Components that are within the customer name range must begin with a letter of the alphabet.
Valid activities are:
01 (create)
02 (change)
03 (display)
06 (delete)
At the moment, activities 16 (Execute) and 22 (Save for Reuse) are not checked for the query definition.
User A is allowed to create, change or delete queries beginning with A1 and A6 within InfoArea 0001 in InfoCube 0002. In addition, the user is allowed to change the calculated key figures and structures (templates) already defined in this InfoProvider.
Related authorizations for user A:
InfoArea: 0001
InfoProvider: 0002
Component type: REP
Component Name: A1, A6
Activity: 01, 02, 06
InfoArea: *
InfoProvider: 0002*
Component type: STR, CKF
Component name: *
Activity: 02
Authorizations for Display Attributes
Definition
Authorization-relevant display attributes are hidden in the query if the user does not have sufficient authorization to view them.
Use
For characteristics:
The user needs to have complete authorization (*) to see the display attribute in the query.
For the characteristic 0EMPLOYEE, the 0EMPLSTATUS attribute is authorization-relevant. Only users with authorization "*" for 0EMPLSTATUS can display the attribute in the query.
For key figures:
Key figures cannot be marked as authorization-relevant. To use this function nonetheless for key figure attributes, the system checks against meta object 1KYFNM. For this, the user requires authorization for the field 1KYFNM in the authorization object.
The key figure attribute 0ANSALARY is contained in the 0EMPLOYEE characteristic.
If the user has the 1KYFNM field in his or her authorization object, and authorization "*", he or she can display all key figure attributes.
If the user has the 1KYFNM field in the authorization object and the 0ANSALARY key figure as a value of the authorization, he or she can only see this key figure attribute. If the user is not supposed to see this attribute, do not give the authorization "*" but only assign the key figures for authorization that are to be displayed.
Authorizations for Navigation Attributes
Use
During authorization checks for navigation attributes, it is always the characteristic that is being used as a navigation attribute that is checked.
Integration
If referencing characteristics are used as navigation attributes, authorization for the basic characteristic is checked. You should, however, change this logic so that the referencing characteristic is checked for instead. In the maintenance screen for reporting authorizations, choose the following path from the main menu Extras ® Compatibility ® Navigation Attributes ® Switch Off.
This function exists for reasons of compatibility. The authorization logic of referencing characteristics worked differently with the beginning of Release BW 2.0. From BW 2.0, Support Package 20 and in all of the releases that follow, for referencing characteristics as well, the authorization for exactly this characteristic (and not the basic characteristic, as was the case previously) is checked.
Example
In the query, you use characteristic A with the navigation attributes A__B and A__R. Characteristic R references characteristic B. For these navigation attributes, authorization for the basic characteristic B is checked. If you switch off the compatibility for navigation attributes option, B is checked for A__B, and R is check for A__R.
Maintaining Authorizations for Hierarchies
Use
Authorizations for hierarchies determine up to which subarea of a hierarchy a user may drilldown.
Prerequisites
Before you can set authorizations for hierarchies, you must first transfer and activate the InfoObject 0TCTAUTHH from the Business Content. Make sure that the indicator Relevant for Authorization is set. You must also create an authorization object for which you want to set the authorization.
Authorization for a hierarchy on the Profit Center characteristic (0PROFIT_CTR):
Define an authorization object with 0PROFIT_CTR and 0TCTAUTHH.
Example: You define a hierarchy for the basic characteristic B. For characteristic B there is a referencing characteristic R. If you use this hierarchy for characteristic R in the query, authorization for the basic characteristic B is checked. However, you can change this logic so that characteristic R is checked for instead. In the maintenance screen for reporting authorizations, choose the following path from the main menu Extras ® Compatibility ® Ref. Characteristics with Hierarchy ® Switch Off.
You need the characteristic 0TCTAUTHH to specify the hierarchy in the authorization. If you add this characteristic to an authorization object, you can specify authorizations for hierarchies for all InfoObjects in the authorization object.
Procedure
       1.      In the SAP Easy Access initial screen of the SAP Business Information Warehouse, choose SAP Menu ® Business Explorer ®Reporting Authorization Objects.
       2.      Choose Authorizations ® Authorization Definition for Hierarchies ® Change.
       3.      In the Definition, select the InfoObject, hierarchy and node.
If there are several users who are authorized to work with just one part of a hierarchy (subtree) but the top node is different for each, you have the option of specifying a variable instead of a node.
See also: Variable Types
Instead of selecting a node, you can also set the Top of hierarchy indicator. This enables you to ensure that a user is authorized to use a hierarchy from the top node down to a determined level.
You can select the top node here. However, if the hierarchy is being used in a query without a filter on this node, the user will not be able to execute the query.
This is because the top-most visible node does not represent the actual top of the hierarchy. As, for example, there are other Remaining Leaves, there should always be exactly one internal node at the top of the hierarchy. Therefore, there is one internal node above the top-most visible node. If the hierarchy is used in a query without the top-most node being determined, it is compared with this unseen, internal node. So that the user has the correct authorizations, select the internal top of the hierarchy for this option.
       4.      Select the authorization type:
¡        0 for the node
¡        1 for a subtree below the node
¡        2 for a subtree below the node up to and including a level (absolute)
You must define a level for this type. A typical example of an absolute level is data protection with regard to the degree of detail of the data (works council ruling: no reports at employee level only at more summarized levels).
¡        3 for the entire hierarchy
¡        4 for a subtree below the node up to and including a level (relative)
You must specify a level that is defined relative to the node for this type. It makes sense to specify a relative distance if an employee may only expand the hierarchy to a certain depth below his or her initial node, but this node moves to another level when the hierarchy is restructured.
       5.      For types 2 and 4 you can specify, in Hierarchy Level, the level to which the user can expand the hierarchy.
¡        With authorization type 2 (up to and including a level, absolute) the level refers to the absolute number of the level in the hierarchy where the top-most node of the hierarchy is level 1.
¡        With authorization type 4 (up to and including a level, relative) the level number refers to the number of levels starting from the selected node itself which is level 1.
       6.      In the Validity Area you specify in exactly which ways a hierarchy authorization has to match a selected display hierarchy for it to be included in the authorization check.
¡        Type 0 (very high) : The name, version and key date of the hierarchy on which the hierarchy authorization is based have to agree with the selected display hierarchy.
¡        Type 1: The name and version of the hierarchy on which the hierarchy authorization is based have to agree with the selected display hierarchy.
¡        Type 2: The name of the hierarchy on which the hierarchy authorization is based has to agree with the display hierarchy.
¡        Type 3 (lowest) : None of the characteristics have to match.
Note that in some circumstances, setting a check level that is too low may lead to more nodes being selected using hierarchy node variables that are filled from authorizations, than actually exist in the display hierarchy for the query. This can cause an error message.
As a general rule, select the highest possible level for the check.
       7.      If you set the Node variable default value indicator, this definition of an authorization for a hierarchy is used as the default value for node variables.
If more than several authorizations are assigned to a user for different subareas of the same hierarchy, one of these authorizations has to be defined as the default value. Only one node can be selected for a node variable on the variable screen of a query. So that this variable can be filled from the authorizations, the correct variable type has to be selected and an authorization has to be determined as the default value.
       8.      Specify a technical name for this definition. If you do not enter a value, a unique ID is set.
       9.      Now create an authorization for the new authorization object. To do this, enter the technical name of the definition as a characteristic value for the characteristic 0TCTAUTHH. Hierarchy authorizations and authorizations for characteristic values are added:
¡        Specify the value (a blank character) as a characteristic value if only hierarchy authorizations are to be in effect. If you specify more values these are authorized additionally.
¡        Specify the value : (a colon) when queries are also allowed without this characteristic.
The value ' (all characteristic values) is not supported for the characteristic 0TCTAUTHH. Nevertheless, if you specify the value a : is automatically generated instead because no other valid value is found.
If you would like the user to be able to see all values and hierarchies for a characteristic, use the value '*' for this characteristic.
If you use a drilldown hierarchy in the query, you restrict the highest node by a fixed node or a node variable.
Definitions of authorizations for hierarchies must be transported separately. See: Transporting Additional Information
Alternative Procedure:
Manually Maintaining Reporting Authorizations
Use
You usually maintain authorizations in the role maintenance. However, in exceptional cases it could be more practical to create authorizations manually. This is the case if you have to assign every user his/her own role.
Prerequisites
Reporting authorization objects have been created.
Procedure
Assign Authorization Objects
       1.      In the SAP Easy Access initial screen of the SAP Business Information Warehouse, choose SAP Menu ® Business Explorer ® Authorizations ® Reporting Authorization Objects.
       2.      Choose Authorizations ® Authorizations for Several Users. Enter an interval and choose Change.
       3.      Select a characteristic from the left side of the screen. You can then display master data as a list or as a hierarchy. The right side of the screen shows you a list of all the selected users with the authorization profiles and roles you assigned.
       4.      You can now use Drag&Drop to assign additional authorization objects to the user.
       5.      Choose Generate authorizations. The system creates the authorizations and assigns them to the users.
Assigning Authorizations for Hierarchies
You can also make authorizations for hierarchies in the same transaction.
       1.      Select a characteristic.
       2.      You can use the context menu on the authorization object to determine up to which hierarchy level the authorization should apply.
You can currently select exactly 1 level for each hierarchy and user.
       3.      Choose Generate authorizations. The system creates the authorizations and assigns them to the user.
Result
The system has created individual authorization profiles.
thanks
karthik
reward me ipoints if the above is usefull to you

Authorization check in LDB PNP

Hi All,
I am using logical database PNP in my report program and GET PERNR to fill the infotype tables. Infotype level authorization checks are performed but not Org data level (organizational assignments). The role assigned to me has access to data of specific personnel areas but I am able to retrieve data of all personnel areas (this was maintained in the authorization object P_ORGIN).
I read the level of simplification should have a value 1 in the authorization object P_ABAP for Org Level authorizations to be performed. I have updated my role but still org level authorizations are not performed.
Can you please let me know if any special setting are to be done like in Tcode OOAC or set some flags/parameters in the report program to perform org data level authorization.
Any information provided will be really helpful.
Thanks,
Pavan

Hi,
A separate ID was created in an environment similar to production and proper authorization were assigned to it (I mean roles with authorization objcts P_ABAP - level of simplfication 1 and P_ORGIN - restricting based on personnel area). Still Org level authorizations were not performed while using the LDB PNP. Is there anything I am missing?
Thanks,
Pavan

CRM - Process Flow of Authorization Check in Business Transactions

Hello Folks:
I have implemented CRM security using Process Flow of Authorization Check in Business Transactions.
What I have in place:
CRM_ORD_OP (inactive, don't want access to own documents)
CRM_ORD_LP (inactive, not using standard org level values Distribution Channel, Sales Group, Sales Office, Sales Organization, and Service Organization.)
CRM_ACT (active)
CRM_CMP (active)
CRM_ORD_OE (active, restricted to display with dummy value ' ' for Distribution Channel
Sales Group, Sales Office, Sales Organization and Service Organization, as we are not restricting on them)
CRM_ORD_PR (active and restricted to display)
Issue:
Restrictions to display for documents works fine when using CRM backend system and the system throws out a message that you are not authorized to change. But, when i come in through Portals (PCUI), i dont get the display at all and it throws out a message insufficient access authorizations.
Traces on backend CRM reveal failing on change access for CRM_ORD_LP and CRM_ORD_PR, which we dont want to give out b/c we dont want to provide change for documents.
OSS notes to SAP have resulted in no results....please advise what is wrong here.
Thanks
KT

Thanks for the Priyanka for the reply, but what you mention is not correct.
BSP errors are different from what I am refering to.
The issue is still open...and looks like a SAP bug, which even they havent been able to fix so far.
Regards,
KT

Create authorization check for a report

Hi,
I need to create an authorization check for a report. It means that I need to restrict the usage of the report to couple of users ( 'USER1' and 'USER2' ). How can I do that? I did read through a lot of threads regarding this piece got a bit confused and stuck while creating the authorization object.
Say the report name is ZHR_TIMEABC.
Can anyone explain how to create an authorization object and how are they tied to the object and call them in the abap code?
Thanks in advance,
VG

Hi,
Thanks. Here is my understanding, S_C_FUNCT calls a system generated function module to make an authority check. So, if different users say USER1 and USER2 have different authroization levels, defined in their user profile, just adding this piece code will take care of authroization check for the program OR do I need to take care of something else?
If so, when do we need to create the authorization objects using SU20 and assign the group and follo this process? When do we use this approach ( lot of threads on authority check have mentioned this procedure)?
Your inputs will be helpful to understand this concept.
Thanks,
VG

Authorization Check on Radio Button

Hi,
I have a custom report which has a radio button. Can I provide the authorization on this radio button, meaning only selected no. of users can run this report with radio button checked. I know it's possible through maintaining a list of users in custom table, But I want to check if we can do it using authorization object/group etc...

Birendra, you're absolutely correct that we need to consider future maintenance efforts. But this is exactly a weak side of the parameter approach that you've suggested. The jet analogy is impressive, but way out of proportion in this case.
Using authority check command in ABAP code and modifying screen elements is not hard-coding. The parameter approach also requires writing some code, so it has no advantage here.
Also it requires someone (a Basis admin?) to update the user profile and a table entry that you've mentioned. To use the standard authorizations, only one authorization object will need to be created (although it may even be possible to use another, existing object if it's the same authorization level). It won't take more space or more time to create than an SM30 entry. Updating the roles might be more of a hassle than updating the user parameter, but the difference can hardly be considered significant and it's a one-time thing anyway.
It is a matter of preference whether to hide a control, disable it or display a message. (By the way, in many standard transactions you'll find that controls or menu options are hidden/disabled based on authorization, so it is nothing exotic.) But I stand by my suggestion of using standard authorization check functionality specifically because it makes the future maintenance easier.
1) Basis admins most likely already maintain some document regarding the role assignment. It might be actually easier to them to maintain the roles than to keep track of the additional profile parameter and remember it in future.
2) Imagine years from now you're gone and all the new people are maintaining the system. The user gets a 'no authorization' message and, naturally, contacts a system admin. Again, naturally, admin will check security trace. Now guess what - your parameter thingy cannot be tracked anywhere. No one knows about it and it will take an ABAPer to figure this out.
With standard approach it will only take a second to run SU53 and a few minutes to resolve an issue by a Basis admin. Additionally, authorization objects have 'where used' button, so it would be easy to check if and where the object is used (e.g. if the report has been changed/deleted it will be easy to spot the 'orphaned' object). With the profile parameter sooner or later someone will have to wonder what the heck it is for and might accidentally delete it. By the way, sometimes users actually have access to their own parameters, so it's not a very secure option either.
I understand you mean well, but, unfortunately, in my work quite frequently I have to deal with some things that were developed by well-meaining consultants who overlooked some long-term effects of their approach.

Authorization Check Infotype Header

Hi all,
i posted the following threat in HCM Forum, but i think it is also a question for ABAP Forum
Authorization Check Infotype Header
Thanks & regards

1. authorisations in hr cannot be controlled at infotype-header level and/or infotype field level.
2. If only a few fields of a specific infotype are to be allowed for a user the most efective way of doing it is by way of creating a view for the infotype with only the allowed fields in it.
3. another way of doing it is by way of a custom authorisation object (potentially) but then again your requirement is not going into explicit details,. so this option is a possibility you may want to do some due diligence on.
cheers

Re: Setting Authorization Check in Report Writer

Hi,
In ABAP Query or ABAP customized program, it is possible to set authorization object checking.
In Report Writer, how can I do it?
<REMOVED BY MODERATOR - REQUEST OR OFFER POINTS ARE FORBIDDEN>
Thanks
Edited by: Alvaro Tejada Galindo on Dec 26, 2008 10:59 AM

Hi Colin,
I would like to suggest,
Creating an Authorization object & then using it in the report program is the preffered way.
I would like to suggest a couple of references, quite similar to your issue,
[SDN - Reference for using authorization checks at the report level|User authorisation check in ABAP-HR program;
[SAP HELP - Standard Reference for Programming Autorization checks|http://help.sap.com/saphelp_nw04/helpdata/en/52/6712ac439b11d1896f0000e8322d00/frameset.htm]
[SAP HELP - Standard Reference for Authorization checks|http://help.sap.com/saphelp_nw04s/helpdata/en/fc/eb3ba5358411d1829f0000e829fbfe/frameset.htm]
Hope that's usefull.
Good Luck & Regards.
Harsh Dave

Authorization check in tocde CJ20N for WBS elements

Hi Experts,
in cj20n tocde, if we give authorization to wbs element then networks and activities attached to this wbs element are authorized for edit,create..This is my requirement. I used 3 function modules EXIT_SAPLCNAU_002, EXIT_SAPLCNAU_003, EXIT_SAPLCNAU_004. It is working fine.
My problem is when network or activity of other wbs element is linked, then it is failing. Because it is checking its parent level instead of checking upper level.
Please help me on this.
thanks in advance

Hi Gurus,
Thanks for your responses.
I am explaing issue cearly with example.
wbs0001 has one network net0001 and this network has one activity act0001
similarly wbs0002 has one network net0002 and this network has one activity act0002
now if i give authorization to wbs0001 then net0001 and act0001 has authorization..this is OK
issue is if act0002 is linked to wbs0001 and if i give authorization to wbs0001 then net0001 and act0001 has authorization but act0002 has no authorization.
My requirement is act0002 also should have authorization as this parent wbs0001 has authorization.
Please help me.
rgds
Ali

Authorization check at diff levels

Similar Messages

Maybe you are looking for