As I said in a previous post, "Dealing with Authorization Gaps: Part 1," the authorization groups aren't limited to technical data as there are also many related to Business Master Data. The concept of implementation is the same:
Hi! In this post I want to summarize you another little-known behavior of SAP Gateway, which is its ability to act as a proxy. Basically when we want to perform an RFC connection two parameters are specified: the IP of the gateway and the IP of the application server. But wait... Is not the gateway always located in the same host than the application server? Yes, usually... but there are some specific cases where you need to use these parameters with different values.
Hi! Today I wanted to share some insight on the behavior of SAP Gateway using its ACL files. Particularly, I'll focus on the ACL which restricts direct RFC connections to the Gateway (gw/acl_file). Briefly, this ACL does not replace sec_info or reg_info (they restrict external servers), acl_file controls direct RFC connections from external clients or other SAP Systems, which is actually the most common kind of RFC connection. Check this document describing the ACL syntax.
SAP has its own specific JAVA virtual machine implementation called SAPJVM, which according to SAP documentation: "...is derived from Sun’s HotSpot VM and JDK implementation ... the SAP JVM is only targeting server-side applications. Certain features related to client environments are intentionally omitted or are not supported for general use.".
Authorization groups are a difficult topic to tackle in SAP as they can be considered a double-edged sword. With proper implementation it’s possible to take security to the next level, however if not properly implemented, authorization groups can lead to usage issues and can create a false sense of security. These problems arise due to different reasons: