Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Security restriction by adding new auth object in SU24

former_member575786
Active Participant
0 Kudos

We have lot of Z- reports and standard reports ,Right now there is no restriction with any objects for the Z- reports and we have security restriction for the standard report by plant wise . we want to restrict the Z- reports for plant specific.

custom t code does not have any objects in SU24. Can we add any object u2026u2026.. to that customized tcode in SU24 without changing the program? I mean without adding this object in the ABAP code and putting authority check will this serve the purpose ? We want to restrict it by plant .

Can anyone please give me suggest the right object and the process behind that

Thanks for the help

J

1 ACCEPTED SOLUTION

martin_voros
Active Contributor

No. That check has to be performed in the program. Just adding record into SU24 won't activate any authorization checks. How could it work? For example you have record with multiple plants (e.g. source and destination plant). How could it know which plant should be used for check.

You will have to go through all your reports and implement additional authorization checks. This is a classic consequence of ignoring security during implementation.

Cheers

17 REPLIES 17

martin_voros
Active Contributor

No. That check has to be performed in the program. Just adding record into SU24 won't activate any authorization checks. How could it work? For example you have record with multiple plants (e.g. source and destination plant). How could it know which plant should be used for check.

You will have to go through all your reports and implement additional authorization checks. This is a classic consequence of ignoring security during implementation.

Cheers

0 Kudos

This is a classic consequence of ignoring security during implementation.

I have been very tempted to write a blog for some time on the evolution of authority-checks in customer coding, starting at executable reports, and via S_PROGRAM (pest), hard-coding (pest), check-tables (pest), generic FMs (pest), etc etc etc (pest) and ending up respecting BAPIs and the calling program context (and user friendliness of the UI security aspect).

I still have "writer's block" because of WAPIs, otherwise I might have done it and also don't have an SDN "sparring partner".

If you are interested in writing a "joint authored" blog or article then I would be very happy to contribute many tricks, gotcha's and experiences to it.

BUT, the audience first needs to RTFM..

Cheers,

Julius

0 Kudos

Julius,

thanks for offer but I am not sure if I would be useful.

Cheers

0 Kudos

I volunteer

Former Member
0 Kudos

Dear,

In addition to Martin Voros post.

For customized transaction, the SU24 is used for maintaining the link between transaction code and auhtoirzation object with values for role (PFCG) purpose and not for any authority check.

Regards,

Shrinivasan. KV

former_member575786
Active Participant
0 Kudos

Thanks for the suggestion. We already developed the security role restricting by plant for the standard reports , It is working without any issue . Z- reports are not subjected to any security right now due to su24 missing .You mean, still i have to incorporate the objects in the program also ?

0 Kudos

You mean, still i have to incorporate the objects in the program also ?

Exactly. Once the checks are there they will work, even if they're not present in SU24.

0 Kudos

Once the checks are there they will work, even if they're not present in SU24.

To be more exact: they will work as designed IN customer systems IF the program reacts to the AUTHORITY-CHECK return code AT the correct program location, regardless whether they are documented in SU24 / SU22 or not.

It is very easy to code defunct authorization checks just to satisfy auditor's sampling...

Cheers,

Julius

0 Kudos

>

It is very easy to code defunct authorization checks just to satisfy auditor's sampling...

Which is the exact reason why I demanded to have (and got( BC400)) ABAP training at my former employer.

0 Kudos

The flip-side of these defunct check locations and not reacting to the returncode and hardcoding user names and checktables, is that you can make a mess of your roles and change them all you want... the access remains stable.

This is sometimes also an indication of the developers' level of confidence in the authorizations side of the coin, and who was / is maintaining them, or might be in future... (sometimes it can even be a blessing in disguise, albeit a sad one...)

It certainly makes sense to first harmonize and clean up the role design, and then tackle the customer code to re-use the existing semantics and access in a consistent way.

Watch the spot

Cheers,

Julius

Edited by: Julius Bussche on Feb 9, 2011 9:14 PM

0 Kudos

Julius wrote

To be more exact: they will work as designed IN customer systems IF the program reacts to the AUTHORITY-CHECK return code AT the correct program location, regardless whether they are documented in SU24 / SU22 or not.

We had a request for transaction MR21 to be given but for just one company with a few plants, tracing showed valuation area passed but the object wasnt present in roles assigned to the test user. Adding the object didn't restrict, changing SU24 to check maintain worked but also stopped people without the object from changing prices. I know we've done SU24 to death but it still has it's mysteries for me

Edited by: David Berry on Feb 13, 2011 10:06 AM

0 Kudos

What you have described is only possible if the RZ10 param transport/systemtype is NOT set to the value CUSTOMER, as SAP uses this as a "dirty trick" to force it's own developers to document the check flagged objects.

Unless you were working on one of SAP's original development systems or had hobbled the systemtype param, what you observed was an illusion

Another possibility is a program error by first checking for DUMMY field or full authority and if sy-subrc NE 0 then suppress all further checks - however manually adding the object with specific values should have shown that.

Cheers,

Julius

0 Kudos

Hi Jeevan

Sorry for hijacking your thread! I only just remembered my manners and I hope you are not too annoyed.

Hi Julius

Exploring areas I've never heard of before - suppose it's normal

What you have described is only possible if the RZ10 param transport/systemtype is NOT set to the value CUSTOMER, as SAP uses this as a "dirty trick" to force it's own developers to document the check flagged objects.

The setting appears to be correct in DEV and QAS but I don't have access in production to check if actually the same. edit - just realised that it must be as QAS was where we did the negative testing edit

ParameterName

transport/systemtype

Short description(Engl) System class (SAP or CUSTOMER)

Appl. area Transport

ParameterTyp Character string

Changes allowed Change generates error

Valid for oper. system All operating systems

DynamicallySwitchable (not ticked)

Same on all servers (not ticked)

Dflt value CUSTOMER

ProfileVal CUSTOMER

Current value CUSTOMER

Unless you were working on one of SAP's original development systems or had hobbled the systemtype param, what you observed was an illusion

Should I take the red pill or the blue pill?

Maybe both...damn - why didn't Neo think of that...

This system is pretty ancient and cobbled-together that it wouldn't surprise me but, as I see it, the SU24 entry is doing exacty what I wanted it to do and hold back users who are (were) happily changing prices on materials outside of their responsibilies.

Cheers

David

Edited by: David Berry on Feb 13, 2011 4:43 PM

Edited by: David Berry on Feb 13, 2011 5:00 PM

0 Kudos

No, the system has foxed you into believing that "Check" has some affect in customer systems. It does not.

If you display MR21 in SU24 and then choose the menu to display change documents ( table USOBT_CD ), then you will see that you did not add the object to MR21. It already was there but with a "No check" indicator as old value.

Of course transaction context specific deactivation of an authorization object has an affect in both SAP and Customer type systems. You might want to check the other MI* tcodes as well as they are mostly delivered "out of the box" with an explicit "no check" on CPE_SETTIN etc.

Cheers,

Julius

Edited by: Julius Bussche on Feb 13, 2011 6:28 PM

0 Kudos

Hi Julius

Spot on... apologies

Changes to check indicators of authorization objects under transaction MR21

TCod Object New Old User Date Time

Changed MR21 K_MLPR_VA Check/maintain No check UK_DBERRY 04.02.2011 13:52:44

That makes sense now!

Many thanks -a bit off topic for Jeevan's posting...

Cheers

David

0 Kudos

I think the discussion is still nicely on track, also with a practical example now.

I hope that Jeevan's question wasn't some interview theory - otherwise I need to fetch my Test & Playground raincoat as well...

Cheers,

Julius

former_member575786
Active Participant
0 Kudos

I enjoyed this thread ..Please continue it.. Our problem is resolved ..