Authorization Object S_ALV_LAYO with activity 23

[former_member511391]

I just wanted to know if there is any security issues/risks with allowing end users to have access to this authorization with activity? Like are they able to maintain any table data with this access, and so on. I would appreciate any input.

Thanks,

Ward C. Shigaki

SAP Security Administrator

Department of Transportation

[Former Member]

Hi,

Object is used to

You use this authorization object to protect global default layouts of the ABAP List Viewer (ALV).

To my knowledge I dont think user will not be able to maintain any table data. Its only List view options.

With activity 23 create, change or set default layouts only. Nothing can be done with table data.

Hope this helps.

Cheers

Soma

[Former Member]

This object gives users the ability to change report layouts globally. What happens is a user will decide that they don't like a report the way it is, so he changes it. Then everyone else that is used to seeing the report the other way start complaining and/or change it themselves.

I've always found it best to restrict access to this object to the support folks. If a report layout needs to be changed globally then they should be a part of that change.

Hope this helps.

[former_member511391]

Thanks for the imput but I need some additional clarification. Are you saying that this authorization then allows the end-user to change the default variant and when saved it becomes the new default variant? If so, then that is bad. Does anybody know what authorization object is that controls the user-defined button on the variant creation?

[Former Member]

Yes, it lets users change the global default variant. And you're right, this is generally very bad. If you take this object away, then users can only save user-specific variants. I believe F_IT_ALV can control the ability to save user-specific variants, but I'm not positive. Check it to be sure.

[former_member511391]

I added the the auth object F_IT_ALV and gave it activities 01, 02, 03 and still the layout screen has the user-specific check box greyed out. Any other thoughts?

[Former Member]

What transaction code are you running? The User-Specific check box is grayed out, but is it checked? I'm guessing it is (and this is what you want), since this forces the layout to be user-specific. If you grant S_ALV_LAYO and then re-run your test, it should be enabled and probably unchecked (generally not good).

F_IT_ALV is a little different than most (maybe all?) other authorization objects. If a user does not have any authorization for F_IT_ALV, then it is not checked. If you add F_IT_ALV to the user, but don't give it full access, you have now made the the role MORE restrictive than it was without the object. There is a note on this that may be worth reading, but the summary is that it's optional and, when present, it introduces an authorization check that didn't previously take place. If you want to control user's ability to create user-specific variants then this object can do it. If you don't care, then it may be easier to just inactivate the object in the role or give it full access. Either way, you've restricted access to global layouts by denying access to S_ALV_LAYO.

[former_member511391]

Okay, then you are saying if end-users have the ability to uncheck the user-specific check box then they will be able to overwrite a default variant if one existed for a specific report/table.

[Former Member]

Correct. If they can uncheck the user-specific box, then they have S_ALV_LAYO and they can create global variants seen by everyone and they can choose to change one of them to the default.

[Former Member]

I have the same situation, I tried removing the Activity 23 for S_ALV_LAYO auth object, but it disabled/ grayed out the user specific check box and not the default check box. Do you know what is being missed here?

[former_member511391]

Thank you for your response. We will not not granting access to the authorization object due to the fact that the default variant can be overwritten.