S_RFCACL - RFC_SYSID values transport or maintain directly in each system?

[former_member348001]

I have a sort of Best Practice question about the S_RFCACL object.

As all our authorisation roles are created in Development and then transported across Quality to Production, the object S_RFCACL, which is needed for our users, is maintained also with the relevant Development, Quality and Production system IDs in the field RFC_SYSID.

This field contains the source Development, Quality and Production system IDs to enable the trusted RFC for our users in each of these systems.

I would like to have the source Production system ID in S_RFCACL ONLY in the target Production system, similarly for the source Quality and source Development system. So that trusted RFC connections are definitely only possible from source Production system to target Production system.

This would mean that S_RFCACL would have to maintained directly in each of the target systems, instead of transporting it.

How do you handle this object, this field RFC_SYSID in particular?

[Private_Member_69416]

Hi

If you want to have trusted connection P->P only, you have to maintain RFC_CLIENT and RFC_SYSID  directly.

Transporting global values can give you access D->P and Q->P (if trusting is set in SMT1 )

Regards

Przemek

[jurjen_heeck]

Hi Anja,

What I do is create an instance of S_RFCACL for each system (DEV/TEST/PROD), transport the roles and then disable the instances I don't need on each system afterwards.

Jurjen

[former_member348001]

Hi Jurjen,

So, you actually then modify the roles in each system, in TEST and in PROD?

Do you create separate roles with the separate S_RFCACL values for each of the systems? Or do you create one role, with separate authorisations for each system, which you then deactivate in TEST and PROD?

Thing is that the Governance, Risk and Compliance department in my company is against me updating roles directly in TEST and PROD.

[jurjen_heeck]

Hi Anja,

I use the second option, one role with multiple instances.

An alternative could be to create a separate role for each system and work with a naming convention to avoid assignment on the 'wrong' system.  I myself would try to convince the GRC folks these transports are incidental and just need a bit of aftercare.

Jurjen

[Former Member]

The transport process is not incidental and you should definitely not be updating roles in your downstream environments.

Doing this causes numerous negative consequences when you need to make future updates to user access or go through SAP upgrades.   If you are not aware of direct changes made to PRD and QAS environments for your users then you are invalidating any testing that went into the creation of the role.  You are also more likely to break user access if you update a role in DEV to transport it through and thus over-write a change you are someone else made in PRD.

SAP has gone to great lengths to detail why you should not do this, as well as to release notes to the Security public at large on how to restrict your roles appropriately in PRD and QAS so that you cannot update a role in those environments thus ensuring com pliancy for you and your Security team in PRD.

@Anja:   The previous suggestion of creating a separate role for PRD/QAS/DEV with the relevant Sys ID or Client/Domain restrictions is a good one.

If your end users require this access for direct calls to other systems once in PRD but these need to be validated during testing in the QAS environment you could always just create your PRD ready role with the required variants which would be assigned to those users and for your DEV and QAS environments a "Project Level" role that opens up the access of that and other items as needed to ensure testing goes smoothly and which can be assigned as needed in those environments.

[former_member348001]

I understand what you are saying;

However, practically, this means then that all users in our QAS and DEV environment would have to be assigned different roles than in PRD; as we use a trusted RFC from our CRM system to our ERP system, to display quotes, so all our users hold the trusted RFC object S_RFCACL.

Is that not extremely cumbersome?

And we use composite roles, so if I have to create separate roles for S_RFCACL for each system, I would also have to create separate composite roles ???, as the S_RFCACL is included in a single role.

The thing is that I do not see how I can pratically work with separate S_RFCACL for each system ...

I do appreciate your further suggestions.

[Former Member]

Anja,

Yes you do have to manage the users separately sometimes in your differing systems, but if the only difference is the RFC connectivity then you only need to create a single role with that required attribute.

Remember role security is cumulative and a composite role is only a container.  You could just as easily assign the 20 single roles in that composite and get the same affect to a user...you do not have to create a composite role for every single role you maintain. 

From a realistic prospective, your main end user population will only require access to your QAS environment for testing and validation purposes and that population should be small since only a few designated users will be doing validation and testing in QAS.      The DEV environment is just that, for development.    The user base in there should be even smaller then QAS as very few "end users" will be working on development projects in there...this is were your support personnel will be mainly working.

If you find yourself loading all of your PRD users into QAS and DEV then I would really question what the purpose is for.    

I would also say that since these systems will most likely not contain any sensitive data then you may only need one role that contains S_RFCACL with both the QAS and DEV systems identified so that you know those users when assigned this single role will get that access.

does this make sense?

[Former Member]

On a side note:   Can your developers not configure these secondary system queries to use a secure system account and pass through the users request and credentials to the CRM system for authorizations and then publish those results back?    Some one with more experience then me may be able to answer that but I don't think you technically have to use the logged on user to make the jump to the other system for the report....and RFC can be used to open the connection and start the process and then pass the users ID over for authorization approval of the specific request.

[Former Member]

This is correct.

You can use a fixed SYSTEM user for the connection as long as there are no dialogs involved. In some earlier system releases the screen calls were programmed into the search help RFC functions instead of returning the results to a calling screen. D'oh..

In that case the SYSTEM user is fixed into the connection and can call FM AUTHORITY_CHECK with the FOR_USER parameter as the DIALOG user. The SYSTEM user will determine the DIALOG user's application authorizations without them having to be logged onto the remote system nor have the Trusted RFC authorizations not QRFC to setup the Trusted connections from anywhere else.

Much like field FILE of S_DATASET without using logical file names, the RFC_SYSID is actually just an irritation and it is more reliable and pragmatic to use other fields and S_RFC and the existence of the connection, than break your roles because of a field which is very difficult to control anyway and needs to be maintained in production (and also VERY and RELIABLY fast if you ever transport the role again because of some other change..).

My advice: put a * in the field and concentrate on other more important things with higher risk and impact and probability, until your concept is secure enough that you can take on this field.

Cheers,

Julius