Exercitation ullamco laboris nis aliquip sed conseqrure dolorn repreh deris ptate velit ecepteur duis.
Close
The basics of SAP access
AuthorisationsA quick introduction on how users get access into SAP
Having spent years working in the area of SAP authorisations, we realise that there is often a (wide) gap between the business (who need the access) and IT (who need to maintain and provision access to these users). Such gaps often result in miscommunication and a lack of common understanding. This could lead to inefficient, or worse, ineffective business access into SAP, with direct impact on the flow of the business.
While the maintenance of SAP is typically the responsibility of IT, the ownership of SAP lies within the business. SAP should be configured to reflect how the business wants to conduct its operations and users should also be granted access according to business requirements – this is why every SAP implementation and application changes have to be signed off by the business.
It is therefore useful for business stakeholders to understand, at least at a high-level, how access is gained into SAP. This blog post covers how typically a user can enter SAP and carry out a task. A more technical blog post, which dives into the world of authorisation objects in SAP, is also available here for those who want to get a more understanding knowledge in this area.
Logging into SAP
All SAP users have a unique user-ID. In order to log into SAP, the user has to enter their user-ID and corresponding password.
Alternatively, single sign-on may be used: This is when SAP authentication is tied to the user’s authentication into Active Directory (i.e., their company network). When single sign-on is used, SAP password is deactivated and their Active Directory user-ID is mapped to their SAP user-ID. When the user starts the SAP application, SAP will recognise their SAP user-ID based on their Active Directory’s login details.
A company will usually only allow one login method for its users, with the exception given of its IT users, who can usually login to the SAP application directly via their user-ID and password, even when single sign-on is used by the rest of the user community.
There are two common user interfaces through which users can log into SAP:
- SAP GUI (Graphical User Interface)
- Fiori launchpad
SAP GUI is the classic backend user interface used in both ECC and S/4HANA, while Fiori is a front-end user interface more commonly used for S/4 HANA.
SAP GUI is logged into using user-ID and password for the specific client. From an organisational point-of-view, a client basically represents an independent business entity in that SAP system. Multiple clients can occupy the same SAP instance (essentially the same application server). Once logged in, the user will see a screen which shows the tasks available in SAP.
Fiori is a front-end which is commonly-used by end users to log into S/4HANA. In Fiori, in order to run a task, the user clicks on a tile/card. The task itself is processed in the backend. Fiori authorisation runs differently from the classic SAP authorisation concept. A user in Fiori needs to be assigned a Fiori role (which allows them to click on a specific tile on the frontend) and corresponding authorisation objects in the backend (which allows the transaction to be processed).
SAP NetWeaver Business Client
Some end users may be familiar with the SAP NetWeaver Business Client (NWBC). This is a browser-like SAP front-end which allows the user to go to various SAP applications (e.g., ECC or S/4HANA, SAP GRC or CRM). All these applications can be accessed through single sign-on via NWBC. This means that the user only needs to log into NWBC to enter other applications. No further authentication process is required.
Once NWBC is logged into, the user can see a list of systems which are connected. The relevant system can be selected on this screen and a new tab will be opened.
Let’s say S/4 HANA or ECC is selected. The new tab will show a screen which contains very similar information to what they would see on the SAP GUI. NWBC only provides a user-friendly, browser-based front-end that allows users to navigate various SAP applications more easily and does not change the underlying data.
Similarly, if Fiori is selected, the new tab will show Fiori menu, similar to what the user would see if they directly logged into Fiori.
If the company does not use NWBC, users will have to login directly to SAP ECC (via the SAP GUI) or S/4HANA (via the SAP GUI or Fiori). Additionally, even when NWBC is used, some users may be able to login directly to the underlying system.
Access within SAP
Whether the user logs into SAP via the GUI, Fiori or NWBC, in order to carry out tasks in SAP (e.g., perform transactions, display information, etc.) they will need to be assigned authorisations in the SAP backend system (i.e., ECC or S/4HANA). These authorisations are contained within a role, which is then assigned to the user-ID. We will not be covering roles in this blog post, but please click here if you want to understand more about the role-building principle in SAP.
How does a user gain access to carry out transactions in SAP?
Those accessing SAP via the GUI (whether on NWBC or directly) will be familiar with transaction codes (t-codes). T-codes are used to start specific tasks. In order to start a t-code, it can be typed into the command field or the specific task in the menu can be clicked. Each task can be accessed through one or more unique t-codes. For example, ME21N is the t-code for raising POs, FB03 is the t-code for displaying accounting journals, XD01 is used for creating customer master records.
From a technical point of view, carrying out a task in SAP requires access to a specific SAP data table. When the task is performed, a specific SAP data record is accessed and may be changed. For example, when a new purchase order (PO) is entered, the SAP data table for purchasing documents is updated with a new record.
SAP data is accessed via in-built SAP functionality. This functionality acts as a checkpoint which restricts the users who can access the data. Essentially this functionality is made up of various ABAP programmes (i.e., coding) which check whether the user has complete authorisation to perform what they want to. The functionality is started by entering a t-code or clicking on a command which starts a task.
When the t-code ME21N is executed, the user will be taken to a screen on which details of the PO can be entered. In order to be able to save this PO (and therefore create a new record in the relevant SAP data table), the user will need to successfully pass additional field value checks.
In practice, the execution of a t-code kickstarts the ABAP programmes to start their checks, which take place in two stages Firstly, SAP will check whether the t-code exists and whether it is locked. If it exists and is unlocked, the user will be granted access to the screen where the desired task can be entered.
Once the user has entered the relevant details and attempts to save the transaction, an authority check will be conducted in the following steps:
- SAP identifies the corresponding authorisation object field values which should be checked for the particular transaction code entered.
- SAP then checks whether the user has the required authorisation object field values assigned.
If these two checks are passed, the transaction will be saved and the relevant SAP data table is updated. We will cover the provisioning of authorisation objects to users in the next section.
Correct level of access
What is the correct level of access to give to your users? In an ideal situation, each user should have the right access which requires them to perform their tasks and nothing more.
Ideally, no user should have excessive access as it can put the company at risk for various reasons:
- Firstly, excessive access can be misused, especially when it is not monitored, leading to a higher probability of fraud.
- Secondly, excessive access could be incorrectly used, opening up to the possibilities of human error.
- Finally, there are legal requirements which require companies to restrict access to certain information.
In order for each user to have the exact level of access rights that they need, you might need to create a unique role for the user. This would lead to a huge number of roles in the SAP system, requiring enormous efforts to create, maintain and monitor. Furthermore, every time there is a change in user requirements (e.g., when a new user joins the company or when a user changes their job responsibilities), roles would need to be created/updated. It would simply require too much administrative effort.
Given that users cannot have exactly the access that they need, what would be an acceptable compromise: Is it better to give users too little or too much access? Let’s consider both scenarios.
When users have too little access, they will not be able to perform their tasks and will raise IT incidents to request more access. This could lead to a lower KPI scores for the IT department and take resources away from more important projects. However, on the positive side, giving users restricted access lowers the risk of unauthorised access into SAP.
When users have too much access, they will have access to perform their tasks, but also other tasks that they do not need. IT will not usually receive any complaints from users, as users’ abilities to perform their tasks are not impacted. However: How can it be ensured that any excessive access rights are not abused?
Ultimately, giving users too little access is not practical and may end up costing the company more efforts on firefighting efforts. It is more feasible to give access more access than they need and carry out robust monitoring activities around authorisations.
Please refer to our blog posts on preventative vs. detective controls to explore the controls that can be put in place to manage access risks.
Go to Newsletter edition 02 here.
