Un-merging authorization instances in PFCG - any tricks for re-use?

[Former Member]

Dear gurus

I encounter the situation sometimes where not maintaining the ACTVT field in SU24 is tempting for some objects (S_TABU_DIS is a nice example) and then maintain it in the role. This works fine, even although ACTVT is generally a usefull transaction related field to maintain in SU24.

The bugger is now that some transactions propose ACTVT's already as well and they are okay if that is all we ever wanted the transaction to do. SAP delivers it the same way often... but any display access to such tcodes (such as current setting views) are then merged into the authorizations of all likewise proposals which are complete.

To simulate an "unmerge" button I use different tricks bepending on the use case, but wanted to know whether someone has a better solution.

1) Add a dummy of sorts to SU24 and open the role in expert mode. Save and exit in all roles, remove the dummy and re-enter the authorizations tab --> SAP forgets about the prior merge.

2) It is often usefull to have a symbolic transaction for the sole purpose of assigning standard authorizations to a series of roles where no real executable transaction code exists. So we switch the SU24 proposals to these tcodes and maintain the ACTVT there. This works well for stuff like "batch job roles" but not for end users and many parameter transactions.

3) Manually...

4) Copied and Changed...

There must be a better way and all of these, even although it does not happen very often...

Perhaps just right of the "merge" button there is some hidden function code to unmerge again...?

Cheers,

Julius

[Former Member]

Hi Julius,

for long term maintaince its better to maintain values in su24(USOBT_C). There should not be changed or manual auth objects present in the role.

or

Copy the existing standard instance and change it to what ever values. Plus point is, next time when u come thru export mode

you will not get new instance added to the role.

As said Merge / unmerge are good. Minus point, when u come thru export mode you will get new instance added to the role.

Thanks,

Sri

[Bernhard_SAP]

HI,

technically 'unmerge' is not possible, as there is no history stored. So after merging we don't know anymore, how the actual authroizations have been composed. So how to decide then of how to divide the existing auths? Create new ones based on existing SU24 values and others with the 'maintained/added/changed'-values? The only thing I could imagine would be the possibility to switch off any merging and simply copy the su24 values into pfcg. But then the profile will get large very quickly and admins will have to go through many of authorizations for checking....

Propably this is a case for https://wiki.sdn.sap.com/wiki/display/Security/SecurityFunctionalityWishlist-Topics - but I am pessimistic that SAP will change something at this point

b.rgds, Bernhard

[Former Member]

> So after merging we don't know anymore, how the actual authroizations have been composed. So how to decide then of how to divide the existing auths?

How about a solution which unmerged all authorizations and a popup appears that all maintained values will appear in all authorizations.

Imagine that (just delete the unwanted ones) to the completeness of the F4 search help on some BEGRU typed fields...?

I think we have a winner here. Hopefully I am not alone doing upgrades the correct way for existing roles which are well built to start with...

https://wiki.sdn.sap.com/wiki/display/Security/UnmergefunctioninPFCGforchangingyourmindandnotthe+authorization

Cheers,

Julius

Edited by: Julius Bussche on Jul 29, 2010 8:30 PM

Wiki link added

[Former Member]

It turns out that this function was implemented once before and caused considerable confusion - SDN is perhaps a good benchmark for this possibility...

However, as I stated before it happens very seldom so the benefits do not outweigh the development effort and... confusion.

So here is my solution for those who might face this problem one day:

1) Identify the transaction from which you want the differentiated authorization instance.

2) In SU24 maintain a value (I use 'Banana' for free text or another value in an obscure field which you don't use and is * as maintained.

3) Open the role in expert mode to read the new values. Save and exit.

4) Go back to Su24 and remove the "Banana".

5) Open the role using the "Change" option without merging. Nothing changed in the menu so you are okay and the authorization is available. Maintain your value sets for the fields. Save and generate.

You can also do this for multiple roles by performing step 3 for them all from SU25 or SUPC, but it is only for the brave...

Step 5 is potentially a task for a lazy afternoon after having a good lunch...

Hope this helps anyone else who encounters the same oneday.

Cheers,

Julius

[Former Member]

Hi Julius, In the situation you have described & usually for very limited number of auth objects, I use manually entered auth objects.

There are a few rules though...

1. Use is documented in the role commentary

2. A manual entry always supports a standard entry.

The thoughts behind this is:

1. Traceability over the origin (and why it was not updated in SU24).

2. If there is a manual entry but no standard entry, that manual entry should not be in the role.

[Former Member]

Thanks all for the comments so far.

@ Sri: I avoid "changed" authorizations at all costs, with the only exception being SPRO project roles and then proceed exactly as you have described. But that is not the case here for already merged maintained authorizations which I want to un-merge again.

@ Alex: Not one single manual authorization in this system so far, otherwise I have to eat my hat

@ Bernhard: Yep, exactly that missing history is why I can use a temporary SU24 value to pull the one proposal out again and then remove it without the system remembering that it once was merged. As we can selectively merge authorizations individually (before the "read old, merge new" does it anyway in bulk) I was hoping for a trick to un-merge individually for the cases where I change my mind or the exact requirement becomes known after the exert mode merge.

It doesn't happen that often, but would be a nice to have for objects such as S_TABU_DIS where the ACTVT isn't always proposed of wanted.

I will leave it open for a while to see whether there is a better trick than mine and then consider a wish-list entry.

Cheers,

Julius

[Former Member]

>

> @ Alex: Not one single manual authorization in this system so far, otherwise I have to eat my hat 
> 

You want to be careful with that...you know what happened last time 😛

[Former Member]

That is why I want an un-merge button for individual objects already merged to make the overview easier. The SU24 trick takes too long (unnecessary IMO) and the customer bought me a construction helmet in anticipation of what Bernhard has predicted..

I will try my luck via SAP Note 11 - that which does not kill you only makes you stronger!

Cheers,

Julius

[Former Member]

> That is why I want an un-merge button for individual objects already merged to make the overview easier.

I found another use-case where this missing unmerge button is a big pain: When globally deactived authorization objects in transaction AUTH_SWITCH_OBJECTS exist to "simplify the concept" and later realize that this is not a good idea, then you activate them again --> the system now pulls all proposals in for EXISTING menu transactions which were previously ignored an not proposed.

No matter how you open the authorization data tab, the system merges the authorizations together where the fields are maintained the same as well as those which are the same because they are empty .

A button to unmerge these authorizations for the now active object is exactly what is needed.

Can we bounce this off IF SY-UNAME(3) = 'LEI' OR IF SY-UNAME(3) = 'ROJ' for an opinion?

Cheers,

Julius