SAP Community - NW ABAP User Administration and Authorization

Microsoft Sentinel and Logic Apps can be the 'Guardians of SAP Security Operations (SecOps)'?

2022-03-14T21:05:04+01:00

"Microsoft Security delivers new multi-cloud capabilities"

Hello Community Members,

I'm back with some interesting PoV to demonstrate the SecOps & SAP Security elements on 'SAP on Azure (or AWS, GCP, or on-prem systems)', leveraging Cloud-based SIEM and SOAR solutions.

As we know SAP is the custodian for immense amounts of sensitive data in many of the most prominent organizations in the world. Since these applications are business-critical, and SAP security breach can be disastrous. However, protecting SAP applications is uniquely challenging always. We constantly require a prominent security squad and resources, characterizing with The Guardians of the galaxy to protect from any internal or external violations. SecOps on hyperscalers is a very comprehensive topic, so I will begin with a clear lodestar. In today’s post, I'd like to exhibit how the Azure services like Microsoft Sentinel, Logic Apps, SAP Connector can be configured altogether to protect all SAP users...An incredibly straightforward use case for advanced SAP users.

Sounds fascinating! Let's hop into the technical elements!

Source: Bing images

It has been notoriously challenging to detect these threats to SAP applications, while the consequences of an undetected threat can be profoundly serious, especially breaches from inside or outside. This hardship in detection stems in part from the complex internal nature of SAP systems, as well as the fact that these systems usually have lots of cross-connections between distinct third-party applications and interfaces, specifically banking and finance segments.

Hence Microsoft Azure provides the new solution to tackle these SAP security challenges with the new SAP threat monitoring solution for Azure Sentinel. (First cloud-native SIEM from a major cloud provider.)

Continuous Threat Monitoring for SAP in Microsoft Sentinel

Azure provides the new solution to tackle these SAP security challenges with the new SAP threat monitoring solution for Azure Sentinel. Please note, is in public preview today, this solution provides continuous threat detection and analytics for SAP systems deployed on Azure, in other clouds, or on-premises. Now, SecOps teams can use Azure Sentinel’s visibility, threat detection, and investigation tools to protect their SAP systems and cross-correlate across their entire organization.

Prerequisite - I presume you completed the deployment of your SAP system and Microsoft Sentinel connection by referring- Deploy SAP continuous threat monitoring | Microsoft Docs (Microsoft documentation)

The Continuous Threat Monitoring for SAP in Microsoft Sentinel enables you to monitor your SAP environment and helps you with cross-correlating various logs from numerous systems with your SAP logs. With the Microsoft Sentinel SAP connector, you can monitor your SAP systems for sophisticated threats within the business and application layers. The connector uses a docker container, which pulls the data from SAP and then sends it through to Microsoft Sentinel. Don't worry, you will see the architecture flow outlying in this article.

By deploying the data connector, we can now import the SAP logs into Sentinel, correlate the logs with other data, and analyze and hunt the logs for emerging threats. Install the SAP solution security content to gain insight into your organization's SAP environment and enhance any related security operation capabilities.

For a comprehensive synopsis of what is included in the Sentinel SAP solution content,
see Microsoft Sentinel SAP solution - security content reference | Microsoft Docs

Microsoft Sentinel contains a substantial Security Orchestration and Automated Response (SOAR) capability which will help SAP applications respond to incidents rapidly with AI and automation features built in to use. Many SOAR integrations can be deployed as part of a Microsoft Sentinel solution, together with related data connectors, analytics rules, and workbooks.
For more information, see the Microsoft Sentinel solutions catalog.

Source: Microsoft Azure documentation

In this composition, we will see how you can use the SOAR capabilities of Sentinel with SAP Application, by using the Azure playbook that automatically takes on remediation actions in the SAP system directly with the Logic App connector.

Let’s glimpse!

Overview & Use case

We are stirring to focus on a pragmatic use case criterion for automating SAP actions as a response to an incident in Sentinel with SAP code triggered with Logic Apps support.

Use case: An SAP user with developer privileges could exploit those privileges to view sensitive human resources or financial data by perpetrating a function module to gain elevated access privileges which are not authorized to this SAP user. Microsoft Sentinel gives you the ability to quickly detect these threats and hazards in the SAP system without drowning in noise.

Obstruct the SAP dialog or RFC user(s) after a suspicious user incident is notified.

The SOC (SecOps) team is alerted of a suspicious atypical travel alert.

After triaging the incident, the SOC team decides to block the user's access to sensitive environments. One of these sensitive environments is the SAP system to which the user can't have access anymore.

The SOC team runs playbooks for these automatic remediations and one of the playbooks is the ‘BlockSAPUser’-playbook.

The objective here is to block the SAP dialog or RFC user credential by locking the dialog or RFC user accessing SAP S/4HANA or ECC/NetWeaver system in an automated way with help of Logic Apps BAPI function triggers.

Getting Started

For this blog post, we make use of the on-prem data gateway to leverage the SOAR capabilities from Sentinel on SAP.

This gateway makes it possible to have a secure data transfer between data sources and services in the cloud. The data gateway should be installed on a Windows system. It is feasible to use a dedicated machine or install it on the machine on which SAP is running, but you must ensure that both the VMs can intercommunication with each other over the private IPs or the same VNET.

For more information on the installation and prerequisites for this data gateway, please visit Install on-premises data gateway - Azure Logic Apps | Microsoft Docs

You can download the gateway via Download On-premises data gateway from Official Microsoft Download Center

When you have installed the data gateway, you will also need to install the SAP Connector for Microsoft .NET 3.0 on the identical machine as the data gateway. The SAP Connector for Microsoft .NET 3.0 will allow us to use BAPIs and remote-enabled function modules in a .NET application. You can download the SAP connector via Software Downloads - SAP ONE Support Launchpad

Make sure to use “Install assemblies to GAC” when setting up the SAP connector and afterward restart the data gateway.

For our conclusive preliminary step, we will have to create the gateway cloud service to conclude the handshake between the cloud services and the on-premises data gateway on the windows host.

More information on creating the Azure gateway resource can be found on Access data sources on-premises - Azure Logic Apps | Microsoft Docs

Reference Architecture for SAP System(s)
connected with Azure Cloud Services and Workflow

SAP Users/RFC User(s) connected from SAP system using SAP RFC /SOAP to Docker container running on Azure Cloud (SAP running on-prem or Azure or any other hyperscalers like AWS or GCP as depicted above in Architecture diagram.)

Microsoft Sentinel triggers an atypical travel Alert/incident if any specific SAP user breaches after detecting by Microsoft Sentinel.

Azure Logic Apps connected with Microsoft Sentinel and on-prem gateway (using SAP connector) triggers SAP BAPI locking function.

This BAPI function triggered by Logic Apps connected to the SAP system locks the SAP user automatically. You can send email via Logic Apps to SecOps for SAP user locked alter (optional step can be added for alerts)

Let's see this Playbook in detail

In this use case, a suspicious developer user will be intercepted from accessing the SAP environment.

The SOC team has been notified of an ‘Atypical travel’ alert in Sentinel. After thorough investigations, they decide to block the user entity from accessing the SAP environment and use the “Run playbook” action to begin automatic remediation.

Atypical travel has been detected. Playbook will be used as an automatic remediation action. This playbook will use the Microsoft Sentinel incident as a trigger so that you can use it as an automatic action on an incident. In the playbook, the ‘Create stateful session’ action from the SAP connector (see: SAP - Connectors | Microsoft Docs) is used to make the connection with SAP.

When the connection has been made, extract the user entity from the Sentinel incident and use the ‘BAPI - Call method’ to block the user in SAP.

For more information visit Connect to SAP systems - Azure Logic Apps | Microsoft Docs

Azure Logic App script available on GitHub page for Input BAPI code - Link

<!-- Business object USER, method UNLOCK for Unlock user implemented by RFC BAPI_USER_UNLOCK -->

<UNLOCK xmlns="http://Microsoft.LobServices.Sap/2007/03/Bapi/BUS2017/">

  <USERNAME>SAPUSERNAME</USERNAME>

</UNLOCK>

When my SAP user "Amitlal" attempts to logon to the SAP S/4HANA system, I cannot access the system since my user got locked out:

Final run

∑ Conclusion

Azure provides enterprise-grade cloud infrastructure & Security for SAP workload on which customers and partners can rely. No matter what your service level objectives are, Azure empowers you to achieve your organization's reliability goals. More complex use cases (e.g., with supplementary steps for authorization from SecOps/SOC manager via Microsoft Teams or Delete the SAP user account after a specific period, removing specific roles or blocking it!) are possible and we encourage you to try it out on your own!

Microsoft Sentinel and Logic Apps can be the 'Guardians of SAP Security Operations'?
Yes, one hundred percent!

Please share your views and comment. Thank you!

Special Thanks to Naomi Christis -Microsoft Sentinel Expert for co-authoring this article published on -
-Microsoft Tech Community

Disclaimer- The Microsoft Sentinel SAP solution is currently in PREVIEW include supplementary legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability. I have blogged this article to share information that is intended as an unrestricted resource and personal insights. Errors or omissions are not intentional. Products and services cited in this article are not endorsements or favor. Opinions are my own and not the views of my employers (past, present, or future) or any organization that I may be affiliated with. Your comments to my posts are your views and I'm not responsible for anything shared by anyone in the article. SAP and hyperscalers Customers are responsible for making their own independent assessment of the information in this document. This article is for informational purposes only. The GitHub code is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. Thank you!

Web Dynpro start authorization

2022-04-26T15:40:55+02:00

In this blog post I will describe the start authorization for Web Dynpro for ABAP applications and, most importantly, how it is controlled.

Similar to the authorization object S_TCODE, which is being checked during the call of a transaction, during the call of Web Dynpro ABAP applications the authorization object S_START is being checked.

This start authorization check is delivered in an inactive state, which means that you need to actively change it in your system.
Note: 1413011 - New start authorization check for Web Dynpro ABAP - SAP ONE Support Launchpad

How to activate the check?

The start authorization check is controlled by a table entry in the table USOBAUTHINACTIVE. To check or activate the start authorization check, call transaction SM30 and enter the table name "USOBAUTHINACTIVE" in the field "Table/View". Choose “Maintain”:

SM30

If in the column “Inactive” the checks are selected, then the checks are not active.

To activate the start authorization check for Web Dynpro ABAP applications and Web Dynpro ABAP application configurations, remove the checkmark in the "Inactive" column for the application types R3TR WDYA and R3TR WDCA. Save your changes. The start authorization check is now active in all clients throughout the system.

Table USOBAUTHINACTIVE

What does this change mean for the current authorization concept?

When this authorization check is set to active, the system will check for the object S_START and give an authorization error if this object is not authorized. If there are any Web Dynpro ABAP Applications that are being used but are not present in the roles, they need to be added in the roles using the transaction PFCG.

Note: If the Web Dynpro ABAP applications are added into the menu of a role, the authorization object S_START is added to the authorizations tab.

PFCG

From S/4HANA 2021 on the Web Dynpro start authorization is active by default.

In SAP S/4HANA, on-premise edition 2021, SAP S/4HANA Foundation, on-premise edition 2021, and SAP BW/4HANA 2021 (and all future releases), this start authorization check is already activated during the installation/migration for Web Dynpro applications (object type R3TR WDYA) and Web Dynpro application configurations (object type R3TR WDCA).

Therefore, the active role concept is affected if the required start authorizations (authorization object S_START) is missing in the roles. The affected roles need to be updated. It is also possible to deactivate the checks in SU25, although this is not recommended. For more information please check the Note 3064888 - Start authorization check for Web Dynpro applications and Web Dynpro application configurations in SAP S/4HANA - SAP ONE Support Launchpad .

More information on Secure by Default can be found in this blog post: The story resumes – Secure By Default for SAP S/4HANA 2021 | SAP Blogs

Also feel free to ask questions in the SAP Community: https://answers.sap.com/questions/ask.html?primaryTagId=462330605920974660730944876913277

Authorization Group Tool

2022-05-16T21:17:13+02:00

About

This tool supports exploration and management of authorization groups.

Features

List Authorization Groups (Quick Jump to SE54 identical feature)

List Authorization Groups used in Table/View maintenance dialogs (Custom Feature)

List Authorizations Profiles / PFCG Roles where a given Authorization Group is embedded (Custom Feature)

Maintain Authorization Groups (Quick Jump to SE54 identical feature)

Assign Authorization Group to Table/View Maintenance Dialog (Quick Jump to SE54 identical feature)

The Problem

A recurring task is to create SM30 maintenance views in onPremise SAP systems on top of customizing tables to enable configuration of processes. When You generate a maintenance dialog, You can choose an authorization group to protect recording data to the table/view through the generated maintenance dialog.

Sometimes that Authorization Group is not predefined in the requirement, due no appropriate one exists, or no one can provide You with an appropriate Authorization Group name, but protection of recording entries in the table is essential. You can search for existing groups or create new one, then validate it by people defining the requirement. At this point You might find Yourself in a jungle to come up with a right Authorization Group. This tool is a helper to bunch the required functions together to solve this problem quickly.

Technical Background

The Authorization Group itself is a Field in the Authorization Object S_TABU_DIS. The Authority Check is done against this Group and the Activity (02-Edit/03-Display ) by the system.

This Object can be assigned in the Authorization Profile of the corresponding Role in transaction PFCG to provide Display or Edit capability for a user having the Role:

Installation

Clone repository

https://github.com/attilaberencsi/authgroups.git

using ABAPGit (online / offline).

Licence: MIT

Features of the tool

The following selection screen welcomes You, when You execute the report zsapdev_authgroup.

Selection-Screen

Show Authorization Groups

Shows all the Authorization groups in the system, which are client (in)dependent.

This is a standard feature.

List Authorization Groups used in Table/View maintenance dialogs

I developed this feature to get an insight which Authorization Groups are used in our systems in maintenance dialogs. You can restrict the search. It comes handy to search for Z* Authorization groups to see which You have, and to which tables/views are they assigned at the moment.

Roles with Authorization group

In case You are trying to validate correctness of an existing Authorization Group, You can fetch the PFCG Roles within a given Authorization Group is used. Without defining a Group, all the PFCG roles are listed having Authorization Groups.

Maintain Authorization Groups

When You didn’t found any appropriate Authorization Group, here You can create a new one.

This is a standard feature.

Assign Group to Table / View Maintenance dialog

You can change Assign Authorization Groups to tables in Mass. The next selection screen helps to list maintenance dialog objects by name or currently assigned Authorization Group.

This is a standard feature.

Validation

ATC Check: Passed

Manual validation done on:

Software Component	Release	Support Package	Support Package Level	Description
S4FND	104	SAPK-10402INS4FND	0002	Foundation
SAP_ABA	75E	SAPK-75E02INSAPABA	0002	Cross-Application Component
SAP_BASIS	754	SAPK-75402INSAPBASIS	0002	SAP Basis Component
SAP_GWFND	754	SAPK-75402INSAPGWFND	0002	SAP Gateway Foundation
SAP_UI	754	SAPK-75404INSAPUI	0004	User Interface Technology

Good luck with Authorization Groups 🙂

Incremento de Segurança na Administração de Documentos Contábeis - FB02 - F_BKPF_BLA

2022-06-26T08:03:05+02:00

Dada a criticidade das informações que mantém, a camada de autorizações relacionada aos componentes FI/CO, estes que, transacionam informações estratégicas e sensíveis, é amplamente discutida. O estabelecimento de controles, tal qual, SOD, visa assegurar a lisura nos processos e a integridade das informações demonstradas.

O ponto de partida para esta publicação foi a seguinte impressão: "A verificação de autorizações na FB02 não provém um nível de granularidade que habilite a restrição a modificações para determinados tipos de documentos."

Cenário.:

Usuários de contabilidade são aptos a modificação de documentos X1 - Lançamento imobilizado, entretanto, não é tolerável qualquer modificação para documenos Z2 – Pgto.Tributos.

Contexto.:

O rigor e a integridade das informações transacionadas no sistema SAP, dentre outros aspectos, são asseguradas pelo robusto conceito de autorizações. Este que, abrange diversos componentes e permite a configuração de restrições complexas, sejam standard, híbridas ou totalmente personalizadas.

Através de um trace de autorizações(STAUTHTRACE), observamos que a rotina de modificações executada na FB02 verifica alguns objetos F_BKPF*, que por sua vez compõem a classe de objetos FI – Contabilidade Financeira.

Em uma análise superficial, observamos verificações relacionadas a: Empresa, Tipo de Conta, Área de Contabilidade de Custos, dentre outros objetos Etc.

Solução.:

A solução viável para nosso cenário foi mapeada e publicada pela SAP há bastante tempo, mesmo assim, achei por bem consolidar as informações.

150496 - F_BKPF_BLA: Authorization for document types

198238 - FI reporting: Authorization check for document type

Através das notas supracitadas, a SAP nos expôs a possibilidade da restrição de modificações por Grupos de Autorizações, semelhante ao funcionamento do Grupo de Autorização Programa(P_GROUP) carregado pelo objeto S_PROGRAM e o Grupo de Autorizações de Tabela(DICBERCLS) carregado pelo objeto S_TABU_DIS.

Os objetos de autorização citados como exemplo, têm como propósito viabilizar a composição de regras granulares, permitindo a distinção de regras de atividade em função do agrupamento dos objetos sujeitos às ações, Sejam eles: programas, tabelas ou em nosso caso, tipos de documentos.

Exemplo:

A role 01 – Assistente de Contabilidade deve habilitar a modificação em lançamentos tipo "A1", bem como, assegurar que lançamentos tipo "C1" estejam restritos somente a visualização.

Ajuste.:

Para tal configuração, a SAP provém o objeto F_BKPF_BLA que se comporta como opcional, tendo sua etapa de verificação relevante quando o Tipo do Documento está categorizado em um Grupo de Autorizações.

Através da transação OBA7 obtemos a visão acerca dos Tipos de Documentos, ao expandir a visão de um tipo específico, temos contato com suas propriedades.

O campo “Grupo de Autorizações” é um CHAR que recebe 4 caracteres, “YDOC”, por exemplo. Definição SAP: "O Grupo de Autorizações possibilita uma proteção de autorização ampliada para determinados objetos. Os grupos de autorização podem ser definidos livremente. Os grupos de autorização surgem em objetos de autorização, geralmente em combinação com uma atividade."

A categorização do Tipo de Documento em um Grupo de Autorizações específico, o torna suscetível a restrições.

Superada a etapa de atribuição do Tipo de Documento ao grupo, cabe uma checagem nos indicadores de verificação através da SU24 para o objeto F_BKPF_BLA.
1. A transação FB02 carrega devidamente o objeto F_BKPF_BLA?
2. O objeto F_BKPF_BLA sofreu alguma manutenção que alterasse seus valores propostos?

Atribuição, verificação e proposta OK? Definimos através da PFCG a configuração de acordo com a necessidade.
1. Recomendações:
  1. Evitemos a inserção manual e modificação de objetos em desacordo a lista de utilizações, preservemos a relação transacional SU24 x PFCG o máximo possível.
  2. Verifiquemos a ocorrência de autorizações sobrepostas, eventualmente alguma autorização para o F_BKPF_BLA pode ter sido definida com “*”, seja na role em si, ou em outra role que esteja atribuída ao usuário. A condição pode ser verificada através da análise do buffer do usuário na transação SU56 ou exame das roles a ele atribuídas através da tabela AGR_1251.

Referências.:

150496 - F_BKPF_BLA: Authorization for document types

198238 - FI reporting: Authorization check for document type

Cavalleri, A.; Manara, M. Authorizations in SAP: 100 Things You Should Know About SAP Security, SAP Press.

Tópicos relacionados:

https://blogs.sap.com/2018/03/01/sap-security-and-fi-validation-rules/

Resumo.:

Em suma, a proposta de solução para o cenário apresentado utiliza um conceito bem difundido dentro das práticas de SAP Security, grupos. Sejam de usuários, programas, tabelas, documentos ou qualquer elemento, nos possibilitam a trazer maior granularidade para nossas restrições. Conforme dito anteriormente, outras rotinas aceitam ajustes dessa natureza, podemos superficialmente buscar por objetos relacionados através do report RSUSR040.

Em breve detalharei outros contextos e estratégias relacionadas a autorizações SAP. Espero poder contribuir, a intenção é sempre: Aprender, compartilhar e fortalecer a comunidade.

Getting back to Standard Proposals with SU24 Authorisation Variants

2022-08-11T12:47:23+02:00

How you can leverage new functionality to improve your security role build in SAP S/4HANA.

Avoid CHANGED. MANUAL by Exception. MAINTAINED is OK. Strive for STANDARD.

For as long as I’ve been building application security roles via transaction PFCG, this is the mantra I’ve followed when maintaining authorisations. Transaction PFCG (Role Maintenance) is integrated with Transaction SU24 (Authorisations Proposals). This integration automatically imports and removes proposals from the role authorisation data based on the items in the role menu.

With the move to SAP S/4HANA and SAP Fiori, managing authorizations effectively becomes more important than ever. Authorizations directly affect the User Experience of your users. Get it wrong and you risk actively degrading UX adoption and reduce the benefits that your users and your organization can derive from these innovations. For example, manually adding transaction code to role will make it unavailable to users in Fiori Launchpad.

An overview of PFCG and SU24 integration

For the most part, transaction SU24 is a build accelerator and is a is considered a best practise for role build as it:

Reduces access creep: when transactions are removed from the role menu, the associated authorisations proposals are also removed (so long as another menu item doesn’t require them). This benefit only works for standard and maintained authorisation status items.

Reduces authorisations errors: the role will automatically receive the require authorisations for each application so long as the mappings are fully maintained in transaction SU24, and the application has been added to the role menu

Reduces build Effort and time: the security administrators can leverage existing mappings as part of role build and requires less time to map the values out for each role.

Simplifies and Improves Impact Analysis: it makes is easier for role authorisations experts to easily identify why an authorisation is part of a security role. This helps with segregation of duties impact assessment, role clean-up, and regression test prioritisation.

Going back to the mantra –

Avoid CHANGED. MANUAL by Exception. MAINTAINED is OK. Strive for STANDARD.

Why Avoid CHANGED?

We avoid CHANGE as it is a deliberate breaking of mappings and deviates from consistency. A CHANGED status object is treated like a MANUAL object. Transaction PFCG cannot automatically remove a CHANGED authorisation from the role when the transaction is removed as there is not relationship between the data. Therefore, CHANGED objects can increase access creep and make it difficult to properly impact assess or remove the access.

Why MANUAL by Exception?

We accept MANUAL by exceptions. Some authorisations are required but are not mapped to applications items that can be added to a role menu (e.g. S_RFCACL for trusted RFC). Some may be clear design decisions for supplementing an existing role to provide additional authorisation (e.g. purchasing approval codes). These exceptions are clearly documented and less likely to change.

Why strive for STANDARD?

We aim for STANDARD as it meant we had a 100% alignment with authorisation proposals. Assuming SU24 data is accurate, it is unlikely the security administrator team needs to maintain values in PFCG.

Why is MAINTAINED ok?

We accept and settle for MAINTAINED as a balance between mapping what we can in SU24 and avoiding CHANGED status.

Wouldn’t it be great if we didn’t have to settle for maintained? Variants makes this possible.

Common Scenario for MAINTAINED status

Maintained status occurs because we only partially maintained authorisation proposal inside SU24. This is needed when a transaction code belongs to multiple roles with differently underlying authorisations values.

For example, if we had a transaction that provided table maintenance then we would provide authorisation object S_TABU_NAM. This object contains fields Activity and Table Name. We cannot maintain the Activity proposal in SU24 if we need to grant access to users in either display or maintenance mode. However, both roles would need the same Table Name. As a result, we would partially maintain the proposal: Activity field would remain blank, and Table Name would contain the entry.

For example, transaction OB52 provides access to posting periods. Many users may need display access and only a few need to make changes. Within transaction SU24, SAP provides the ACTVT Activity field as an empty proposal which is then maintained at role level.

Within transaction PFCG, we would receive a STANDARD proposal initially that is then set to MAINTAINED once we finish populating the Activity proposals (one role gets display only whilst the other role gets change and display).

Other Scenarios for MAINTAINED status… and where it can get messy

MAINTAINED Status can also be due to:

SAP Proposal and Upgrades remain unchanged – the customer chooses to leave the default proposals as is and make all necessary refines at role level.

Cockpit Style Transactions – the application has several use cases controlled through combinations of authorisations. The SU24 default proposals remain predominately empty to provide the flexibility to maintain values at role level.

HR Authorisations and transaction - most HR transaction access is controlled through two (2) main objects – P_ORGIN and PLOG. The objects contain fields for activity level, infotype, and enterprise data restrictions. To avoid CHANGE and MANUAL status, these objects are added with empty proposals and all changes are managed at role level.

SAP Proposals and Upgrades

SAP provides default proposals for SAP standard transactions. These values are shipped via transaction SU22 tables and copied across to transaction SU24 tables via transaction SU25 (for greenfield systems, Step 1 is run).

The customer is allowed to make changes to the SAP proposals. Within transaction SU24, you can compare the values in your system against SAP proposals to check if you have deviated from the original.

As part of upgrades, SAP ships new values (changes to existing mappings and mappings for new transactions). The customer uses transaction SU25 Steps 2a/2b to compare customer tables and SAP tables to import changes.

However, for many customers, it becomes a challenge to decide if they should adopt SAP updates on transactions that they have already maintained. Depending on build maturity, it can be difficult to change which proposals are a better fit: SAP’s latest proposals or updates the customer made as part of build refinement.

Some security administration teams avoid making changes to SAP standard proposals. In this situation, it leads to an increased level of CHANGED and MANUAL authorisations – what we’re trying to avoid. However, it makes upgrades a bit easier for the security team to process.

Cockpit style transactions

The transaction is a single-entry point for several functional scenarios and assigned to multiple roles. In this situation, SU24 proposals have a higher incomplete rate and requires individual maintained in each role. Each role requires a different combination of fields values. This level of localisations shifts the build effort to the security administrator as part of role build.

HR Authorisations and transactions

HR authorisation objects control personnel record and organisational structure for infotype access. If you attempt to use transaction SU24 proposals, in most cases you are forced to enter an empty proposal in SU24 as each role requires different values. For example, transaction code PA30 for Maintain Personnel Record requires P_ORGIN authorisations to control activity level, data access, and Infotypes. Several users may need access to the transactions but different functional access. Therefore, P_ORGIN would need to be empty in SU24 and fully maintained in PFCG. It can make it difficult in HR-centric roles to determine why the roles has field values as you cannot determine the context by the role menu items. Often, security administrators resort to manually adding objects instead of attempting SU24 maintenance.

A use case of needing variants in SU24

Using the “cockpit style: scenario, let’s imagine you want to provide users with access to F3163 Manage Business Partner Master Data. This application allows you to access Suppler, Customer, and Employee information and is included in several business role templates. Many users will have a requirement to access the application, but they will need to be restricted to specific data.

Fiori App F3163 authorisation is based on SAP Gateway Service “MD_BUSINESSPARTNER_SRV 0001”. Within SU24, default proposals are provided but they are for maintenance access with no specific limit to business part role. This means without changing the proposal within transaction SU24, all restrictions will need to be at role level. Making changes are role level will result in MAINTAINED, CHANGED, or MANUAL status. Alternately, SU24 can be updated to remove the field proposals and leave empty values to maintain entirely at role level (end up with MAINTAINED only) but that doesn’t a consider different maintenance level (e.g. deletion access may be restricted).

Each time the application is added to a role, the administrator then must make changes. However, SU24 variants can solve this problem and allow you to continue with STANDARD proposals. Within, transaction SU24, a variant is created with the required mapping.

Transaction code PFCG now contains an Application Tab which will list the available Variants for each application maintain. This tab is populated after the role menu is refreshed and SU24 definitions have been read in. In the example below, the options are greyed out as there are no variants to choose between.

Once the variants have been selected, the SU24 proposals are then imported via the Authorisation Tab. Again, in this example there are not variants sot the SAP standard values will be adopted.

The security role administrator will need to work through each authorisation proposal to either set the unrequired authorisations to inactive, complete field proposal, or return to transaction SU24 to make proposal changes at the master data and then return to the role to continue build. However, as this application is used by several process areas (procurement, sales, HR, etc), it is unlikely SU24 proposals will be changed as it impacts all roles. Instead, the proposals will end up in a MAINTAIN or CHANGED status to maintain the required authorisation for the role. Ultimately, you start to lose the benefits of SU24 proposals, or you must remove all proposals in SU24 and maintain everything inside of PFCG.

Finally what are these variants and how to use them

Originally this capability was delivered under a “new” transaction code SU24N but has seen been merged back into transaction SU24. Refer to SAP Note: 2798443 - SU24N: New dialog environment for authorization default value maintenance

Transaction SU24 now allows you to create variants of the maintenance proposals. This means you can create multiple proposal versions and control which ones you adopt within the roles.

Within SU24 transaction you can how choose to CREATE VARIANT instead of changed SAP standard proposals for an application. When creating the variant you must enter this in the customer namespace. You can implement a naming convention (such as including Fiori Application Id which can help for context later).

As this is workbench object, you will need to assign it to a transport (no screen shot shown). Once you have created the VARIANT you can start making changes to the proposal data without updating the standard values.

In the case of this application and the context of managing Supplier, you can now switch off authorisation proposals that are not relevant as well as changing the existing proposals for values that are more relevant to supplier master data.

Once you have completed the updates you then save (just like you would have when you made updates to the standard proposal)

Return to transaction PFCG and look and go to the Application Tab. You will now. The SU24 variants are automatically identified based on applications in the role menu.

As a variant now exists, you can choose which on you select for the role authorisation proposals. If there are several variants, you can choose as many as required for the role.

Once you have selected the applicable variant, save the role before you maintain authorisation data again. On the authorisation tab you will need to select Expert Mode for Profile Generation > Read Old/Merge with new to re-read the SU24 values and pick up the VARIANT proposals

You will still be asked to enter the organisational values (or update them if you need to).

The authorisation data will show more STANDARD (green) proposals due to the VARIANT that you maintained

When reviewing the authorisation proposal you will now see which specific variant brought them in.

As mentioned, when creating a VARIANT in SU24, the variant name is quite useful to understand the context. As shown above, the application variant name of “ZF3163_SUP_M” is a basic naming convention for the Fiori App F3163 with variant of Supplier Maintenance. These conventions can make it easier to understand the access context compared to the application Odata service name.

Impacts of Using Variants

The primary benefit of using variants is to allow you to leverage authorisation default proposals from SU24 and minimise overall maintenance of individual permission within the role. The following are benefits I can see in using variant in SU24

Able to easily handle different access contexts for the same application.

Separate development/maintenance default mappings with security roles team

Reduce access creep and confusion in role build through less direct maintenance of value

Obtain better access context through variant names to better understand reason authorisation proposal within a role

Easily able to add a new variant to an application for another role without having to maintained the existing roles. This can occur when you add an application in design but need to change the SU24. If you update the SU24 data, then you would need to also maintained the existing role and regression test. This further add to your change request and effort. Instead, you can define a new variant just for those values.

Reduce SU25 Step 2a/2b upgrade effort as you avoid maintaining SAP standard proposals. However, you will need to manually assess your variants to decide if you need to add new value proposals that were added to the SAP original

Flexibility to differentiate access proposals for non-production and production access. This can allow security teams to leverage SU24 for project role build for sensitive transactions that would generally be granted in display mode only.

Small win – your can double-click on the variant tab line items of transaction PFCG to navigate to the related transaction SU24 configuration to confirm you have selected the required variant.

Give variants a go and share your thoughts below. I’d love to know if this is something you’d consider using as part of your build accelerator and approach to consistently building security roles.

Cheers

Colleen

P.S. For those of you who are new to building security roles ABAP authorisations roles via transaction PFCG, the authorisations status is summarised in the table below:

Authorisation Status	Summary of build sequence that causes the Status
Standard	Authorisation proposal for the transaction is wholly maintained via transaction SU24 with proposal status set to Yes. Exception: organisational field proposals are not set via SU24 Application is added to the role menu in PFCG Authorisation proposal is fully imported. At most, the security administrator maintains the organisational values The security administrator makes no further changes to the authorisation Authorisations Proposal remains in a STANDARD status
Maintained	Authorisation proposal for the transaction is partially maintained via transaction SU24 with proposal status set to Yes. Partially means at least one authorisations field has been left empty and it is not an organisational field. Application is added to the role menu in PFCG Authorisation proposal is imported showing a STANDARD status with traffic light of YELLOW as the build is incomplete The Security Administrator must maintain the blank values. Once maintained, the Authorisations changes to a MAINTAINED status.
Changed	Authorisation proposals is either partially or completely maintained in SU24 Application is added to the role menu in PFCG Authorisation proposal is imported as a STANDARD status The Security Administrator overwrites a proposed value (e.g. ACTVT 01, 02, 03, 06 is changes to 01, 02, 03 to remove 06 delete) The original proposal is automatically copied and deactivated. It remains in a STANDARD status (this happens in later releases) The authorisation proposal status is now set to CHANGED as the proposed values no longer align to the source mappings in SU24. CHANGED values are treated like MANUAL. Usually you will receive a pop-up warning you that you overwriting proposal. Pay attention to breaking organisational value inheritance as this can cause headaches later.
Manual	The security administrator manually adds the authorisation in to the role. The status is set as MANUAL There is no connection to role menu items and SU24 proposals.

Mitigating controls - is this a cure for "all evil" in excessive authorizations risks in SAP?

2022-11-18T14:38:49+01:00

The implementation of additional mitigating controls is a frequent response from the company management in order to limit the risk of excessive (redundant or unnecessary) authorizations in ERP (SAP) systems. Is it a good way to eliminate the excessive authorization risks or are we are just dealing with its side effects? Let’s debate whether it is the right and well-thought approach. What are the negative consequences of doing so, are there any? Is there one answer that is right for all organizations, situations, and markets? During the SoD (Segregation of duties) project, there are many myths about excessive user rights in SAP. The desire to dispel doubts and debunk the myths about mitigating controls and SoD challenges was the main motivation and inspiration for us to write this series of 5 articles. Today we give you heads-up it is coming.

We encourage you to read our series of articles and let us know about your thoughts after.

A properly conducted project of building or rebuilding user authorizations in SAP should be based on the segregation of duties matrix in business processes designed during business workshops. It’s the matrix that is the key product of such project, often overlooked and forgotten during system implementation by vendor/implementation companies, who’s priorities are different and are concentrating on launching a new S\4 Hana (ERP) system. Within the last few years, GRC Advisory has carried out a number such workshops in wide range of private businesses as well as public organizations and administrative units. We had trainings in organizations of various sizes – medium companies led by small management team and large international corporations. Among many conclusions which came from these workshops and meetings, the topic of mitigating controls seems to be an interesting and a bit unfamiliar aspect. What are mitigating controls? When do they apply? In the case of many companies that we have had the opportunity to cooperate with by far, the mitigation control seems to be the most common

The mitigating controls are very wide subject, the material has been created and divided into 5 articles:

Challenges for mitigating controls.

When is it worth to create and when should we avoid mitigating controls?

Control examples and repository – Review building best practice.

How to implement mitigating controls in GRC systems?

Summary and conclusions.

My friend and busienss partner andrzejpartyka was a great influencer to this series. We invite you to read the article and learn more on the subject of mitigating controls.

I encourage you to read it

Filip Nowak

GRC & Security Enthusiast

PFCG: merge of authorizations - another explanation with screenshots

2022-12-06T15:55:20+01:00

The technical background and rules for the merge process of authorizations are documented in SAP note

113290 - PFCG: Merge process for authorization data maintenance

To illustrate the described rules, here are some simple examples, which will help to explain the behavior of PFCG in the most common cases. Image/data in this document is from SAP internal systems, sample data, or demo systems. Any resemblance to real
data is purely coincidental.

First thing to know is, how the status of the authorization fields and the entire authorization itself is set:

When an authorization initially is inserted automatically by the merge function, all fields and the authorization have the status ‘Standard’.

If the administrator enters values into an empty Standard field, the status changes to ‘Maintained’.

If the administrator enters values into a Standard field, where proposed values exist, the status changes to ‘Changed’.

If at least one field of an authorization has the status ‘Maintained’, the entire authorization gets the status ‘Maintained’. If at least one field of an authorization has the status ‘Changed’ the authorization gets the status ‘Changed’, no matter, if also fields with status ‘Maintained’ are contained.

With this knowledge we can know, how this authorization has been inserted initially:

This example contains the authorizations for a fictive transaction ZMERGE.

The authorization T-Y055125200 for object S_PROGRAM contains the fields P_GRUOUP and P_ACTION. Both have the status ‘Maintained’. That means, initially, when the authorization was created (Status ‘Standard’) both fields have been empty, means, the defined proposal in SU24 contained no values for those fields:

The administrator entered the value Z* to field P_GROUP (resulting in the status ‘Maintained’ then) and BTCSUBMIT into P_ACTION (resulting in the status ‘Maintained’ then also).

This is important to know!

A common case is now, that the system was updated with support packages or was upgraded.
This role is contained in the result of SU25 step 2c.
Or, the administrator performs any change to the content of the role menu, resulting in a new merge of the existing authorizations.

What happens is, that the existing authorization for S_PROGRAM gets ‘Deleted’ and replaced by a new authorization. It is not clear yet, why.

Let’s have a look at the new situation in PFCG after the merge:

In the right frame we can see that the old authorization with status ‘Maintained’ is deleted (mind the technical name of the authorizations to see the change. Old: T-Y055125200 vs. New: T-Y055125201).
In the main frame we can see that a new authorization with status ‘Standard’ is inserted, with the value BTCSUBMIT in the field P_ACTION.

Why?

One main rule described in SAP note 113290 for existing authorizations with status ‘Maintained’ is:

The authorization remains, if the same fields of the actual SU24-proposal are filled with values as in the original authorization (= the standard authorization, which was entered during the initial merge in the past) of the existing authorization.

This condition is not met in the above example, as the field P_ACTION contains (now) a value in the SU24 proposal.

When the old authorization T-Y055125200 was created, both proposal fields have been empty. We know that, as the old authorization had both fields filled with values and the field status have been ‘Maintained’. (Remind above mentioned behavior: empty standard field, enter values->status is changed to ‘Maintained’)

The merge creates now a new standard authorization T-Y055125201, containing the actual SU24 values, visible in the left frame of above screenshot.

Actual SU24 values:

But why is the existing authorization deleted?

We know already that the original authorization has bee created from a proposal, where both fields of S_PROGARM contained no values (because both fields of the deleted authorization contained values and had the status ‘Maintained’).

But the actual proposal contains a value in field P_ACTION.

So, the merge cannot find a proposal for S_PROGRAM (with both fields empty) for the entries in the role menu. Therefore, this authorization is deleted. The merge cannot know that this old authorization belongs to the existing T-code. The merge checks only the actual proposals and not any history.

Comment:
This is a typical behavior after an update/upgrade, when authorization proposals are changed by SAP (SU22) and taken over into SU24 (with SU25 step 2a).

A similar behavior can be noticed of course if both fields in the proposal would contain these values:

P_ACTION = SUBMIT
P_GROUP = Z*

Based on the initial authorization from above:

The result after the merge is then:

It looks weird, that the existing authorization T-Y055125200 is deleted and a new authorization
T-Y055125201 is inserted – both having the same values! But only, if we would not know the above rules and the different maintenance status of the fields.

The new standard authorization is inserted as there exists no authorization, which’s original (with status ‘Standard’) had the same fields filled with values as the actual proposal (we know, that both fields of the original standard authorization and its proposal were empty, because both fields of the deleted authorization contained values and had the status ‘Maintained’).

Consequently because of the same reason the old authorization is deleted, as there is no entry in the role menu, which has a proposal for S_PROGRAM with both fields empty.

It does not matter, that the new standard authorization contains the same values, as the old, deleted authorization.

Special case: authorizations with status ‘Changed’

Authorizations with status ‘Changed’ exist if values of an existing Standard authorization are added or removed by the administrator.

Based on the last example with a proposal for both fields, P_GROUP = Z* and P_ACTION = BTCSUBMIT, the administrator has added a value SAP* to field P_GROUP. The old authorization looks then like this:

At the next merge of authorizations, the situation is then:

Explanation:

According to SAP note 113290 authorizations with status ‘Changed’ do not participate in the merge process. But the merge of the authorization data includes the authorization default value (standard authorization) once again, from which the changed authorization was generated. So as if the changed authorization would not exist at all.

As of the corrections of SAP note
2421626 – PFCG/PFCGMASSVAL: Improved handling of authorizations with the status “Changed”

for each authorization that switches to the maintenance status "Changed" because of a field value change, the transactions PFCG and PFCGMASSVAL automatically insert the relevant default authorization with the status "Standard inactive", unless at least one other authorization in the status "Standard" or "Maintained” exists for the same object and contains the authorization default value.

If that inactive standard authorization was not deleted, the repeated adding during the merge of the standard authorization can be avoided.

Related notes and KBAs:

KBA 2093228 - PFCG | display changes after merging authorizations - SAP Note 2086293 [VIDEO]
SAP Note 113290 - PFCG: Merge process for authorization data maintenance
SAP Note 1539556 - FAQ | Administration of authorization default values
SAP Note 2421626 – PFCG/PFCGMASSVAL: Improved handling of authorizations with the status “Changed”
SAP Note 2632422 - Authorization objects deleted after merging authorizations

I hope this blog helps a bit to understand some of the 'miracles' of the merge process in PFCG.

SAP authorization testing with reference users

2023-01-05T17:02:34+01:00

1 Use-case

This methodology is especially useful to perform SAP role redesign (small or large scale) where you choose to implement new SAP role(s) for your productive SAP entity, to replace an existing role concept with a new improved role concept and you are looking for a high-quality authorization testing strategy that will require low involvement of business users.

This methodology works well from basis release 7.4 onwards and is also useful if you would like to reduce wide access (like SAP_ALL) from system (or other technical) users and you choose to implement new role(s).

This methodology is not useful:

if you change an existing SAP role that is already assigned to users in your productive system

if you are running an SAP roll-out project (the new SAP entity is not yet in use in the productive system).

Prerequisites:

Your internal controls/ compliance team agrees to transport newly created SAP role(s) all the way to the productive system. This testing methodology is executed directly in production. At a first glance, this sounds risky, however, the risk of granting inappropriate access during the testing phase can be mitigated by various pre-checks.

Critical and/or unnecessary authorizations must not be added to your newly created roles. I guess if you are looking for a methodology like this you are already aware of a bunch of those. (If you use GRC -AC then you should be able to run a risk analysis on the newly created roles already in the development system and you can make sure that you only transport risk-free roles to production)

You have the STUSERTRACE (long-term trace) transaction available in your SAP system and you know how to use it. (This transaction is very well documented so you can easily get your head around it)

2 Summary of the methodology

The process steps are the following:

Design/ Implementation: create the new SAP role(s) as usual and transport them all the way to the productive system

Testing prep:
1. create reference user(s) (user type L) and assign the reference user to the “normal” SAP user ID(s)
2. assign the new role(s) to the reference user
3. set up a long-term trace for the “normal” user(s) (STUSERTRACE)

Testing: Analyze STUSERTRACE results and apply corrections

Go live (switch the roles of the reference user and the regular SAP user ID and remove the reference user)

Hyper care (in case something goes wrong for any reason you can still add back the reference user and analyze the root cause without stress)

Closure – remove the “old” roles and the reference users as necessary

Figure - 1 (picture was made by me)

Using this methodology, you can achieve very good test results for potential authorization issues without the user(s) even knowing that they are testing, and because everything is happening in the productive system this is real end-to-end, in-depth testing, and it does not require extra effort from the business.

3 Detailed explanation

3.1 Set up reference users

Once you are done with the role implementation in your development system and transported all the newly created roles to your productive system, you will need to continue creating users with user type “L- Reference”. Depending on the scenario you might need to create one dedicated reference user for each regular user, but it is also possible to assign the same reference user to multiple regular user IDs.

Figure - 2 (picture was taken by me)

It is not possible to log in with the reference user itself, so this does not mean that the “normal” users will have 2 user IDs. This is a technical user type that can only be assigned to the regular SAP user ID.

Luckily this has no impact on your license cost because the reference users are normally not counted by SLAW2 but better to be double-checked just to avoid any surprises.

3.2 Add reference users to regular SAP user IDs

You need to add the reference user to the regular user on the “Roles” tab in SU01/SU10:

Figure - 3 (picture was taken by me)

There is an entry in the PRGN_CUST table (REF_USER_CHECK) that controls the system behavior when you are trying to assign a user ID here which is not “L – Reference” type.

Figure - 4 (picture was taken by me)

In case you are using central user administration (CUA) then you will need to create the reference user(s) in all systems where the regular user is created, otherwise, the user segment of the USERCLONE idoc will fail for those systems where the regular user ID is created but the reference user not.

If you are using an SAP system under basis release 7.50 then the maximum number of profiles that can be assigned to a user is 312. The reference user does not have an effect on this limit meaning the regular user has a threshold of 312 and the reference user also have its own threshold of the same size.

3.3 Set up long-term authorization trace (STUSERTRACE)

One of the key elements of this testing methodology if you have the STUSERTRACE transaction code in your SAP system.

This transaction code is well documented in SAP and also there are good blog posts about it on SCN, for example, https://blogs.sap.com/2021/09/20/stusertrace-new-tracing-option-authorization-trace-for-user/

STUSERTRACE is collecting the data into a dedicated SAP table: (SUAUTHVALTRC) which sometimes makes the analysis easier and while you are running STUSERTRACE you still can use ST01 or STAUTHTRACE as usual.

To sum up:

you have created reference user(s) and assigned them to the regular SAP user ID

you assigned the new roles to the reference users

you have activated the long-term trace and set up the filter for the regular user IDs

At this point, you basically started the testing. You need to start the process of analyzing the trace results. In the authorization trace, you will see whether an authorization check was successful via the reference user or via the normal user or if it was not successful at all.

Figure - 5 (picture was taken by me)

The reason why this methodology works well is that SAP authorizations are checked in sequence. First, the system checks if the reference user has the right authorization if not, then the system checks if the regular SAP user has the necessary authorization, this is why you needed to add the new roles to the reference users and keep the old roles for the regular SAP user ID. So basically, in this way you can run a “what-if” analysis regarding what would happen if the regular user had the new roles only.

Figure - 6 (picture was taken by me)

3.4 Analyze results and fix issues

This is a bit weird but in this case, the lines which could be potential issues in STUSERTRACE are the ones that are successful without additional information (please see Figure - 5), because these authorization checks were successful with the authorizations of the regular user, so that is something which is missing from your new roles. Some of these values could be missing on purpose, therefore, those will be false-positive, this is something that requires careful analysis.

The lines which are successful with the additional information “Authorized Through Reference User” are those authorization checks which will be successful with your new roles.

The lines where the authorization check failed (either RC = 4 or 12) are cases where the access was already missing from the regular user (therefore from your "old" role) too.

You can run the analysis as long as you feel confident that there are no issues left. The main advantage is that the business users will not notice any difference, they are doing their day-to-day job just like before and you will get a very detailed in-depth testing result.

Once again just to state the obvious: it is important that not all failed authorization checks are issues, and not all passed authorization checks are OK, so when you apply this technical methodology, you need to know what you are doing.

4 A few drawbacks

This is a technical approach to authorization testing and even if it has some major benefits (high testing quality and low business involvement) there are also a few drawbacks:

You cannot apply this methodology for roles that are already assigned to users in your productive system and you cannot apply this methodology for entities which not yet live in your productive system.

You need to transport new roles all the way to prod. In some cases, this might not be possible, however, it worth a try to convince your internal controls team 😊

There are a few things that are not “added” from the reference user
This methodology is useful for testing ABAP authorizations, so any other element of your “old” role (for example role menu for Fiori or NWBC, role technical name-based workflow, or other bespoke implementations which are depending on the role technical name) might not be tested with this methodology
Also, you might not be able to test the access aspects related to user parameters and other user master data-related settings.

According to the documentation, a maximum of 1000 users can be traced at the time without performance impact. This number might be too low depending on the scale of your testing.

Technical issues: I did not face any technical issues however, I found some blog posts on SCN and a few SAP support notes, about the STUSERTRACE transaction and the authorization checks of the reference users. These most likely have been fixed by the later support packages, but you might check what is your SAP version/ release and you start with some investigation first.

5 Conclusion

Even if this methodology is quite technical and requires a bit more preparation than a usual test approach, I personally found it useful and effective. After a 3 month testing, while I only used this methodology there were only a very few minor issues after go-live.

Please ask/ answer SAP Access Control related questions here:
https://answers.sap.com/tags/01200615320800000796

Please follow/ comment SAP Access Control related topics here:
https://blogs.sap.com/tags/01200615320800000796/

Please share below in the comment section your thoughts, and ideas on this blog post.

SAP Security Role Redesigning [Edition 1/2]

2023-01-18T09:57:44+01:00

Edition 1- SAP Security Role Redesigning

WHAT IS ROLE REDESIGNING?

A Role redesign, also sometimes referred to as security redesign or role remediation, refers to significant changes to SAP roles that impact the authorizations of SAP users.It is basically based on the principle of separation of duties (SoD). Due to different SoD requirements between companies, the final SoD review takes place in the customer concept, based on a defined set of rules.

REASON OF ROLE REDESIGNING:

There are various reason why organizations Decide
to commencement on a role redesigning project,
Involve:

Segregation of Duty (SoD), is the concept of
having more than one person required to
complete a task. Effective SOD in an
organization is intended to prevent fraud and
error.

Changes of organizational structure,

Upgrade of SAP Systems

Migrations to SAP S/4HANA

Over-authorized users,

Legal requirements,

The desire to simplify role administration

IMPROVE SECURITY BY REDESIGNING YOUR SAP AUTHORIZATIONS

An authorization concept is highly complex and subject to dynamic changes.

We provide the single roles that cover the major functions of SAP S/4HANA and SAP ERP.

We adapt the naming conventions of our template roles to individual customers.

We adapt the naming conventions of our template roles to individual customer.

The roles are delivered with a standardized specification of the documentation structure in the role long text.

If you use our role template, you benefit from enormous time savings, which will also be reflected in your project budget

At the same time, you can grant access authorizations according to the need-to-know principle, which means each user is only assigned
the authorizations they need to perform their day-to-day work.

By automating your SAP role generation, you can conserve valuable internal resources while at the same time guaranteeing the security
of your data and systems.

The role design is based on the principle of separation of duties (SoD).

BENEFITS OF SAP SECURITY ROLE REDESIGNING

Reduces Fraud/Risk :

One thing that falls upon every organization is taking care of some events that can put SAP system at risk. These events involve-

Removing and adding authorizations for a short time period

External IP logins and logins at irregular time/hours

Inactive users or dormant user accounts

Managing segregation of duty (SoD) implications

Transparency in the design:

SAP system optimization is another crucial task for many businesses. Reducing and optimization of authorizations is an important activity that SAP system
requires and it is successfully achieved with the right SAP security design. Implementing roles and authorizations that are free from risks and SoD
complications leads to transparency of user authorizations and makes your audit easy. In addition, a proper and well-defined change management process will
help you keep your system clean at any point in time.

Define the right role architecture/design:

Lay the foundation for picking up the right design. When you are about to choose the right role design, ensure that the role architecture is designed to reduce your
existing access risks (in case of a new implementation, build risk-free roles).

The roles can be either

Single, master, derived, and composite roles (These are the technical designs that can be further broken into job-based and task-based
roles)

Job-based and task-based roles (Based on the job function, or business task)

Position-based design (Roles assigned to a position in the HR system. Every user will have the required access based on his/her position)

Monitor your system 24/7 to keep it in a healthy state:

Now that you have understood the importance of a well-designed security strategy, you need to monitor it to ensure that the design is
within the defined boundaries and your business data is safe. SAP GRC Audit Management (AM) is one such solution that can be
designed to monitor your SAP security system.

Consuming a Business Technology Platform service from an S/4 HANA system using SM59 destination with OAuth

2023-05-19T20:17:30+02:00

EDIT Oct 2023 - This feature is now available from release 750 with SAP note 3324172

Scenario Description

In this blog, I present an introduction to OAuth and explain how to implement and configure the consumption of an OAuth-enabled service provided by the SAP Business Technology Platform from an SAP S/4HANA system (here workflow service on cloud foundry is used as an example) using the CL_HTTP_CLIENT class and SM59 destination. The blog only focuses on the client credentials and SAML Bearer Assertion grant types.

We create a simple runnable ABAP class consuming an SM59 destination pointing to the REST API offered by the workflow service for cloud foundry. This is used to get details of the workflow definitions in the subaccount on SAP Business Technology Platform. The SM59 destination shall be configured for using OAuth with client credentials or SAML Bearer flow, as desired.

Note: Here, the workflow service’s REST API is used only for demonstration. In a real use case where you need to connect to the workflow service, there is a dedicated API for this. [Read More…]

Introduction to OAuth

In the traditional client-server authentication model, the client requests an access-restricted resource (protected resource) on the server by authenticating with the server using the resource owner's credentials (basic authentication). To provide third-party applications with access to restricted resources, the resource owner shares its credentials with the third party.

Third-party application access in client-server model

This creates several problems and limitations such as:

Third-party applications may store the resource owner's credentials for future use, potentially as clear text or with poor encryption.

Servers are required to support password authentication, despite the security weaknesses inherent in passwords.

Third-party applications gain overly broad access to the resource owner's protected resources, leaving resource owners without any ability to restrict duration or access to a limited subset of resources

Resource owners cannot revoke access to an individual third party without revoking access to all third parties, and must do so by changing the password

Compromise of any third-party application results in compromise of the end-user's password and all the data protected by that password

OAuth addresses these issues by introducing an authorization layer and separating the role of the client from that of the resource owner. In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server. The client is issued a different set of credentials than those of the resource owner.

Instead of using the resource owner's credentials to access protected resources, the client obtains an access token -- a string denoting a specific scope, lifetime, and other access attributes. Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server. [Source: https://www.rfc-editor.org/rfc/rfc6749#page-4]

Third-party application access with OAuth

OAuth Client Credentials v/s SAML Bearer Assertion

In this blog, I cover the client credentials and SAML Bearer assertion grant types. It is therefore important to know when to use each of these.

The Client Credentials grant type is used by clients to obtain an access token outside of the context of a user. [Read more…]. This works with the client ID and client secret.

The OAuth SAML bearer assertion grant on the other hand can be used to propagate the principal (the logged on user) from S/4HANA to the Business Technology Platform. [Read more…]

How to use OAuth to connect from SAP S/4 HANA to an SAP Business Technology Platform service

The following image shows the activities performed by different personas

Activities performed by different personas

The steps broadly involve the following:

Create OAuth 2.0 client profile in SE80

Establish Trust between the S/4HANA system and the subaccount on SAP Business Technology Platform

Create OAuth configuration with the appropriate type (SAML Bearer/Client Credentials/…) using the profile created above

Create destination to connect to the BTP service in SM59

Consume the destination in code

The subsequent sections of this blog detail the steps listed above.

1. Gather the necessary information needed for configuration

1.1. As security administrator of the subaccount on SAP Business Technology Platform

Download SAML metadata from the subaccount on SAP Business Technology Platform, where the service instance to be consumed (workflow in our example) is created.

As security administrator of the subaccount where the service resides, go to the “Trust Configuration” section in the menu and use the “Download SAML Metadata” button

Open the SAML metadata file and note the following details. These details would be used in future steps
- EntityID - This is the entity ID of the SAML service provider and will be used as SAML Audience for our OAuth SAML Bearer assertion configuration later
- Location of the SAML binding URI (which contains /oauth/token) - This would be our token service URL in the configuration

1.2. As space developer of the subaccount on SAP Business Technology Platform

Go to the Business Technology Platform service instance (workflow service in this example) and read the service key details. If a service key does not exist, you could create one as per the documentation. Following information is required from the service key:

1.2.1. Client ID, Client Secret and URL

The Client ID and Client Secret would be used against the corresponding fields in the configuration.

The authorization endpoint in the configuration would be the URL from the service key followed by "/oauth/authorize" without spaces.

1.2.2. Endpoints - WORKFLOW REST URL

The host for our SM59 destination used to connect to the workflow service shall be this URL without the https://

The part of this URL after “.com” shall form the path prefix of our SM59 destination for a basic connection to the workflow service. To make this more meaningful, we will enhance this path prefix with the specific REST endpoint for the workflow definitions.

1.3. Using web browser to access the API Business Hub

To identify the specific path to the workflow-definitions endpoint, go to the API Business Hub (api.sap.com)

Search for the “Workflow service for cloud foundry”

Navigate to the API Reference section and pick a suitable path prefix (example: workflow-definitions)

The summary of required details and where to find them is presented by the following image

2. Establish trust between the S/4HANA System and the Business Technology Platform

2.1. As administrator of the S/4HANA system

Note: This step can be skipped if client credentials grant type is used. See section OAuth configuration with client credentials.

For the S/4HANA system to issue a SAML assertion and for the Business Technology Platform to validate this, we need to establish trust. To achieve this -

Enable SAML 2.0 by clicking the “SAML 2.0 Enabled” button

Download SAML 2.0 metadata using the “Download SAML 2.0 Metadata” button

Note: If the download button is not visible, apply SAP Note 3229914.

2.2. As security administrator of the subaccount on SAP Business Technology Platform

Note: This step can be skipped if client credentials grant type is used. See section OAuth configuration with client credentials.

To set the ABAP system as the SAML Assertion issuer for getting the credentials (Email) whenever a token is requested, upload the SAML 2.0 Metadata downloaded in step 3, to the subaccount on SAP Business Technology Platform.

As security administrator, go to the trust configuration section of the subaccount which contains the service instance you wish to use (in our example, workflow)

Click the “New Trust Configuration” button

Upload the SAML 2.0 metadata downloaded from the OA2C_CONFIG transaction.

After the upload, a new identity provider (IDP) would be listed with the name specified in the form

Note: We do not need this identity provider (IDP) for user logon. Therefore, make sure to disable the “Available for user logon” checkbox.

2.3. Add SSL/TLS digital signature certificate to the certificate list of the SSL Client Anonymous PSE (Personal Security Environment)

To establish a trusted relationship using the OAuth 2.0 client with SAP Business Technology Platform, you must use an SSL/TLS communication channel between your service provider (SAP BTP) and the SAP S/4HANA System. For this purpose, the service provider (SAP BTP) and the SAP S/4HANA System must trust each other. This is achieved by placing the SSL/TLS digital signature certificate of the service provider (SAP BTP) in the certificate list of the SSL Client Anonymous PSE (Personal Security Environment) of the SAP S/4HANA system.

2.3.1. Using web browser in the SAP Business Technology Platform,

To achieve this, open the subaccount and from the address bar of the browser, click the lock icon

Go to “Connection is secure”->” Certificate is valid”

Go to the details tab and export the certificate for the root CA of the certificate hierarchy

2.3.2. As administrator in the S/4HANA system

In the S/4HANA system, go to transaction STRUST and open the edit mode

Under the SSL Client (Anonymous), double click the subject. Scroll down to the certificate section and click the import certificate button

Import the certificate exported above and save

3. Configure connection to the BTP service via OAuth

To make sure that users access only the resources that are exposed to them, you can restrict access through scopes in an OAuth client profile. An OAuth 2.0 scope represents a list of resources that can be accessed by remote applications.

3.1. As developer on the S/4HANA system

In the SAP S/4HANA system, use transaction SE80.

Under your development package, create an OAUTH 2.0 Client Profile. This is used to define the scopes. For simplicity, I do not specify any scopes in our example

Note: Specifying the wildcard * under scopes is NOT the same as not specifying any scopes. Specifying such a wildcard could cause errors.

3.2. As Administrator on the S/4HANA system

Next, we need a client for our communication. The communication between OAuth 2.0 client and server is secured by an HTTPS connection. The end users can then use services and resources offered by the service provider
- Use T-code OA2C_CONFIG to create an OAUTH 2.0 client.
- When requested for OAUTH profile name, use the profile name created SE80. Use Client ID copied from the information gathering stage.

We now can choose the OAuth method we wish to use. In the current blog, we restrict the explanation to only the Client Credentials and SAML Bearer Assertion approaches.

3.2.1. OAuth Configuration with Client Credentials

Provide the following details based on the results of the information gathering section

Client Secret

Authorization Endpoint

Token Endpoint

Remaining Details:
- Client Authentication: Form Fields
- Resource Access Authentication: Header Field
- Selected Grant Type: Client Credentials

3.2.2. OAuth Configuration with SAML Bearer Assertion

Provide the following details based on the results of the information gathering section

Client secret

Authorization Endpoint

Token Endpoint

SAML 2.0 audience

SAML 2.0 recipient: <Auto populated using Token endpoint>

Remaining Details:
- Client Authentication: Form Fields/Basic
- Resource Access Authentication: Header Field
- Selected Grant Type: Current User Related
- Grant Type (Current User Related): SAML 2.0 Bearer Assertion
- User Email for SAML 2.0 Name ID: 000

Once configuration is done and saved, a test could be done using T-Code OA2C_GRANT. Select the profile and click on the button “Request OAUTH 2.0 Token”. If everything is configured correctly, the “Access Status” column will be green and “Receive Date”, “Receive Time” would be filled

Note: The OA2C_GRANT transaction, shown under administrator activities on SAP S/4HANA can only be used to request access tokens for user-related grant types, i.e. SAML Bearer Assertion grant type (see section OAuth configuration with SAML Bearer Assertion) and Authorization Code grant type (not covered in this blog). The OA2C_GRANT app cannot be used to request an access token for OAuth configurations where the Client Credentials grant type is selected

Since we are propagating the email ID for single sign-on, users in the S/4HANA system should have email id maintained. Use transaction SU01 to verify this

3.3. As Security Administrator on the Business Technology Platform

Assign Roles/Role Collections to S/4HANA On Premise specific users (by using the new IDP we set up).
This step is only needed if you chose the OAuth SAML Bearer Assertion in the previous step

3.4. As Administrator in the S/4HANA system, create SM59 destination with OAuth settings

On the S/4HANA System, go to transaction SM59 and create a destination of type G (HTTP connections to external server). We use Type G since we wish to connect to BTP which is external.

Under the technical settings tab, provide the following details:
- Host: api.workflow-sap.cfapps.sap.hana.ondemand.com (Obtained in the information gathering section)
- Path Prefix: /workflow-service/rest/v1/workflow-definitions (Here, and /v1/workflow-definitions is the additional path we use to get the workflow-definitions)
- Port: 443 (Default HTTPS port)

Under the Logon and Security tab,
- Use the OAuth Settings button to link the OAuth configuration we did earlier with the SM59 destination
- Click the button and provide the OAuth profile name and OAuth configuration names as defined in corresponding steps

- Scroll down to the security options and under “Status of Secure Protocol”, ensure the following:
  - SSL: Active
  - SSL Certificate: ANONYM SSL Client (Anonymous)

Perform a connection test to ensure everything is set up correctly. If all configuration is correct, you should get a status code 200

4. Use the destination in ABAP Code

The SM59 destination, now linked to the OAuth configuration can be used in ABAP code as demonstrated in the following runnable class (created as developer in the S/4HANA system)

class ZCL_OAUTH_BTP_WF definition



public



final



create public .



public section.



INTERFACES IF_OO_ADT_CLASSRUN.



protected section.



private section.



ENDCLASS.



CLASS ZCL_OAUTH_BTP_WF IMPLEMENTATION.



METHOD IF_OO_ADT_CLASSRUN~MAIN.



TRY.



* Create HTTP client using the SM59 Destination with log-on configured using OAuth



CALL METHOD cl_http_client=>create_by_destination



EXPORTING



destination = 'S4H_2021_BTP_WF' "Name of SM59 Destination



IMPORTING



client = DATA(http_client).



IF sy-subrc <> 0.



out->write( 'Could not create http client' ).



ENDIF.



* In productive code, handle potentially raised exceptions better. Not handled here for brevity



http_client->send( ).



http_client->receive( ).



http_client->response->get_status( IMPORTING



code = DATA(status_code)



reason = DATA(http_status_description) ).



out->write( 'HTTP Status: ' && status_code ).



* Read the parsed character data from the HTTP response



DATA(workflow_definition_data) = http_client->response->get_cdata( ).



out->write( workflow_definition_data ).



* Generic exception handling done for brevity



IF http_client->oauth_last_err_txt IS NOT INITIAL.



out->write( http_client->oauth_last_err_txt ).



ENDIF.



CATCH cx_root INTO DATA(exception).



out->write( exception->get_longtext( ) ).



ENDTRY.



ENDMETHOD.



ENDCLASS.

Executing this class, provides the details of workflow definitions in the subaccount

For some troubleshooting guidance in case of issues and to share your experiences with issues you may face, please refer the following blog: Troubleshooting errors when connecting to a service on SAP Business Technology Platform through OAuth

What is your experience with OAuth in SAP software? Looking forward to discussions in the comments section!

Troubleshooting errors when connecting to a service on SAP Business Technology Platform through OAuth

2023-05-19T20:28:08+02:00

Motivation:

In my earlier blog, Consuming a Business Technology Platform service from an S/4 HANA system using SM59 destination with OAuth, I covered what it takes to connect to an SAP BTP service from S/4HANA on-premise using OAuth. Here, we look at some errors one may come across and how to troubleshoot them. This is by no means an exhaustive list and I encourage you to share the errors/issues you face in the comments section so over a period, this grows into a document that can help a lot of people

Useful troubleshooting technique:

Run the report OA2C_GENERIC_ACCESS with SE38. This is a report that can be used to test the OAuth 2.0 client configuration/access tokens request (for all grant types). The report shows the complete raw error response which might be helpful for troubleshooting.
Example:
Error when trust configuration is missing/wrong on the Business Technology Platform:

Error when “<URL>/oauth/token” is configured as token endpoint in OA2C_CONFIG instead of “<URL>/oauth/token/alias/mytenant” (from the downloaded SAML Metadata):

Some other errors/issues along with solutions:

Download SAML Metadata button not visible in t-code OA2C_CONFIG
Solution: Apply SAP Note 3229914.

OA2C_GRANT does not return OAuth 2.0 token
Solution: In OA2C_CONFIG, for the created configuration, verify if the following are correctly mapped:
- Client ID/ Client Secret are as defined in the service key of the BTP service being connected to (workflow service in this example)
- The SAML 2.0 Audience is the "Entity ID" from the SAML Metadata of the sub-account which we are connecting to. The SAML metadata can be downloaded under "Trust Configuration" section of the sub-account
- The Token End Point is the Location ID from the SAML metadata of the sub-account which contains "/oauth/token". Ensure the Location ID is copied along with alias

Error: "Create Failed" when doing a connection test in SM59
Solution: Check the token service URL in OA2C_CONFIG. Check if "https://" is repeated. Note: This is automatically added and while copy-pasting the URL, this needs to be done without https://

Error: "Connection to <URL> broken" when doing a connection test in SM59
Solution: Under the Logon and Security Tab of the SM59 destination, under status of secure protocol, make sure SSL is active and the right SSL certificate is chosen (where the certificate from BTP was imported)

Additional material for troubleshooting at the level of the XSUAA service on the Business Technology Platform:

Status Code 401: https://ga.support.sap.com/dtp/viewer/index.html#/tree/2212/actions/28290:52819

SAML Issues: https://ga.support.sap.com/dtp/viewer/index.html#/tree/2212/actions/28290
- E.g. https://ga.support.sap.com/dtp/viewer/index.html#/tree/2212/actions/28290:48369 or https://ga.support.sap.com/dtp/viewer/index.html#/tree/2212/actions/28290:48362

Trust Establishment in general (both SAML and OIDC): https://help.sap.com/docs/btp/sap-business-technology-platform/establish-trust-and-federation-between-uaa-and-identity-authentication

Attribute Mapping (SAML): https://help.sap.com/docs/btp/sap-business-technology-platform/federation-attribute-settings-of-any-identity-provider

Looking forward to hearing your experiences with this setup, the issues/struggles you had or on the other hand, the great experience you had!

Should we use SAP Standard Roles or not.

2023-07-25T22:13:28+02:00

As SAP security practitioners, we frequently encounter a critical decision-making process concerning the effective management of user access. Today, we will explore a pivotal subject that often sparks debates within the SAP community: The utilization of SAP Standard Roles.

SAP Standard Roles are predefined roles provided by SAP for each of its applications or modules, identifiable by their nomenclature starting with "SAP*."

SAP's Recommendation:

SAP advises against direct usage of standard roles and instead recommends utilizing them as a reference for creating customized roles within the client namespace. It is not mandatory for the client namespace to be designated as Z* or Y*, as long as the roles created do not commence with SAP* and are tailored to suit the specific requirements of the client.

In fact, any attempt to create a role starting with SAP will result in an error message stating: "Role SAPXXX... is not in the customer namespace."

Rationale for Avoidance:

The suggestion to avoid employing SAP standard roles is based on several reasons:

Security Risks: SAP standard roles are generic and grant extensive authorizations, potentially exposing sensitive data and functionalities unnecessarily.

Compliance Concerns: Standard roles may not align with industry-specific compliance requirements, leading to potential audit failures and legal consequences.

Limited Flexibility: Standard roles may not cater to an organization's unique business processes and security needs, hindering the ability to customize authorizations effectively.

Complex Role Management: As the organization expands, managing and updating standard roles can become cumbersome, whereas custom roles can be more efficiently maintained.

Reduced Efficiency: SAP standard roles often provide more access privileges than required, compromising user efficiency and increasing the risk of misuse.

Conflict Resolution: Addressing segregation of duties (SoD) conflicts or user access issues with standard roles can be challenging due to their generalized nature.

Impact of SAP Updates: SAP system upgrades may modify standard roles, potentially disrupting user access and necessitating additional configuration efforts.

Recommended Approach:

To overcome these challenges, it is advisable to implement custom roles based on the principle of least privilege. Custom roles offer more precise control over user access, aligning authorizations with specific job duties and ensuring compliance with industry regulations.

Engaging in a Professional Discourse - Welcome Your Valuable Contributions! 💼

I cordially extend an invitation to SAP enthusiasts, security experts, and professionals to participate in a constructive conversation. Together, let us exchange insightful thoughts, valuable experiences, and industry best practices pertaining to SAP access management. We encourage you to share success stories, encountered challenges, and innovative solutions in the comments section below. Your contributions will undoubtedly enrich the discussion and foster a collaborative learning environment.

BW/4HANA Security: SAP BW/4HANA Migration (Remote Conversion)

2023-08-06T05:44:48+02:00

Introduction

SAP BW/4HANA is a next generation data warehouse solution developed by SAP. The underlying foundation of SAP BW/4HANA is the SAP HANA in-memory database, which means that the data is stored and processed in the main memory of the server resulting faster data retrieval, processing, and analytics compared to traditional disk-based databases.

SAP BW/4HANA simplifies data modeling, enables real-time analytics, and supports integration with advanced technologies like big data and machine learning. It helps organizations consolidate, manage, and analyze large volumes of data, providing timely insights for data-driven decision-making.

Organizations that have been using the earlier version of SAP BW can migrate to SAP BW/4HANA. The migration process involves converting the existing data models, objects, and applications to the new platform, taking advantage of the improved features and capabilities.

Business Scenario:

Organization is planning to migrate from BW to BW/4HANA solution but they are keen to know the impact on security authorizations. Also, the security authorization activities to be carried out as a part of the migration. This article will help the organization to achieve their requirements in terms of security authorizations.

Step1: Transport SU25 changes

Create a transport request in BW system for customer tables.

Transport the customer tables from BW to BW/4HANA system.

Step2: SAP BW Users.

Discuss with the business about the SAP BW user master i.e. how they want to handle the users in BW/4HANA system.

If business agrees for client copy via BW system then copy profile SAP_UONL (User Without Authorization Profiles and Roles) into BW/4HANA system.

Step3: Transport BW Analysis Authorizations

Discuss with the business and identify the list of BW analysis authorizations which are in scope i.e. BW analysis authorizations which needs to be available in BW/4HANA system.

Transport the scoped analysis authorizations from BW to BW/4HANA system.

Step4: Transport BW roles

Discuss with the business and identify the list of BW roles which are in scope i.e. BW roles which needs to be available in BW/4HANA system.

Transport the scoped roles from BW to BW/4HANA system.

Step5: Run SU25 Steps

Execute SU25 steps i.e. Step 2A, 2B, 2D and 2C

Extract the list of impacted roles, discuss with the business and remediate the roles.

Step6: Execute Transfer of Authorizations into BW/4HANA

BW specific authorizations for object types get impacted when we convert SAP BW to SAP BW/4HANA system like InfoCubes and those must be replaced by authorizations for corresponding object types like ADSO.

Program “RS_B4HTAU_CREATE_RUN” gives you the list of impacted authorizations for the corresponding object types.

Run Program “RS_B4HTAU_CREATE_RUN” into BW/4HANA system.

Fig.1.1

Create Rule ID to perform Transfer of Authorizations

Fig.1.2

Add the required BW/scoped roles which needs to be analyzed.

Fig.1.3

Click on the settings button to add the Suffix for the new BW/4HANA role i.e. when you execute this tool, system automatically creates new role with adjustment of authorizations for corresponding object types.

Fig.1.4

Selected BW/scoped roles with corresponding new BW/4HANA roles (with suffix) gets available in the Transfer of Authorizations tool.

Fig.1.5

Click on Initial Run and Delta Run to perform the analysis on the selected BW roles.

Fig.1.6

The output of Initial Run and Delta Run gives you the following Action Types:

ASSUME: No change in authorizations for object types i.e. Authorization will continue to work even after the conversion.

Fig.1.7

ADJUST: Check if there is any change in the values of authorization object and adapt it accordingly.

Fig.1.8

REPLACE: Change the Authorization Objects and adapt it's values accordingly.

Fig.1.9

Fig.1.10

OBSOLETE: Authorization object is not supported or obsolete, should be removed/deactivated from the role.

Fig.1.11

Click on the Generate button to create and generate the new BW/4HANA role with defined suffix.

Fig.1.12

Role gets created & generated into BW/4HANA system with automatically adjustments of All Action Types.

Note:

If there is a business requirement that not to create any new role and wants to make use of the existing role then based on the Action Types, existing roles must be modified manually via PFCG.

SAP BW/4HANA has some Fiori Apps which can be enabled and mapped into the roles based on the business requirement.

List of Important Notes:

2383530 - Conversion from SAP BW to SAP BW/4HANA

2468657 - BW4SL & BWbridgeSL - Standard Authorizations

2930058 - FAQ - SAP BW/4 Conversions

List of Important Links:

Security Guide SAP BW∕4HANA

Feedbacks, questions and comments are most welcome!!

Please follow my profile for future posts on SAP Security and GRC. Also, follow myself via LinkedIn

Happy Learnings!

Krishan .

Filter table maintenance view rows based on user authorizations

2023-09-01T17:02:26+02:00

Requirement

We have a custom Z-table with Sales Organization and Order Type as key fields.

There's an associated maintenance view.

Users will be using this maintenance view to maintain entries in the table.

Users should only be allowed to display and edit records that belong to the sales organizations and certain order types that they are authorized to.

The usual approach

As many of the articles would suggest, the most sought-after approach would be to create 2 authorization objects (one for sales org, one for order type) and then use maintenance view Events 01 (Before saving the data in the database) and AA (Instead of the standard data read routine) to check each row's data against the authorization object and remove unauthorized entries.

Pros:

If the authorization objects are already in place and assigned to the user, there's no work to be done from the authorization (BASIS) perspective.

As this is purely a custom logic, this also gives freedom to introduce new error messages, extra validations, etc.

Cons:

There is coding involved as the authorization check happens at the code level.

As there's custom code involved, there will be increased unit test efforts for positive and negative scenarios to ensure that all scenarios (display, change, insert, delete) work as expected.

If we don't authorize the maintenance view from standard auth objects (S_TABU_DIS), the user should have "change" access to the SM30 transaction. Then the coding will have to control everything else. With the user getting "change" permissions to SM30, other Z tables will also become changeable - which is not what we expect.

One can't see from the authorization object assignment perspective whether there is an object assigned to the maintenance view or not.

The better approach

We can use the two standard authorization objects and the maintenance view's authorization group to handle this requirement with no code changes.

The authorization checks, error handling, and everything is handled by the standard itself which takes a significant burden off our shoulders. Also, we can clearly see in user roles how the assignment is done.

Here are the steps:

Authorization Group setup

This is needed only if you don't have an Authorization Group created already.

1. Go to the table maintenance view generator, and create an Authorization Group via Environment > Authorization > Authorization Group
2. In the new screen, under object S_TABU_DIS, create a new Authorization Group with a 4-character name that starts with Z. For this scenario, let's say it's ZAUT.
3. Go back, and assign this new Authorization Group in the Table Maintenance Dialog Genearator window.

Authorization Object: S_TABU_LIN setup

Go to SPRO > IMG > SAP NetWeaver > Application Server > System Administration > Users and Authorization > Line-oriented Authorization > Define organizational criteria

Create new Organization criteria entry:

We don't need to do anything for the "Assignment of authority object to organizational c" step.

Select the created entry, and go to "Attributes". Then, hit "New Entry". Here, we can list up to 8 attributes. The attributes are basically the key fields that we need to filter the records based on values that we define later. In this example, we need 2 attributes - VKORG, AUART. Create the first:

Hit the "Next Entry" button and create the second attribute as well. Note that the "Authorization fld:" value at the bottom of the screen is now changed to ORG_FIELD2 from ORG_FIELD1 for VKORG.

Then, go to "Table Fields" in the left-side tree. And create an entry specifying our custom table and field name that would align with this attribute.

Do the same for the next field (Attribute 2) as well. And continue to do this for all the attributes you've defined.

Once done, save under a workbench TR and exit.

Authorization Object configuration from BASIS

Now, it's time to set the appropriate values for the respective authorization objects so the setup starts working as we want.

Set "Change" permission for the Authorization Group via the S_TABU_DIS authorization object. To do so, set
ACTVT = 02
DICBERCLS = ZAUT (authorization group assigned to the table)
This allows the user to access the tables with auth group ZAUT in change mode.

Set row-level filtering via S_TABU_LIN authorization object. Set values as
ACTVT = 02
ORG_CRIT = ZTESTAUTH (this is the new organization criteria we created in SPRO)
ORG_FIELD1 = <sales org>
ORG_FIELD2 = <order type>

With this setup, it says that the user can insert/change/delete the entries belonging to sales org 1030 and order type ZORD.

Assign these to respective roles and to the users as usual and let the standard take care of all the validations, etc.

Useful Links

SAP's documentation on S_TABU_LIN

A step-by-step guide on setting up S_TABU_LIN including the authorization assignment

Custom Tcode Management

2023-09-22T00:31:35+02:00

As an SAP Authorization Administrator would have come across with Functional/IT team creating Custom tcodes for a specific Business purpose and requesting Auth team to include into a suitable role.

There are many projects/organizations still not managing custom tcodes methodically, leading to audit deficiency and in some cases misuse of critical access assigned via custom tcode.

Also, if custom tcodes technical name not based on functionality i.e Create/Change/Display, then it will be a tedious effort to categorize and also mapping into GRC ruleset for the first time, when there are hundreds of custom tcodes to be looked into.

Purpose

This document provides information on managing Custom Tcodes in any organization from an SAP Authorization team perspective.

Introduction

In SAP we have many modules and each module has specific tcodes in place to process Business data. There are few instances where Business team needs to be restricted with few fields or added more fields in a standard tcode provided by SAP. This type of requirement differs from Business to Business.

There also few scenarios when Custom data managed in a custom table, needs to be given access to Business/IT teams for data processing.

Business Case

Let’s take an example a Business team intend to restrict Company Code data field in the SAP standard tcode XK02 i.e changing Vendor. Hence based on Business requirement a Custom tcode copy of XK02 need to build with restricted Company Code Data field.

Based on my experience and per SAP best practice, i would suggest the below steps as a SAP Authorization Administrator.

Step 1: Whenever there is a need for Custom development, make sure it is relevant, unless the business requirement cannot be fulfilled/managed by SAP standard tcode. If there is an alternative tcode, suggest Business team to leverage with the same and avoid custom development.

SAP Functional/ABAP team should involve Authorization team from the initial discussions since Business team mostly contact Functional team. This will help Auth team to understand the requirement in terms of auth checks, objects, table access requirement etc.

Step 2: Upon the requirement is finalized, let there be a Functional/Technical Spec document for Custom tcode which includes Custom program names, objects, tables, Custom tcode and most important functionality i.e Create/Change/Display type of the tcode. As per SAP best practice it is suggested to use SAP standard objects within custom program and it is fine to create custom tables if needed.

Also, insist ABAP team to name custom tcode based on the nature of tcode i.e ending with 01 for create/ending with 02 for change etc. and update suitable Tcode description as per the type, since this will help to identify type of tcode if there is no proper documentation.

Step 3: Upon ABAP/Functional team completes necessary developments in Dev system, Authorization team can build a test role with new Custom tcode added and assign test role to a test user for further testing from Functional team.

Enable Auth trace for the test user to capture the auth check objects within the trace.

Scenario 1: If no objects traced when tcode successfully executed, it means there is no Authority check enabled in the Custom Program and hence inform ABAP team to include suitable objects under Authority-Check section of the custom program. Relevant Auth objects can also be identified if custom tcode is a copy of standard tcode in SU24 and same can be enabled for Custom tcode program.

Scenario 2: If objects are populated in the Auth trace as missing auth, then relevant object can be added into test role to make sure it executes successfully. Later inform ABAP team to include in the Authority-Check section with relevant objects, if not enabled in the custom program. Please make note of these objects which required to be added into SU24.

Step 4: Other option to get objects relevant by executing program RS_ABAP_SOURCE_SCAN with below mentioned search strings and based on the results ,we could classify Change/Display tcode ,based on objects with Activity i.e Change/Display.

AUTHORITY-CHECK
BDC_INSERT
CALL FUNCTION
Call Transaction
Call Method
Submit Report
Submit
Update table/Database
Delete from

Step 5: Maintain relevant Auth objects identified from previous steps into SU24 with required Values as well. After saving the changes, it will request for a Workbench transport request and capture in the same.

Step 6: Assign custom tcode into desired Business Role and make sure Auth objects are populated into the role, which were included in SU24.

Step 7: Get the necessary Unit testing performed to make sure Custom tcode functionality works as expected and proceed further with Quality for UAT.

Also update into GRC Ruleset if tcode is a Business sensitive Access (BSA) with relevant Risk id & objects and its values mapped and check for SOD conflict with existing tcodes in the role.

Please follow the sequence of ABAP/Functional changes to be moved first and followed by Security i.e SU24 and Role changes into Production system.

Key Take Aways

- Auth team involvement from early stage of requirement gathering.

- Avoid custom development if standard functionality is not available/possible.

- Suitable Naming Conventions, Authority-check enablement in Custom program by ABAP team.

- Update into SU24 with relevant objects/values and GRC Ruleset if tcode is BSA.

- Follow Sequencing of ABAP/Functional changes followed by Auth changes into Production system.

Relation between SAP S/4HANA System Upgrade | Migration | Conversion and SAP Security Upgrade

2023-12-20T00:13:38+01:00

In the ever-evolving world of SAP, it is indispensable to update Security and Authorizations as per Standard and Latest Controls. Upgrade | Migration | Conversion collectively known SAP Landscape Maintenance are the Core Project Transitions in SAP.

It is significant for a Security Consultant to understand | distinguish the above.

In this blog, I will present a crisp knowledge on Upgrade | Migration | Conversion and discuss how does it impact SAP Authorizations and when Security Upgrade should be performed.

What is SAP SECURITY UPGRADE?

SAP introduces New | Updated authorizations (Transaction Code | Authorization Object | Authorization Field | Authorization Check Indicator) to SAP Tables – USOBT | USOBX during Core Component Upgrade.

SU25 – Security Upgrade Tool will be used to update the authorizations to Customer Tables – USOBT_C | USOBX_C. Impact of Security Upgrade will be reflecting in roles post execution of Upgrade Steps – 2A, 2B, 2D and 2C.

Note : As of Dec 2023, customer can Upgrade | Convert to SAP S/4HANA 2020 & above versions (Reference SAP Note: 3338941)

CONVERSION : Customer who is in SAP ERP Central Component (ECC) getting CONVERTED to Latest SAP S/4HANA version

SAP Conversion

UPGRADE : Customer who is already in SAP S/4HANA getting UPGRADED to Latest SAP S/4HANA version

SAP Upgrade

Database Migration : This can be categorized into three approaches, and it accords only to Database.
- Lift & Shift : Homogeneous Migration of SAP Database without changing the Database type in source and target host.
- Export & Import : Migrating Database from one host to another host where source and target host may or may not have same Database type.
- Database Migration Option : Popularly known as DMO, is an option in Software Update Manager (SUM) to move the data from Non-HANA Database to HANA Database. SUM meanwhile offers Homogeneous DMO for SAP HANA to SAP HANA Migration.

SAP Migration

SUMMARY :

It is fundamental to perform Security Upgrade for Conversion and Upgrade scenarios as there is change | upgrade in SAP ABAP Component Version.

When Software Provisioning Manager (SWPM) is used for Homogeneous and Heterogenous Database Migration - Security Upgrade is not required as there is no change in SAP ABAP Component Version.

When Software Update Manager (SUM) is used for Database Migration combined with Upgrade or Conversion - Security Upgrade is required as there will be change in SAP ABAP Component Version.

SAP User Access Reviews: Best practices

2024-01-13T11:28:39+01:00

Let’s understand with a use case:

A global enterprise that uses SAP for its operations employed an executive who sensitive customer and financial information as part of his job. He was later promoted to a different position and was given new authorizations to carry out new tasks as part of his job duties. Unfortunately, while the new access was granted, no one looked at what he has or revoked the previous authorizations that are no longer relevant. As a result, this individual continued to retain both sets of authorizations.

He started utilizing these authorizations by creating numerous fake vendor accounts and subsequently approved payments to these non-existent vendors. Surprisingly, these actions went unnoticed within the company until an internal audit unearthed this irregularity.

Although this scenario may seem uncommon, many enterprises encounter similar situations. So, how to have a control on these kind of scenarios? Does SAP provide any tools/solutions to implement better controls?

Many compliance frameworks mandate period authorization reviews. Performing regular User Access Reviews holds importance in maintaining a secure and efficient system within an organization. Here are some of the advantages of conducting periodic User Access Reviews:

Advantages of conducting User Access Reviews

Additionally, in recent years, many regulations such as SOX/JSOX, ISMS and GDPR has mandated enterprises to perform User Access Reviews. However, executing these controls can be exceedingly time-consuming, potentially impeding core business activities.

This article puts a spotlight on User Access Reviews, offering insights into optimizing and streamlining this pivotal process for your organization's benefit.

Why are SAP User Access Reviews crucial?

Principally, User Access Reviews are primarily conducted for audit purposes. Mandates such as Sarbanes Oxley (SOX) and JSOX necessitate periodic User Access Reviews, commonly performed annually or semi-annually by listed organizations.

The crux of User Access Reviews lies in validating the relevance of SAP access that is provided to a user over a period of time at a later stage. For instance, if the user has requested access to ME21N (Create Purchase Orders) transaction code and it was approved few years back, does that access remain pertinent today, considering potential job function changes or role adjustments?

Consequently, User Access Reviews afford organizations the chance to reassess a user's access, ensuring its continued relevance amidst potential shifts in roles or job functions. An added benefit is correcting and ensuring that SAP authorizations are well managed.

Nonetheless, for many organizations, conducting a User Access Review solely to fulfil audit requirements, especially given the significant effort required from business users. However, there's a pressing need to shift the mindset surrounding User Access Reviews from a mere audit checkbox to an effective tool for managing access risks.

How can this mindset change be fostered?

To encourage a shift in thinking within organizations, it's crucial to emphasize the consequences of not performing the reviews. If the access control process is perceived as complex, the initial step is to simplify it and set up the right process of managing accesses and regular review procedures. This not only limits the authorizations, but also helps in identifying the users with unnecessary authorizations and further contributes insights for restructuring and streamlining the authorization processes. For instance, you can pinpoint users with access to critical permissions and remove those permissions when they are no longer necessary for their job duties.

Diagram that show the Mindset Shift in enterprises wrt Authorization Reviews

After simplifying the access control process and setting up regular reviews, the next step is to implement an automated system. Various solutions such as SAP GRC Access Control User Access Review (UAR), or ReviewNow streamline User Access Reviews by providing comprehensive information, aiding users in making informed decisions. Such tools can be configured to expedite the process and present technical SAP role language in user-friendly terms.

How to achieve better output?

How to achieve better output with User Access Reviews

Role Design: Many organizations adapt to role design approaches that are complex to understand and manage. For example: Enabler roles. It is highly recommend to simplify the SAP role design to aid users in comprehending user access easily. A descriptive role design facilitates informed decisions by users during the review process.

Role Methodology: Opt for a role methodology that reduces the number of role assignments, making the User Access Review less arduous for business users. Consider methodologies like task based and value based roles to streamline access.

Rule-set Customization: Customized rule-sets empower business users to better understand the potential access risks, aiding informed decisions during the review.

Split Reviews: Consider segregating reviews into User Access Reviews, Critical Authorization Reviews, Reviews for key business users and so on. This enhances the focus and efficiency of each review.

Iterative Reviews: Divide large annual reviews into smaller, more manageable reviews across geographical regions, risk levels, user groups, or SAP modules. This minimizes certification fatigue among reviewers and enhances efficiency.

By implementing these strategies and emphasizing the value of User Access Reviews beyond mere audit compliance, organizations can effectively manage access risks while ensuring the process remains user-friendly and impactful.

Conclusion:

In conclusion, SAP User Access Reviews are critical to safeguard the organization from potential inside and outside attacks and adhere to compliance with regulations like SOX and JSOX. While these reviews offer benefits, a mindset shift is needed to view them not just as audit checkboxes but as tools for effective access risk management. The article suggests simplifying access processes, establishing systematic reviews, and emphasizing the consequences of neglect. Automation tools like SAP GRC Access Control User Access Review or ReviewNow can streamline and simplify the process. Practical strategies include role design simplification, efficient methodologies, rule-set customization, and iterative reviews. Implementing these recommendations ensures a user-friendly and impactful User Access Review process that aligns with business goals.

Basis Monitoring & Tcodes with Key notes

2024-02-05T14:25:53.980000+01:00

Hi All,

I am thrilled to have the opportunity to connect with all of you through this blog.

The purpose of this blog is to aid newcomers in Basis in gaining knowledge about Basis-related Tcodes, including key notes and their usage and frequency.

I believe this will be beneficial for those who are beginning their careers in SAP Basis.

I wish you good luck and welcome to SAP Basis Team

The Daily Monitoring Basis-related Tcodes, their uses, and their related Tcodes are utilised for any future investigation.

Tcodes that pertain to operating systems and databases, their usage, and any future process.

The SAP Basis Admin is accountable for tuning performance. These Tcodes are associated with performance analysis at the application level.

Ticketing tools vary widely between organizations, including SAP ITSM (SOLMAN), Non SAP (ServiceNow, Zendesk), and others.

User Management, Role Management, and Transport Management will receive the majority of daily ticketing. Here are the Tcodes that pertain to these areas.

Tcodes that pertain to SAP Software Maintenance and related OS and other tasks.

Programs that are useful for administrative tasks related to Basis.

Thank you for taking the time to read the blog.

#SAPBasis #Basis Basis Technology EWM - Basis NW ABAP Monitoring Tools SAP EarlyWatch Alert SAP HANA Cloud, SAP HANA database SAP Advantage Database Server Oracle Database SAP S/4HANA SAP NetWeaver Application Server for SAP S/4HANA #Dailymonitoring NW Java Security and User Management Defense and Security SOLMAN Setup/Configuration/LMDB NW ABAP Monitoring Tools SOLMAN System Monitoring

User types in SAP ABAP Stack Systems

2024-02-28T14:30:09.735000+01:00

This blog will outline the various user types found in SAP ABAP Stack Systems

User Types

In SAP systems, Users play a pivotal role in accessing and utilizing the various functionalities provided by the system.

In the Transaction SU01- user management system, we primarily categorize users into five distinct types:
1.Dialog

2.System
3.Communication
4.Reference
5. Service

Dialog Users (A): These are regular users who interact with the SAP system through the graphical user interface (GUI) or web interface ( SAP GUI for HTML). They perform tasks such as entering data, running reports, and executing transactions relevant to their roles assigned to them.

Multiple logon is checked.

System Users(B): System users are typically used for background tasks, such as running batch jobs, executing automated processes, or performing system-to-system communication. They do not require direct interaction with the GUI.

Multiple logon is allowed, Only an administrator user can change the password.

Communication Users (C ) : Communication users are primarily used to establish connections and facilitate communication between SAP systems or between SAP systems and external applications, services, platforms and integration scenarios such as RFC (Remote Function Call), SOAP (Simple Object Access Protocol), HTTP (Hypertext Transfer Protocol), IDoc (Intermediate Document), ALE (Application Link Enabling), EDI (Electronic Data Interchange), and more .

Logon with SAPGUI is not possible

Reference Users (L) :Reference users are special types of user accounts that serve as templates or blueprints for creating new user accounts with predefined settings, roles, authorizations, and other attributes. They are used to streamline the process of user creation and ensure consistency across user profiles within the SAP system

No logon possible.

Service Users (S) : Service users are considered technical users because they are primarily used for technical tasks rather than human interaction. They are often assigned specific technical roles and authorizations required for performing their designated tasks.

unlike regular dialog users who interact with the SAP system through the graphical user interface (GUI), service users typically do not require direct interaction with the GUI. They may communicate with the system through interfaces, APIs (Application Programming Interfaces), or background processes.however SAP GUI logon is Possible

Multiple Log on allowed.

User Master Record
User Master Record in SAP is a fundamental component that stores and manages information about individual users who access the SAP system

Creation of user accounts in SAP systems is client-dependent, meaning that user master records must be established separately in each client where users need access.

User Master Record in SAP contains a variety of information pertaining to individual users who access the SAP system. This information is crucial for managing user access, permissions, and preferences within the SAP environment. These are the key components typically found in a user master record:

User Details Like Name, Department, function, responsibilities, user group, user type and License

User Details with Validity ,Lock Status, and authentication properties

User Settings Like parameters, spool requests, time zone.

Note : User details, such as user IDs, hashed passwords, authorizations, and related information, are stored in the USR02 table

User Deletion

User deletion is always possible and can be done using the transactions SU01 or SU10. During the deletion, all of the personal data belonging to the user master is deleted

Deletion Effects: Deleting a user account in SAP has several effect such as

The user's access to the SAP system is immediately revoked.

Any active sessions associated with the deleted user account are terminated

Authorization objects and roles assigned to the user are removed.

User-related data stored in tables such as USR02 (User Master Record) is deleted.

After deleting a user account, administrators may need to perform additional tasks, such as reassigning responsibilities to other users, updating documentation, or communicating the deletion to relevant stakeholders

#basis #abapstack #netweaver #ECC SAP S/4HANA

SAP S/4HANA - Extracting User Email Addresses from Standard Tables

2024-05-10T15:09:30.362000+02:00

What are we discussing here?

When working with SAP systems, it is fundamental to need / verify user email addresses for various purposes. Whether it is to send Automated Notifications, facilitating communication between users, or Generating Reports, having accurate and up-to-date email addresses is crucial. However, extracting the email address from SAP system is not as easy as we think. In this blog post, we will explore the simplest method to extract / find email addresses of users from SAP Standard tables.

Note : There is no direct transaction code or program to extract email addresses of users

How are we going to achieve it?

The primary table that stores user information in SAP is USR21. This table contains User Master Data, including Personal Numbers (PERSNUMBER) associated with each user. To retrieve email addresses, we will link this table with the address data table ADR6.

What is USR21?

USR21 is a standard table in SAP ERP system that assigns User Names and Address Keys.

What is ADR6?

The ADR6 table in SAP ERP system is a standard table that stores email addresses (Business Address Services) for any address record.

Procedure to Extract Email Address from SAP Tables

Execute table view transaction code: SE16 -> Enter Table Name : USR21 -> Execute

Provide the list of User ID(s) through Multiple Selection for BNAME -> Execute

Copy the list of Personnel Number (PERSNUMBER) for the users

Execute table view transaction code: SE16 -> Enter Table Name: ADR6 -> Execute

Provide the list of Personnel Number(s) through Multiple Selection for PERSNUMBER -> Execute

SMTP_ADDR column of ADR6 table will provide the list of email address for users

SAP also offers to extract the list into Spreadsheet from this screen

Tip : Ensure to select ALV Grid Display in User Specific Settings at initial screen of ADR6

What are other options?

Another approach for SAP S/4HANA is to leverage the built-in Core Data Services (CDS) view.

Table : PUSER002 can also be used | BNAME = UserName | Ensure column SMTP_ADDR is visible

Word of Caution

Avoid Unintended Disclosure

When querying SAP tables, be cautious not to inadvertently disclose email addresses to unauthorized users or external sources.

Limit access to relevant personnel and follow proper authorization procedures.

Remember, accurate and secure email addresses contribute to smooth business processes and effective communication within your organization. Handle them responsibly, and always prioritize data protection.

If you have any further questions or need assistance, do not hesitate to comment on this blog. Happy SAP querying!

Feel free to share this article with your colleagues and peers who work with SAP systems.