Roles read only

[Former Member]

Hi experts,

We want to make the roles of some users read only. We thought to change all ACTVT fields to 03, but users have over 200 roles, and these have more than 11.000 objects ACTVT. This is a drudgery job.

Is there another way to do this task?.

Thanks and Regards

[Former Member]

Hi,

The requirement is to see all the transactions with display authorizations alone.

Correct me if am wrong.

Pls provide the req clearly.

Regards,

Raja. G

[Former Member]

>

> Is there another way to do this task?.

Build a specific set of display roles & replace what is assigned to the users.

That is the proper way of doing it and will take you less time than changing 200 roles + the job will be done correctly.

[jurjen_heeck]

In addition to the other comments: It will not only be a drudgery job but also a sloppy one. There are somewhere around 200 different activity-related fields and with some of them 03 isn't the read activity. Besides that, there are several objects that will grant change access without having an activity field at all............

[Former Member]

Exactly Raja, we want users have the same transactions, but only for reading.

Regards

[Former Member]

Hi,

If you want to have all the transactions in single role with display authorizations.

Goto PFCG->Create new role-> Goto Authorizations tab-> change authorizations Data->Edit-> insert Authorizations-> full authorization

It ll give full authorization. You can make the ACTVT field to 03.

If you have any Z transactions add it manually. It wont come.

For any issues. Revert back.

Regards,

Raja. G

[jurjen_heeck]

This is very poor advice. It will not protect your system in any way.

[Former Member]

Hi Jurjen,

The requirement is to see all the transactions with display alone.

This role will be assigned to all the top level people and the functional consultants.

So that i suggested this one. We are also maintaining like this.

We are also maintaining it for every department level display roles.

May i know what kind of security breach in this? So that i ll also modify the same.

Regards,

Raja. G

Edited by: Raja Gunasekaran on Sep 17, 2009 1:47 PM

[Former Member]

> If you have any Z transactions add it manually. It wont come.

This would only be true if a special config setting had been activated, which it by default is not. I doubt there are many customers out there who have actually done this.

As you can see, some forum members are itching a bit at the rest of your post. This is an urban legend which has been going around for many years, and causes nothing but security problems and bad (inconsistent) role designs.

If you want to take that approach, then you need to know all the fields which are action related and in which objects (so you need to know the objects very well as well) they are used. There are also combinations of objects which are tricky and if you mix it with another role built correctly then you quickly have unintended and unauthorized access. For dialog users starting transactions you will still have the S_TCODE problem anyway.

Cheers,

Julius

Edited by: Julius Bussche on Sep 17, 2009 1:43 PM

[Former Member]

Hi Raja,

Why would you assign FB01 if someone needs to display only and FB03 should be used instead?

The transaction is rendered useless & should not be performed unless there is no other practical way of displaying the data.

The risk is twofold.

1. Can you guarantee that they will have no other roles with create or change activities which will be inherited?

2. Are you 100% confident that the authorisation concept hasn't missed a validation on a create or change transaction. I'm not.

Additionally, what do your internal & external auditors say about it. If they haven't raised this as a problem then they aren't reviewing properly.

[Former Member]

Thanks all for your answers,

In the end, the customer wants to change all the ACTVT field in all the roles. Raja, your idea is not possible because they doesn't want that every user can see all transactions.

Best Regards

[Former Member]

Hi Maximino, with the greatest respect intended, the customer are wrong. As the service provider shouldn't you be telling them the best way to achieve it.

I would recommend that you tell them this to ensure that you are not responsible when they auditors pick this up as an issue.

[Former Member]

It is still a notch better than merging all the roles into a mother-of-all-display access.

But a big problem will be thousands of "changed" status authorizations in roles which might have been previously intact.

Come SP and upgrade time, you will pay for that mistake 10 times over!

=> Advise your customer not to do it.

Cheers,

Julius

[Former Member]

>

> It is still a notch better than merging all the roles into a mother-of-all-display access.

depending how you do it of course

I would prefer to see a big role made up of only display tx & objects treated properly than the proposed alternative

[Former Member]

It also depends on what the chances are of the role being mixed with other roles using different builds.

What he said was:

> but users have over 200 roles, and these have more than 11.000 objects ACTVT.

So I am thinking that all users would have this role somewhere, and what is intended to be "the enablers" in a different role.

But I could be wrong.

Cheers,

Julius

Edited by: Julius Bussche on Sep 17, 2009 7:06 PM