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: 

Is S_RFCACL a critical Authorization Object ?

Former Member
0 Kudos

Hi All,

As we know that S_RFCACL (Authorization Check for RFC User (e.g. Trusted System)) is required for having access to the trusted systems.

In most of our roles for this authorization Object we have maintained the * value for the following fields:-

RFC_SYSID

RFC_TCODE


This has been made as an observation by the auditors as having this critical access with the users.


But my question is how can it be the critical access when the user should have id's in both the systems(trusted and trusting) to login to the called system.

Also even if the user logs into the called system he will only be able to execute the list activities/t-codes that he is authorized to in that system, it will override the * value maintained in RFC_TCODE.


What possibly could be the risk from this authorization object ?



Regards,

Parichay

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Parichay Jain wrote:

In most of our roles for this authorization Object we have maintained the * value for the following fields:-

RFC_SYSID

RFC_TCODE


This has been made as an observation by the auditors as having this critical access with the users.



The object itself is certainly critical, but as you stated the trust itself has to have been setup at the system level for the authorization to be going anywhere.

These two fields are in all honesty only irritating and you can successfully defend putting a * into them.

RFC_SYSID values for a role means you unit test a role in DEV, integration test in in QAS and then use it live in PROD. Additionally the field RFC_INFO is actually the installation number and you can be fairly sure that will be the same in the landscape. So only adding the pairs of production system IDs means you cannot test the same roles, which is a bit silly.

RFC_TCODE is even sillier. The generic RFCs for starting transactions (eg. ABAP4_CALL_TRANSACTION) check the transaction code themselves again and that is then user specific roles relating to their job functions. Restricting S_RFCACL additionally in a system role (eg. common role for all users) means that you must double-discriminate against all possible transactions which can be called via RFC and list them all there and maintain the list. But the check happens later again and the application authorizations in the transaction are generally checked as well. Waste of time.

@ Alex: The RFC_EQUSER = Y field only means that if the calling and called user ID names are the same, then the field RFC_USER is not checked and therefore does not have to be maintained. But it is often misunderstood and the field RFC_USER gets a * value as well (which is where the real music is..) and the EQUSER setting has no further affect. Technically, it actually weakens the authority-check on the user field - which is correct because otherwise you have to maintain it and end up with personalized roles, which is most silly of all.

So you can quite safely tell you auditor that Julius agrees with you and they are barking up the wrong tree..  🙂

Cheers,

Julius

6 REPLIES 6

Former Member
0 Kudos

Hi

Putting it in context, it is critical enough as to be excluded from SAP_ALL as standard.

Have a look at SAP Note 1416085 - a snippet of which is:  "...If you enter the full authorization (*) in one or more of these three fields, you allow the logon from any system, client, or any user, and as a result, you may produce significant security risks..."

Former Member
0 Kudos

Thanks for the reply.

But again I have the same concern, I think even if I maintain the * access in the fields of S_RFCACL Authorization Object, the user will not be able to login to any of the system remotely.

1) Trusted relationship has to be set-up between those systems then only the logon is possible.

2) Secondly if after the trusted relationship is set-up, the user would be able to login to the target system(called system) but will be able to execute the transaction to which he is authorize to in that system, irrespective of his authorizations in the calling system.

Therefore I don't see a risk, please let me know if there is any critical risk through this Authorization Object.

0 Kudos

Hi,

1. Correct, however if you don't have a trusted relationship set up then using S_RFCACL is breaching principle of least privilege, is not required and most importantly if misconfigured it could bring a significant risk.

2. That does depend on the rest of your configuration.  If you have RFC_EQUSER = Y then it will force the same ID being used, if you don't you have lost that key control.  If you aren't using trust relationships then you can just do away with it.

So looking at the risks I see the following challenges

- Critical auth present in roles when it's not required: breach of common good practice

- Potential serious risk (depending on how you have configured the rest of the fields) if trusted connections were set up

- Potential risk with current RFC destinations being setup with stored credentials allowing misuse

The reality is that I know the square root of zero about your setup and there are always mitigations & other circumstances however I hope you can see how the auditors came up with their finding.  Considering that it is not required (no trusted connections) and can cause problems then why would you not remove it?

Cheers,

Former Member
0 Kudos

Parichay Jain wrote:

In most of our roles for this authorization Object we have maintained the * value for the following fields:-

RFC_SYSID

RFC_TCODE


This has been made as an observation by the auditors as having this critical access with the users.



The object itself is certainly critical, but as you stated the trust itself has to have been setup at the system level for the authorization to be going anywhere.

These two fields are in all honesty only irritating and you can successfully defend putting a * into them.

RFC_SYSID values for a role means you unit test a role in DEV, integration test in in QAS and then use it live in PROD. Additionally the field RFC_INFO is actually the installation number and you can be fairly sure that will be the same in the landscape. So only adding the pairs of production system IDs means you cannot test the same roles, which is a bit silly.

RFC_TCODE is even sillier. The generic RFCs for starting transactions (eg. ABAP4_CALL_TRANSACTION) check the transaction code themselves again and that is then user specific roles relating to their job functions. Restricting S_RFCACL additionally in a system role (eg. common role for all users) means that you must double-discriminate against all possible transactions which can be called via RFC and list them all there and maintain the list. But the check happens later again and the application authorizations in the transaction are generally checked as well. Waste of time.

@ Alex: The RFC_EQUSER = Y field only means that if the calling and called user ID names are the same, then the field RFC_USER is not checked and therefore does not have to be maintained. But it is often misunderstood and the field RFC_USER gets a * value as well (which is where the real music is..) and the EQUSER setting has no further affect. Technically, it actually weakens the authority-check on the user field - which is correct because otherwise you have to maintain it and end up with personalized roles, which is most silly of all.

So you can quite safely tell you auditor that Julius agrees with you and they are barking up the wrong tree..  🙂

Cheers,

Julius

0 Kudos

@julius I obviously need to re-read some code! thanks.

OP - I still agree with your auditors for the reasons I listed. 

Cheers

0 Kudos

You will have difficulty (re)reading some code in this case - you cannot see it.

But it is fairly well described in the documentation and SAP Note 1416085 also removes the * from the RFC_USER field if it is transferred to it in authorization merges and hard maintenance of it in PFCG will give you a warning message on this field.

Regarding the SYSID - if you are going to maintain it then it makes sense to add the corresponding DEV and QAS systems as well so that you can at least test the roles. That means you authorize the landscape against a trusted landscape so can use the RFC_INFO field. If you want to do it more granularly than that then you must be aware that it will impact the number of system specific roles you need to create and maintain. IMO you should prove to the auditor that you have already fixed all other security risks and this is the next best thing on the list because you are very bored...  🙂

Cheers,

Julius