In our latest ASUG Asks the Authors feature, we sat down with Alessandro Banzer, CEO of Xiting, and Alexander Sambill, a senior SAP security consultant and certified SAP trainer at Xiting. The two wrote the SAP Press book, “Authorizations in SAP S/4HANA and SAP Fiori.”

In this first part of our conversation, we examine the importance of authorizations, review the hurdles that customers often encounter regarding authorizations, and learn how Xiting can help SAP customers.

This is an edited transcript of our conversation.

Q: Can you give us an overview of SAP authorizations? Why are they so important to those SAP users, especially those using the SAP Business Suite?

Alexander: You have to keep in mind that authorizations enable end users to perform activities in the SAP system. Even accessing the SAP system with your credentials is based on authorizations. Authorizations are the lowest common denominator in an SAP Business Suite Authorization Concept. They control what functions an end user can execute and which data records they have access to. They protect your entire system. It doesn’t matter whether you are an administrator, a business end user, or a key user. You typically have responsibilities or tasks for different job functions or user groups. All users require specific authorizations to enter specific functions or to do their intended duties in the system.

Authorizations enable users to use the system, and on the other side, they prevent unintentional or malicious access. That’s all based on the Advanced Business Application Programming (ABAP) code. Even with SAP Fiori, with all the UI5 (based on HTML) functions you can now use, you are indirectly working at the back end with the ABAP code, where the core programs are processing the specific end-user calls. The developers implement different authority checks. You require the appropriate authorizations to pass these authority checks. It’s very important to note that SAP S/4HANA isn’t just an upgrade. And that’s why you must migrate your former authorization concept from SAP ERP into an SAP S/4HANA authorization concept. You have to consider when you integrate the new SAP S/4HANA software. SAP S/4HANA is a new product with additional and new authorization components. It doesn’t mean that the entire authorization concept of SAP ERP is outdated, but a one-by-one transition is impossible.

If you want to use SAP Fiori 3.0, you will encounter new authorization components such as SAP Fiori business catalogs, SAP Fiori groups, spaces and pages, Internet Communication Framework (ICF) nodes, and Odata services. For example, that means you have to activate ICF nodes and Odata services, as well as authorize the end users for these services in their job functions. Furthermore, besides the former back-end authorizations, there are also many new components in the SAP Fiori authorization context that you have to consider.

Q: What are some of the common hurdles that customers are encountering when they’re designing authorization concepts? How can they avoid some of these hurdles?

Alexander: There are many hurdles and widespread factors that might challenge you during your authorization concept design phase. It doesn’t matter which software solution you are talking about—it’s common for all. Generally, every company has to observe the internal and external regulations that affect how the access model is designed and how access is granted to users. On the one hand, you have external and internal regulations or requirements such as legal obligations, industry standards, good manufacturing practice requirements, and certifications. Internal requirements might be the internal control of financial reporting or internal policies and principles. It is useful for heading the least leveraged principle, so the users should only have the authorizations for their required duties or tasks. This is also known as the need-to-know principle. But on the other side, not all of these requirements will be necessary for access management in its entirety, especially regarding specific cases. Keep in mind that a technical transfer capacity from pure business demands to the system is also necessary.

Next to the internal and external requirements, I would say that the authorization concept must also fit the company’s goals. This involves more than the customer standards and principles that they should include. One example: updating your risk-based authorization management with SAP Identity Access Governance. Your company’s goal might be standardizing your role concept to be secure and aligned with some risk-based regulations for those goals. Another example: changes to your organizational structure or implementing new software such as SAP S/4HANA might also be considered in your authorization concept design. Additionally, always think about security, but also focus on the maintainability and sustainability of your concept. Last but not least, it must function with a well-maintained security level. Your conceptual approaches should always be in harmony with the cost-benefit ratio.

Q: In the fourth chapter, you both specifically focus on the Xiting Authorizations Management Suite. Please tell me about this solution. How does it fit into the SAP PartnerEdge? How does that help SAP customers?

Alessandro: As Alex already mentioned, SAP customers face a lot of hurdles and problems when trying to safely and effectively maintain an authorization concept. Xiting has developed a solution that’s called the Xiting Authorizations Management Suite, which is a standardized solution that SAP also recommends. There’s an SAP note that encourages SAP customers to use this third-party solution as the best-practices tool for authorization redesigns and hardening—especially in the area of RFCs that are very difficult to harden—to properly secure and authorize. At the end of the day, it’s a third-party solution that SAP recommends. It’s also SAP certified. If you’re an SAP S/4HANA customer or an SAP S/4HANA Private Cloud customer, the tools are fully certified. They’re widely used. Ultimately, these tools try to make authorizations management simpler—simultaneously more efficient and more secure. So it’s all about automating and simplifying to address all those hurdles that Alex mentioned before. It’s about using tool-driven approaches. Then customers can rest assured that the security is in place and that they’re not spending too much money and too much time—or using too many resources—in securing the entire environment.

Q: From a security perspective, why are authorization default values so vital?

Alexander: The authorization default values are indeed so important, but unfortunately, not so in the minds of our customers. It’s kind of sad because these are so essential for every authorization concept. Generally, as mentioned above, in every SAP Standard Application, authority checks are implemented. These code statements protect data access or function access. Based on these checks, SAP also delivers a ready-to-use authorization bundle for each application. These bundles are called authorization default values, also known as proposals. They depict the minimum authorization requirements needed to successfully pass the application’s source-code authority checks for the function or data access. The authority checks that the system processes are based on which specific program functions (code lines in detail) of the application that the end-users are using.

The advantages of authorization default values allow you to directly and easily maintain the proper authorizations that end users require by using the SAP standard. For executing or accessing anything, you don’t need to find and maintain necessary authorization objects manually because SAP already did this for you. It’s a huge advantage to use the proposals by only maintaining the application in the role menu. The system then automatically integrates the required authorizations into your role profile. Further, it is not only a code-based maintenance but also a secure, sustainable maintenance. For every system upgrade with new authorization checks, you can more or less automatically integrate the new setting. Besides, you also have a direct link between the existing authorizations in the role profile and the correlating applications.

In a manual approach, this isn’t all useable. Using manual authorizations or forgetting to maintain proposals for your specific business needs is bad, and not the best practice or the SAP standard in most cases. To save time, be secure, and have the correct authorization setting in your end-user roles, use the authorization default values (Transaction SU24).