How to link two authorizations to an object.

[Former Member]

Hello,

In the EWA report I received the following recommendation:

"If you do not want to disable development in your system, you have to exclude OBJTYPE=DEBUG with ACTVT=02 from the profile and allow any other object type for S_DEVELOP. This means that development and debugging with visualization are still possible.

You can do this by linking two authorizations to object S_DEVELOP: One with all object types (except "DEBUG") and all activities and another for object type DEBUG only with all activities (except 02)."

How to achieve this?

Thanks

Galina

[jurjen_heeck]

I think the term "linking" may confuse here.

You just need two instances of the S_DEVELOP object in your roles' profile.

"One with all object types (except "DEBUG") and all activities and another for object type DEBUG only with all activities (except 02)."

[Former Member]

Hello, Jurjen

These two occurrences of the same object will appear in the same role, correct?

Thanks for your reply.

Galina

[Former Member]

Yes, that should be done in the same role..

Regards,

Sandip

[Former Member]

Thank you, Sandip

[Former Member]

I disagree with "should be done in the same role".

It will (most likely) force you to add a "manually" created authorization within the role data, unless you maintain the tcode of the ST22 debugger in Su24 and the menu.

Additionally I would recommend a dedicated role for debugging of any sorts (1 for display, and 1 for change) anyway. Other activities in the debugger can be critical as well...

The EWA-check IMO is like an acid-check. It is not meant for granular security concept reviews, like those which a role concept (and how you build them) are.

Cheers,

Julius

[Former Member]

Julius,

thank you. I try not to maintain transactions in SU24. I like the idea of the separate debugging roles. I understand what you mean about acid-check. I got "red" light because the number of people with critical authorization for S_DEVELOP is more than 10% of the users. We have a small user population. So, I have to address every user separately and to see what to do in each case. After we upgraded to ECC 6.0 there was many authorization issues related to objects like S_DEVELOP or S_PROGRAM. This was not expected.

Thanks

Galina

[Former Member]

> I try not to maintain transactions in SU24.

>...

> We have a small user population.

I can understand that, however it still has a downside when your user base grows, or you move on and someone else needs to take over, or the functional consultants leave the building and when you upgrade or apply support packs and need to make some changes, then you don't know why the authorization was added manually - at least not without having to sieve through a sea of documentation and mails etc.

It is easier to find a transport request and it's documentation IMO, and who knows about it, approved it, tested it, etc.

It is just a little organizational discipline thing, but it does go a long way.

Cheers,

Julius

[Former Member]

Julius,

I am not sure I understand completely. There will be transport request anyway. Would you, please, explain a little bit more what is different in your approach? I understand about creation of the separate debugging roles.

Thanks

Galina

[Former Member]

> There will be transport request anyway.

That is mostly true as well. Fair enough.

>Would you, please, explain a little bit more what is different in your approach?

You transport the concept change through via the SU24 indicators - this is like customizing, and different (also technically) to a role, which is more like application data.

Certainly if you are choosing the option to disable some checks transaction specifically, it is necessary to use this approach anyway to keep the SU24 data in sync.

If you have not used Su24 before, then try it out a bit. It is a great tool to maintain the concept (and not just the roles).

Cheers,

Julius

[Former Member]

Julius,

Thank you. It is helpful. I will look into SU24 usage.

Galina

[Former Member]

There have been a lot of questions about this (actually, strange answers would be more accurate...) so Alex and I put a blog together to explain some of it's workings and intentions.

=> /people/julius.vondembussche/blog/2008/04/19/how-to-get-hit-by-the-abap-authorizations-bus-and-survive-to-tell-the-tale--part-1

There is also a part 2, which includes an example on a tricky object which is comparable to S_DEVELOP when it comes to making easy mistakes.

Hope it helps as well,

Julius

[Former Member]

Julius,

Many thanks. And how to see Part 2/

Thanks

Galina

[Former Member]

Just use the search...

=> /people/julius.vondembussche/blog/2008/10/22/how-to-get-hit-by-the-abap-authorizations-bus-and-survive-to-tell-the-tale--part-2

Cheers,

Julius

[Former Member]

Julius,

Many thanks.

Galina

[Former Member]

Hi,

Authorization object: S_DEVELOP, with activity 02 and Object type "DEBUG" is too critical. As per the reuest you need to do change the role by the following steps:

1. Add all activities in the object: S_DEVELOP and extract the Object type: DEBUG.

2. Add all object type in S_DEVELOP and add all activities except: 02.

Regards,

Sandip.

[Former Member]

Is there an echo in here? That's exactly what Jurjen said