Custom Authorization Objects

[former_member207873]

Hi Experts,

I have created  a custom report which is showing Account Balances, Stock and Invoice. All these reports come under one Tcode. Below are the autho rization fields which are required for my each report. (ACC Bal, Stock and Invoice)

Sales Office              

Company Code

Sales Division

Plant

Here I have created my own authorization class, authorization objects and authorization fields.

       ZAUTH      (AUTH CLASS)

ZINVOICE(AutOb)

ZVKBUR ZSPART

ZACCOUNT(AutOb)

ZVKBUR

ZSTOCK(AutOb)

ZBUKRS ZWERKS

There is no overall authorization concept existing in the organization now. That is why I am going ahead with custom authorization concept. But I am confused with the steps to follow.

Here is the precise of what I have done so far.

1) Created custom Authorization fields with the existing data elements, (SU20)

2) Created Authorization objects and class (SU21)

3) Created a role in PFCG. (Added values say for sales office 2000 and activity '03').

4) Assigned TCode to Authorization Object in SU24.

5) Checked in my custom program with 'Authority check' for sales office with '2000'. But it is running for all sales office.

What will be the possible issue?

There are many levels of authorization to be achieved. First for the TCODE and then for the individual selections in the list box item. (Invoice, Stock and Accounts- All in the same tcode ). Then for the individual fields in the report. How to achieve this?

BR.

[former_member207873]

Any Help

[Former Member]

Why not take the regular organization objects (WERKS, BUKRS, VKORG) instead of creating custom (ZVKORG, ZBURS, ZWERKS) ones?

You say that "There is no overall authorization concept existing in the organization now. That is why I am going ahead with custom authorization concept."

It's sounds like a good first step to set up a (new) overall autorization concept using org levels.

If you chose for creating new org objects you will have to assign these new ones to the users as well and this can be very confusing for the auth concept itself.

[nishad_showkath]

In stead of using custom fields like ZSPART or ZWERKS, Can you use standard fields SPART, VKBUR and WERKS in your authoirzation objects ZINVOICE. ZACCOUNT and ZSTOCK? Then update the roles with the new fields and restrict the value to 2000 for VKBUR and check if it is working.

[former_member209962]

Hi Nishad,

Yes you can use standard uthorization objects in your zreports only thinng is you need to call that authorization object by passing required vaules in zreports

Then you can create a role with that particular zreport and assign the authorization object manually to that role and give required values.

Thanks

Tabrayz

[nishad_showkath]

HI Tabrayz Abdul,

I was asking the user who posted the question to use standard fields instead of custom one. i know that you can use standard feild in ZRreports..

Nishad

[former_member209962]

Sorry my mistake i guess i applied to wrong post.

Thanks

Tabrayz

[former_member209962]

Hi

Yes you can use standard uthorization objects in your zreports only thinng is you need to call that authorization object by passing required vaules in zreports

Then you can create a role with that particular zreport and assign the authorization object manually to that role and give required values.

Thanks

Tabrayz

[Former Member]

HI,

Check if SU24 is maintained for Sales Office. Also check with ABAP team, as to why auth.is not being checked in program.

As Nishabd, said, use standard fields , instead of custom ones.

Auth. checks will be finally performed on the fields, for your reports. So, ensure to keep them checked in Su24.

[Colleen]

Hi ABAP ABAP

"There is no overall authorization concept existing in the organization now." - was there ever? And I wonder if your approach is going to add to the mess in your system.

I can see three options here (some of it will involve removing what you have done)

• Stick to SAP Standard: Look TOBJ table (or the SUIM reports) and check what authorisation checks actually exist for standard fields VKBUR; SPART; VKBUR; BUKRS; WERKS instead of your Z version. Keeps the objects standard and makes sense. Depends on purpose of report, etc
• Use a mixed version - keep your ZINVOICE, ZACCOUNT and ZSTOCK but map the SAP standard fields to them instead of your Z fields. You will need to fix the auth object definitions and then check your ABAP code to clean the authority check up.
• Stick to what you are doing.. and improvement:
  • If you need to separate data for the fields ZVKBUR, ZSPART, ZVKBUR, ZBUKRS, ZWERKS so you can build imparting/derived roles you can look at promoting these auth fields to org fields via PFCG_ORGFIELD_CREATE program

For your actual question - why isn't my authority check working - your last comment

"5) Checked in my custom program with 'Authority check' for sales office with '2000'. But it is running for all sales office." i

• What is your ABAP syntax for these authority check?
• Also, have you run ST01 Auth Trace to see what is passing/failing - if you are not getting an RC=0 what Return Code are you getting?
• Have you passed the actual input field selection or data/etc into the authority check?
• Finally, have you debugged your code?

There are many levels of authorization to be achieved. First for the TCODE and then for the individual selections in the list box item. (Invoice, Stock and Accounts- All in the same tcode ). Then for the individual fields in the report. How to achieve this?

This statement also comes back to your program logic - how have you managed this? On execute your cover S_TCODE but when you execute the report you need to handle each scenario and pass the selection values for the report.

Finally - what did you actually assign the test user? You built a role in PFCG with this access - did that user just get that access and nothing else?

Regards

Colleen

[OttoGold]

Hi there,

your only option IMO is (and should be) to fix the "standard security". Fix the process of building and assigning roles. What you're doing sounds like you're making the mess even worse. Although it might sound like your way may work (for a moment... very short moment), it will pile up the problems for people that will come to fix the company and "do the right way".

cheers Otto