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: 

security profiles for configurators and developers

Former Member
0 Kudos

hello experts,

is there a generic (standard) profile for:

1) functional configurators that are not allowed to touch development objects, and

2) developers that are not allowed to perform functional configuration?

I am familiar with the S_DEVELOP authorization object; is there a way to exclude the customizing tables from the list of objects?

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Tiberiu,

I dont have a definite answer for your question but I can suggest somethings that I think might help.

First and foremost, what you are trying to do depends on the system you are trying to do this in. Typically developers and configuration users would have more access in Dev than in QA and Prod (I'm sure you know that). It also depends on the strength of your organization, SOD etc.

So coming back to your point, I am going to try and answer your question assuming that this is for Dev

1) functional configurators that are not allowed to touch development objects

You can do this.

1. Create a role, assign sap_all profile and then disable all the basis object classes (bc_a, bc_c, bc_z).

This is a little cumbersome, but they would be able to do everything they need. Certain Functional Tcodes however would need table change access. You can then add these as requested.

2) developers that are not allowed to perform functional configuration?

Try the role SAP_BC_DWB_ABAPDEVELOPER

You can again restrict the table access by S_TABU_DIS and set it to display only (again that depends on your company policy etc) and create another role for table change.

Hope this helps.

Kunal

5 REPLIES 5

Former Member
0 Kudos

Tiberiu,

I dont have a definite answer for your question but I can suggest somethings that I think might help.

First and foremost, what you are trying to do depends on the system you are trying to do this in. Typically developers and configuration users would have more access in Dev than in QA and Prod (I'm sure you know that). It also depends on the strength of your organization, SOD etc.

So coming back to your point, I am going to try and answer your question assuming that this is for Dev

1) functional configurators that are not allowed to touch development objects

You can do this.

1. Create a role, assign sap_all profile and then disable all the basis object classes (bc_a, bc_c, bc_z).

This is a little cumbersome, but they would be able to do everything they need. Certain Functional Tcodes however would need table change access. You can then add these as requested.

2) developers that are not allowed to perform functional configuration?

Try the role SAP_BC_DWB_ABAPDEVELOPER

You can again restrict the table access by S_TABU_DIS and set it to display only (again that depends on your company policy etc) and create another role for table change.

Hope this helps.

Kunal

0 Kudos

Hi Kunal, thank you for your reply.

can you explain how do I "disable all the basis object classes (bc_a, bc_c, bc_z)." from teh SAP_ALL profile ?

Tiberiu

0 Kudos

Hi

Please remove all the S_* autorization objects from SAP_ALL.

But you have to check some necessary objects that are required for activities.

Please have a look at this link and prepare a list according to requirement

http://help.sap.com/saphelp_45b/helpdata/en/52/671326439b11d1896f0000e8322d00/content.htm

0 Kudos

Tiberiu,

You cannot disable (deactivate) them all at once. You will need to disable 1 object at a time. Like I said, this option is cumbersome, but it will make sure that your Functional Consultants do not have access to Basis Objects and still have access to all the Functional ones.

In case you are not aware of how to copy sap_all in a role, do this.

1 Create a role using PFCG

2. Go to the Authorizations tab

3. Click change

4. Copy sap_all from the list of profiles that you will get.

5 To disable, you will need to go to each object and click on the small green rectangle/square to the left. It will say "deactivate" if you place your mouse cursor on it.

A few more comments/suggestions from my side

Workout with your team to whom you want to provide the access.Let them(functional team) come with what access they need and accordingly provide the access.

If you can do that, great ! If the Functional Team members are non-cooperative, then you don't really have a choice. Again, if this is a Prod system, don't do what I said. That is too liberal an access. If it is Dev it should be okay. QA is also debatable.

Inactivate the objects which are not needed and provide display activity for the objects which you are not sure.

I would say disable the objects that you are not sure about rathar than giving Display access. Display access to S_TABU_DIS can be an audit issue in some cases.

There will still be some authorization issues since some transactions change tables. But you can always add the ones needed.

Kunal

Former Member
0 Kudos

Hi,

Do not delete the objects from the classes.

Workout with your team to whom you want to provide the access.

Inactivate the objects which are not needed and provide display activity for the objects which you are not sure.

Let them(functional team) come with what access they need and accordingly provide the access.

Rakesh