Basic understanding
In the following i will do the question and answer game to develop a basic understanding of the RFC Gateway, the RFC Gateway security and its related terms.
What is the RFC Gateway?
The RFC Gateway can be seen as a communication middleware. The RFC Gateway act as an RFC Server which enables RFC function modules to be used by RFC clients. It also enables communication between work or server processes of SAP NetWeaver AS and external programs.
From a technical perspective the RFC Gateway is a SAP kernel process running on OS level as user <SAPSID>adm.
Where can we find the RFC Gateway?
There are three places where we can find an RFC Gateway:
◉ In SAP NetWeaver Application Server ABAP: Every Application Server has a built-in RFC Gateway.
◉ In SAP NetWeaver Application Server Java: The SCS instance has a built-in RFC Gateway.
◉ The Stand-alone RFC Gateway: As a dedicated RFC Gateway serving for various RFC clients or as an additional component which may be used to extend a SAP NW AS ABAP or AS Java system.
Who can access the RFC Gateway in general
The RFC Gateway is by default reachable via the services ‘sapgw<InstNo>’ and ‘sapgw<InstNo>s’ which can be mapped to the ports ’33<InstNo>’ and ’48<InstNo>’. Access to this ports is typically restricted on network level.
There may also be an ACL in place which controls access. The location of this ACL can be defined by parameter ‘gw/acl_info’.
Which usage types are there?
This diagram shows all use-cases except `Proxy to other RFC Gateways´.
‘Registered external RFC Servers’
The RFC Gateway allows to register ‘external RFC Server programs’ (also known as ‘Registered Server’ or ‘Registered Server Program’) to itself and allows RFC clients to consume the functions offered by these programs.
An example would be the program ‘Trex_<SID>_<timestamp>’ registered at the RFC Gateway of the SAP NW AS ABAP by the server running SAP TREX.
Another example would be the program ‘IGS.<SID>’ registered by the SAP IGS running on the SAP NW AS ABAP which runs on the same server as the RFC Gateway (since it is part of it).
‘Started external RFC Servers’
The RFC Gateway is also capable to start programs on the OS level.
Common examples are ‘tp’ for transport management via STMS or ‘gnetx.exe’ for the graphical screen painter on the SAP GUI client host.
There may be some cases where starting a program is used to register a ‘Registered Server Program’ at the RFC Gateway. In these cases the program started by the RFC Gateway may also be the program which tries to register to the same RFC Gateway.
Please note: One should be aware that starting a program using the RFC Gateway is an interactive task. This means the call of a program is always waiting for an answer before it times out. If the called program is not an RFC enabled program (compiled with the SAP RFC library) the call will time out, but the program is still left running on the OS level!
To overcome this issue the RFC enabled program ‘SAPXPG’ can be used as a wrapper to call any OS command. This is for example used by AS ABAP when starting external commands using transaction SM49/SM69.
Typically remote servers start the to-be-registered program on the OS level by themselves.
‘RFC destinations’
Most common use-case is the SAP-to-SAP communication, in other words communication via RFC connections between SAP NetWeaver AS systems, but also communication from RFC clients using the SAP Java Connector (JCo) or the SAP .NET Connector (NCo) to SAP NetWeaver AS systems.
The RFC Gateway hands over the request from the RFC client to the dispatcher which assigns it to a work process (AS ABAP) or to a server process (AS JAVA).
‘Proxy to other RFC Gateways’
The RFC Gateway can also be used to proxy requests from one RFC Gateway to another.
For example system AAA is not allowed to communicate directly with system BBB but both are allowed to communicate with system PXY. System AAA may send the request to system PXY which will forward it to system BBB to circumvent the restrictions.
What about the reginfo ACL?
The reginfo file is holding rules controlling which remote servers (based on their hostname/ip-address) are allowed to either register, access or cancel which ‘Registered Server Programs’ (based on their program alias (also known as ‘TP name’)).
Its location is defined by parameter ‘gw/reg_info’.
In case of SAP NW AS ABAP for example it may be defined as ‘$(DIR_GLOBAL)$(DIR_SEP)security$(DIR_SEP)data$(DIR_SEP)$(FN_REG_INFO)’ to make sure all RFC Gateways of the application servers of the same system rely on the same configuration.
What about the secinfo ACL?
The secinfo file is holding rules controlling which programs (based on their executable name or fullpath, if not in $PATH) can be started by which user calling from which host(s) (based on its hostname/ip-address) to which RFC Gateway server(s) (based on their hostname/ip-address).
Its location is defined by parameter ‘gw/sec_info’.
In case of SAP NW AS ABAP for example it may be defined as ‘$(DIR_GLOBAL)$(DIR_SEP)security$(DIR_SEP)data$(DIR_SEP)$(FN_SEC_INFO)’ to make sure all RFC Gateways of the application servers of the same system rely on the same configuration.
How are reginfo and secinfo related?
As we learnt before the reginfo and secinfo are defining rules for very different use-cases, so they are not related.
What about the prxyinfo ACL?
The prxyinfo file is holding rules controlling which source systems are allowed to talk to which destination systems over the current RFC Gateway (based on their hostname/ip-address).
Its location is defined by parameter ‘gw/prxy_info’.
In case of SAP NW AS ABAP for example it may be defined as ‘$(DIR_GLOBAL)$(DIR_SEP)security$(DIR_SEP)data$(DIR_SEP)$(FN_PRXY_INFO)’ to make sure all RFC Gateways of the application servers of the same system rely on the same configuration.
Wait! What about the SNC System ACL?
RFCs between two SAP NetWeaver AS ABAP or between RFC clients using JCo/NCo and the RFC Gateway are typically controlled on network level only. The RFC Gateway does not perform any additional security checks.
When using SNC to secure RFC destinations on AS ABAP the so called ‘SNC System ACL’, also known as ‘System Authentication’ – where imho the term ‘Authentication’ is misleading -, is introduced and must be maintained accordingly.
This ACL is applied on the ABAP layer and is maintained in transaction SNC0.
No comments:
Post a Comment