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: 

'Protecting' your derived roles from being maintained on object level

l_borsboom
Active Participant
0 Kudos

I'm redesigning an authorization concept that has been polluted in the past by maintaining object level values in the derived roles instead of the master roles.

Now I would like to build in a kind of warning or authorization so that future role administrators can adjust master roles on object level, and derive the roles from the master, but are not allowed (or get a warning) to change object level values in the derived roles themselves.

I'm looking for a warning similar to the warning you get when you are trying to change an organizational level value within the object rather than change the orglevel table.

I have looked for entries in table PRGN_CUST, but found none.

Also, the authorization checks for deriving roles [seem to be similar|http://help.sap.com/saphelp_nw04/helpdata/en/2b/84653f1b76b11ae10000000a114084/frameset.htm] to actually maintaining a role, so no distinction can be made here.

Knowing al this, II think the answer is: 'no, this is not possible' but if you have dealt with the same problem successfully, please let me know.

Kind regards,

Lodewijk Borsboom

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Lodewijk,

yes this possible.

you can prevent users from changing derived roles.

it need custom coding, similar to one done in Risk Terminator.

Risk Terminator is GRC (VIRSA) product, it don't allow user to generate a role in PFCG if it have conflicts.

it's BAPI's or User exist are maintained in table SSM_CUST table (via SM30).

i will suggest , contact Custom Development team of SAP and ask them to written code for your org on same pattern as done in GRC product.

hope this help.

Regards,

Surpreet Bal

13 REPLIES 13

jurjen_heeck
Active Contributor
0 Kudos

Hi Lodewijk!

If you cannot protect this, maybe you can (have someone) create a report which detects these unwanted changes so you can address the issue with the person responsible.

A blunt force method would be to run SUPRN_REGENERATE_DEPENDENT over each parent on a regular basis, or based on change document triggers. This fixes all pollution and probabely will send the message to anyone meddling with the child roles that this is not a lasting solution. Hopefully they'll give up

Just my 2ct

Jurjen

Edited by: Jurjen Heeck on Sep 17, 2010 12:28 PM

0 Kudos

I am looking for a table / table field in which I can distinguish between changes on object levels that have been made through the master/parent role and change which are made in the derived role itsself so I have the basis for a report for this issue.

Lodewijk

0 Kudos

i thought the "object status" in AGR_1251 would help - did you try that already?

Former Member
0 Kudos

Hi Lodewijk,

My only thoughts are that you (or a developer) may be able to find an enhancement point in the PFCG code that can be triggered at an appropriate point (preferably before the change is committed).

Otherwise a detective report could be an option. Once the offenders have been chastised once, maybe they will start to adopt more compliant behaviours...

Former Member
0 Kudos

Hi Lodewijk,

There are exit paths in SU01 and PFCG which might (have) help(ed) but SAP removed the documentation on them because as (to my knowledge) as the code was integrated into BAPIs and org. management these exits (like many which have gone before them) caused no end to confusion over time.

I heard that they would at some ponit be replaced by BADI's but I guess the same problem exists there and I have to date not seem any of them released.

I have the documentation if you are interested but which release are you on? I suspect that SAP might even remove the exit coding anyway.

As the other's have stated, I would also go for a detective control. You can always wipe the mistake out again from the master and this will let you know that someone is not sticking to the rules or doesn't understand the concept.

This is also an advantage when compared to an error message or warning which only they see...

Cheers,

Julius

0 Kudos

Hi

I like the SUPRN_REGENERATE_DEPENDENT option! It's all too easy to go in and mod a role in the auths tab following an Irate call/SU53, generate and then transport to then see that there's a parent role sitting in the queue too.

I really do hate derived roles anyway as they are prone to beggering up cost centres, storage locations and purchase groups (I should have said release strategies - another grey moment...) when you least expect it.

I'm not sure yet how GRC's role building tool will be set up to handle these but that may be an option if you don't actually load the derived roles into it. Unfortunately that means you have to go directly to R3 and update org levels in each derived.

I'm going to try that SUPRN_REGENERATE_DEPENDENT the next time I get a chance!

Regards

David

Edited by: David Berry on Sep 19, 2010 1:48 AM

0 Kudos

> It's all too easy to go in and mod a role in the auths tab following an Irate call/SU53, generate and then transport to then see that there's a parent role sitting in the queue too.

Good naming conventions can play a role in warning the innocent here. If derived roles are easily recognisable by name these mistakes are made less often. It's the ignorant people posing the real danger, they don't even notice the parent in the transport

0 Kudos

Hi

Just had a play in DEV and the parent role,adjust derived resets the objects' field values to match the parent - just the org levels remain unchanged. Been some months since I messed with derived roles so I'm getting a bit rusty

Still hate derived roles though

0 Kudos

Hi Julius,

I am interested in your docs on this SSM_CUST exit. We are at SAPKB70020.

Thanks!

Lodewijk

Former Member
0 Kudos

Lodewijk,

yes this possible.

you can prevent users from changing derived roles.

it need custom coding, similar to one done in Risk Terminator.

Risk Terminator is GRC (VIRSA) product, it don't allow user to generate a role in PFCG if it have conflicts.

it's BAPI's or User exist are maintained in table SSM_CUST table (via SM30).

i will suggest , contact Custom Development team of SAP and ask them to written code for your org on same pattern as done in GRC product.

hope this help.

Regards,

Surpreet Bal

0 Kudos

Hi

Disabling the authorisations tab in derived roles...

What if you need to maintain a cost centre, release strategy or storage location - would these then be excluded from the derived roles option?

Cost centres and release strategies are two of my pet hates in derived.

0 Kudos

> Disabling the authorisations tab in derived roles...

How do you propose to do that? Especially without blocking the initial build of a derived role?

0 Kudos

There is an exit when you save in PFCG. You can call a custom function named in ssm_cust (at the bottom) to validate that only standard and maintained authorizations are present, or at least no changed ones.

You can do this on your own but you must be carefull! It can easily interfere with SU25 and SUPC!

But these exits are not documented anymore and used at own risk as far as I know because they don't abstract between the calling programs. This means testing the same thing might give you different results the second time round.

Cheers,

Julius