Assigning a reference user locally in combo with CUA

[Former Member]

Dear gurus,

I have an Emergency User solution which keeps the current user context plus all personalization contexts, queries, HR, analysis auths, etc etc by assigning only a delta authorization via the indirect reference user concept.

This works fine, but I am now confronted by a CUA environment which wants to use it - and local changes are not allowed.

The solution is exclusively BAPI based, but user BAPIs are 1:1 with the transaction equivalents (SU01 etc) so I cannot assign the reference user as it is considered the same as roles or profiles for user admin.

I know some of the "dark horses" for working around this but was hoping there is some BAPI exception for reference user assignment, or a SCUM config option without opening SU01 etc at the same time.

An attempt I made was to call via the CUA master to assign the reference user for the system requesting the access, but that does not work reliably, there are too many IDOCs involved and forces the system CUA RFC user for the text comparison into more access if that approach is used (fair enough to assume for others as the caller would otherwise need their own access on the CUA master...)

Plan B is to wait 6 months and then ditch the CUA in favour of IdM going live, but I still want to get it to work.

Does anyone have another idea to simply and sustainably to do this locally with CUA active?

Cheers,

Julius

[Former Member]

I'm stumped on this one. Personally I would think it brings a good case for allowing changes via SCUM and then providing additional restrictions.

[Former Member]

Thanks Alex.

Yes that is true, but the missing create, add, etc buttons are so idiot proof and that does have it's advantages..

The customer will have to give it up anyway at some stage when they switch to IdM after the role cleanup phase, and then "providing additional restrictions" must be in place anyway.

As there is only one field for reference users and only one reference user can be assigned at any point in time, I think the option of a locally assigned reference user would be usefull anyway. Otherwise you are forced to assign it in the master and for all child systems (!). I don't want that nor the end users on the CUA.

Cheers,

Julius

[Former Member]

> I know some of the "dark horses" for working around this but was hoping there is some BAPI exception or a SCUM config option...

Uahh, you see. Sooner or later these are not reliable: [SAP Note 1406435 - Missing authorization check in FM PRGN_INTERFACE_USER|https://service.sap.com/sap/support/notes/1406435]

Cheers,

Julius

[Former Member]

Hi Julius,

Not sure if I have understood this question correctly, so will rephrase it in my words -

For Emergency access you have Reference user id and in case somebody needs additional access you add this delta access to Reference user id and then add the Reference user id to this user. It was working properly as CUA was not involved. But now there is this CUA and you cannot add the reference user ids locally to child systems. It has to be added from the central system but should only be added to the one particular child system where emergency access is required by the user.

If this is the correct question and we do not have SCUM settings for it to change it locally then it might makes sense to have this in the wishlist but then you can always make use of delta roles instead of Reference user id and role change can be done locally.

Nevertheless I can still think of one crude solution where you create unique Refrence user ids in all your child system which is unique to that particualr child system. So Child System A will have Reference user id REF-A, Child system B has REF-B and so on..but REF-A should not be in Child System B or any other child system. Similarly REF-B should not be in any child system except B.

Now when you add a Reference user id REF-A in Central System for say child system A, it will get reflected in System A as this user id REF-A exist there but will not get reflected in any other child system as REF-A does not exist.

Edited by: Nishant Sourabh on Apr 6, 2010 11:20 PM

[Former Member]

Hi Nishant,

Thank you for the suggestion.

Yes, it is possible to block the distribution of the reference user and additionally subject to the role of the reference user - but that is the problem here as well --> the roles are application specific and not just "SAP_ALL minus a little bit".

They are for exception handling and I want to keep the users off the CUA as the do not necessarily need access to it. They can request it themselves locally in the managed system and complete the task with the delta access. Only reporting (on SM20 and SM21) is central via SolMan, but now CUA got in the way

The option of remote menu's and RFC callbacks is much too complicated, considering that the basic requirement is pretty easy and the rest of the solution is based only on stable BAPI's and BP exceptions for some events.

I am also considering transaction variants for SU01 as an interim solution. That, combined with restricting local access to user management generally seems to be the easiest option.

Unfortunately there are some legacy profiles and roles and we need to offer a better alternative before they give it up.

Cheers,

Julius

[Bernhard_SAP]

Hi Julius,

maybe I am completely wrong now because I did not get exactly what you want to achieve, but from my understanding the SCUM solution should work... For instance set the setting for reference user to 'Proposal'. As soon the User_ID exists already in the child, the field 'reference user' will not be touched anymore by CUA distribution. Only local SU01 or locally executed user-bapis will be able to change the field. So in that case, it will be possible to change the reference user locally, w/o including the CUA simply by local bapis. Isn't it that what you want to achieve?

b.rgds, Bernhard

[Former Member]

Thanks Bernhard,

If I open the Reference user to Proposal in SCUM, then SU01 users could locally change these as well if permitted to assign the roles and profiles of the reference user.

As reference user assignment is functionally the same as a role / profile assignment and makes the same checks, I incorrectly assumed that we would have to open the role and profile screens for local administration as well. But that is not the case it seems. The reference user's own authorizations are not changing - so it is fine!

> locally executed user-bapis will be able to change the field

Yep, but we don't want the end user to be able to do this on their own - should they find some way to access SU01 or some other function modules, etc.

So the BAPI can be called locally, but via a "destination engine" with the authorizations to keep the users of the application well out of the user management and SU01 anyway.

Thanks for clarifying my misinterpretation!

Cheers,

Julius