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: 

Question about Auth Objects and Tcodes

Former Member
0 Kudos

If a user has access to a Tcode in 1 role and the auth objects to run that Tcode in another role, can the user still run the tcode?

For example, a user has access to FS00 in 1 role, and F_SKA1_BUK with Activity 02 in another role, can the user make updates?

Thanks!

6 REPLIES 6

Former Member
0 Kudos

You have three options here actually...

- Take a guess --> Invent your own authorization concept in your own code.

- Use the search --> To understand the reasoning behind it.

- Test it yourself --> To clear the initial doubt about the same standard system behaviour.

Depending on how lucky you are feeling, you would be safer going for the last option first.

Please try it and let us know.

Cheers,

Julius

sdipanjan
Active Contributor
0 Kudos

Logically not possible. But, the checks for assigned TCodes and their respective authorizations are populated in the User buffer as a whole and thus during execution of a TCode, the corresponding Objects are verified in the user buffer throughout, so the execution can be granted for separate source of TCodes and Objects.

To make you more clear on this concept I would like to phrase this in separate literature:

The authorization is basically meant for granting access to particular Tasks for a particular Function of an employee. After all, the importance is the total area of Work the employee should be authorized to perform and admin are imposing this authorization to him/her as a whole. It's not important who and how is providing, maintaining, verifying the total set of authorization during the execution of the task while the employee is working.

Regards,

Dipanjan

Former Member
0 Kudos

Dipanjan,

If I understand you correctly, roles are meant to segregate authorizations between user functions, however since the tcode and authorization checks happen in the user buffer, it is possible execute authorizations across muliple roles.

Please correct me if I am wrong,

Former Member
0 Kudos

Though there is a special exception to this --> Composite authorization objects.

To my knowledge it was a precursor for analysis authorizations. So it is an "exotic" now...

Cheers,

Julius

Former Member
0 Kudos

Each authority-check statement typically will specifc an object being checked.

Together with the client, user ID and this object, the system will search in USRBF2 to see whether it is present at all.

If found, the system will search in those authorizations of the object to see whether the set of field values requested in the authorization check correspond with the authorization values per object and *regardless of the role".

In some cases only the field ID name is checked for presence, and not "typed" via the field name definition.

Please try it with two different roles, one for the tcode and some initial authorizations to start it (see SE97) and one for all the objects checked "when using" the tcode.

Then read Dipanjan and my posts again.

Please also see the FAQ thread at the top of the forum page.

Cheers,

Julius

sdipanjan
Active Contributor
0 Kudos

Julius already answered you in details. Try out yourself as he suggested to understand the basics clearly. .... just to add a point... If a Clerk is not supposed to do the work of his supervisor at all then there should not be any point to discuss to give him the access to some kind of supervising authorization by other means (through other role). His/her whole user buffer should contain similar kind of Authorization which is at per with the Task to be performed.

If you design is meant to dedicate a Composite role for each Position (same kind of action as per Task / Function matrix - may be separate in Organization entity or location wise) then you must need to check those Composite roles for their access type which should not lead to the situation to grant unnecessary access .... now-a-days very popularly known as Segregation of Duty (SOD).

regards,

Dipanjan