Authorization object S_DATASET

[ashish_vikas]

Hello friends,

I have a question..(may be silly one )

If i have a auth object say S_DATASET available in 2 roles with different values.

S_DATASET

Activity 33, 34 ACTVT

Physical file name /transfer/C11/order/aus FILENAME

Program Name with Search Help * PROGRAM

S_DATASET

Activity 33, 34, A6, A7 ACTVT

Physical file name * FILENAME

Program Name with Search Help ZP1, ZP2, ZP3 PROGRAM

Now what happens when both roles are assigned to a single user. Does he get S_DATASET with activity merged ?? means will he have auth lieke this :

S_DATASET

Activity 33, 34, A6, A7 ACTVT

Physical file name * FILENAME

Program Name with Search Help * PROGRAM

thanks

ashish

[jurjen_heeck]

Nope, authorizations do not merge.

[Former Member]

Hi Ashish,

Yes, He will get the merged Authorizations for his access !

During authorization check, Authorization fields are always checked in an AND relationship for each authorization object instance within role(s).

Regards,

Raichand

[ashish_vikas]

thanks for reply.

Edited by: ashish vikas on Sep 16, 2011 8:12 PM

[Former Member]

Jurjen Heeck is correct, but Actvt A7 with program * is critical for the operating system. Not a good idea and seldom needed.

Cheers,

Julius

[ashish_vikas]

Hi Julius,

but in Role 2, I am not giving * for Program. it has only 3 programs ZP1, ZP2, ZP3 with Activity A7.

thanks

ashish

[Former Member]

Yes you are correct, but it does depend on what those 3 programs do and which import parameters / selection screens they have.

Why do you want to put * into the program name of the first role though?

Can the user create a file in the order directory with the name permitted, then use ZP1 to move it to a different directory and rename it and execute it?

The mix seems suspect to me because of the combined access from building roles using different techniques, but they are not merged!

Cheers,

Julius

[Former Member]

Wait, to be clear....

The reason why "auths don't merge" in OP's case... is because ACTVT, FILENAME, and PROGRAM are unique in the two profiles, correct? But if the situation was like below instead, then you could think about it as "auths merging" even though technically that doesn't happen.

so if it was:

S_DATASET

Activity 33, 34 ACTVT

Physical file name /transfer/C11/order/aus FILENAME

Program Name with Search Help ZP1, ZP2, ZP3 PROGRAM

S_DATASET

Activity 33, 34 ACTVT

Physical file name * FILENAME

Program Name with Search Help ZP1, ZP2, ZP3 PROGRAM

Then the FILENAME restriction from 1st role would be ignored because of the * in the 2nd role. But if we added ACTVT A6 to the 1st role, then this role would not be overriden the 2en, because the auths don't match, meaning in this case, the user would have ACTVT A6 for filename transfer/C11/order/aus and nothing else. Correct?

[Former Member]

Having added A6 would have kept the merge appart, but that is no reason to keep the merge appart from a cosmetic perspective. The access is the same if all other fields are identical.

I sometimes use "banana" values to avoid merging so that I can later keep them appart. But this is only because there is not unmerge function to split them appart again.

Yes, you could achieve actvt A6 for the first authorization's other fields by adding it first, but if A6 is not needed then it would add not value...

--> ZP1, ZP2 etc will anyway read and write to /TRANSFER/C11/... etc and does not need A6.

But okay, they are two seperate authorization instances assigned to the same user and they look different.... if that is your goal

Using transaction FILE and SPTH you could however achieve more granularity (beyond the "file name"),

Cheers,

Julius

[Former Member]

From an academic perspective they could however be merged by program ZP1, ZP2 or ZP3 using actvt A7, because this permits operating system commands to any file system location. At the operating system level you could then do almost anything (such as merging the two roles into one in a transport request, adding it to the tp buffer and importing it).

Your first priorities should be to restrict the program name and the A* actvties and maintain su24 with the; then restrict / validate what the programs are capable of doing.

Cheers,

Julius