SAP Community - Security

Security approach in SAP Conversion projects

2025-01-28T10:29:03.956000+01:00

This is a step-by-step detailed procedure document on the security steps required in SAP conversion projects for instance during system conversion from ECC to S4HANA. If you are new to conversion this document can be used as reference to get started.

This document is divided into three sections based on the different stages of projects – pre upgrade, upgrade and post upgrade.

Objective:

After the system conversion, SAP will bring in new authorization checks or update existing ones and from security perspective our task is to re-adjust the existing roles to accommodate all the authorization changes that have been brought in due to conversion. This is referred to as role remediation. Along with the role remediation, customers would like to explore the Fiori apps as well. Our task can also include setup of Fiori roles to provide access to the apps.

Preparation / Pre-Upgrade Phase:

From security perspective we should do detailed analysis of the role design strategy in the as-is system (for e.g. ECC ). For instance, analysis of parent – child roles, composite role, single roles as per the current design of the system. This will give us the idea of what type of roles are assigned to users, is it single / composite / derived roles. It will give us the view of roles that we might need to remediate and define the scope of work.
We should remediate the master roles only in case of parent – child role concept is followed. Once the master role is remediated, changes are pushed to all the child roles. In case single role concept is followed, then all these roles need to be remediated.
Before the system conversion starts, we should take backup of below tables in the existing ECC system. These can be used for reference at later stage during remediation of roles:

AGR_USERS
USR02
USOBT
USOBT_C
USOBX
USOBX_C
AGR_DEFINE
AGR_1251
AGR_1252
AGR_AGRS
AGR_TCODES

Download list of transactions executed in last 13 months from production. This will be helpful in determining the scope of the remediation of roles.
Finalise the Fiori strategy with the client on how the end users will login in Fiori launchpad, as this will be new for them. Will they be using SSO to login, customer branding on the launchpad screen, spaces and pages concept, list of apps in scope, to accommodate the new apps in existing roles or new roles to be setup for Fiori.
You might have to give some demos to client on the Fiori spaces and pages concept once you have the S4 system ready.
Once the system is converted follow the below steps in the converted S4 system.
Execute table PRGN_CORR2 and download the extract. This will help to find replaced SAP S4 Hana transaction codes against ECC obsolete transaction codes.
Implement recommendations of SAP Note 440231

Execute program SU24_AUTO_REPAIR

This step will help to resolve SU24 errors such as below:

Reviewing the security profile parameters – After system conversion SAP might bring in updates to the profile parameters which concerns the security. We can keep the parameter value which are existing in ECC system or keep the SAP suggested values based on the customer requirement. This is important to consider as parameter for min password length, complexity, etc differs in S4 and ECC. This will have an effect on how user’s login.

Upgrade Phase:

Once the system is handed over by the Basis team after system conversion, we can start the role remediation tasks in sandbox or development system. It is advisable to keep screenshots of all the steps executed as proof of reference.
You will get good idea of the scope of work from the report of Step 2D and Step 2C.
We will execute the SU25 transaction to update the SU24 and customer tables with the SU22 changes which SAP have brought in as part of conversion.
Do not execute Step 1 as it is generally done during initial setup of system. It will overwrite all the customer changes done in SU24.

Execute STEP 2A in SU25 – In this step, SAP would compare and adjust transaction codes to auth object mapping automatically and the scope would include transaction codes for which the SU24 mapping has not been changed by the customer. Execute the step 2A with the below options. First in test mode and check the outcome. Then uncheck the test mode and run it. It will copy the SU22 data to SU24, wherever there is no conflict.

Execute STEP 2B in SU25 - In this step, the system would give an insight about the transactions for which SU24 mapping has been changed. Most of the customers prefer to keep the existing mapping and do not change to SAP standard.

Execute Step 2D in SU25 - This step would give an insight into obsolete transaction codes and its effect on roles. It would give you report about which transactions need to be replaced in which role. This report gives the reason also why SAP is suggesting replacing the existing transaction and it would be due to transaction not existing, locked or being obsolete in the upgraded environment. Once you have the report, work with your functional team in identifying the replacement transactions. Security team will have to adjust the menu and generate the profile of those affected corresponding roles. The list of changes required as part of step 2D needs approval from customer before making changes in the roles.

Execute Step 2C in SU25 – In this step, we get the roles affected due to conversion. Roles get affected mainly for below reasons:
New Authorization objects get checked against a transaction. This will appear in the role as Standard New.
Another instance of existing authorization object can be pulled in with SAP recommended values.

List of roles to be remediated should be reviewed and approved by the customer. In this step each role affected is maintained manually in PFCG. In PFCG, role is open is expert mode -> Read old status and merge with new data, option.

As best practice, we will not activate the new authorization objects and during the testing phase, we will activate the authorization objects based on the authorization errors. This way we will not end up giving higher access, following the principle of "Least Access Privilege".

Role Remediation Steps – This is the major task for security team in conversion projects. Below are some scenarios of the type of updates required in roles, while executing the expert mode -> Read old values and merge with new data. Only roles used by the customer should be remediated.

Role that need only profile generation - In this case, authorization objects will have status old, and no new authorization object is introduced in the role. Hence this requires only profile generation.

Role with two or more instances of the same authorization object i.e. Old & New - In this case, a new instance of the same authorization object gets added in roles. As per best practice, we will deactivate the new auth object and keep the old values as is. Based on the testing, the new authorization objects will be activated. This is aligned with the principle of "Least Access Privilege".

Roles with new authorization object - In this case a new authorization object gets added in roles. We can deactivate these new objects . They can be adjusted later based on the access issues encountered during testing.

Role with update status in authorization object - In this case, few authorization objects will have value as Updated – This means that the value in this object has been changed during merge, some field value might have been dropped from the object. Refer to the production version of this role and add the updated value through comparison.

Role with deleted authorization object - In this case, few authorization objects would have been dropped from the roles. We must compare the production version of the role and re-add the dropped values. Check the simulation report of STEP 2C to find out the list of dropped values, but they should be cross verified with the production version of the role.

Role with new org level values - In this case, new org level values is added to the role. We can deactivate the new authorization object and activate it again during the testing. In case we need to add the org level values, we can refer to the existing roles or reach out to customer for this.

Retrofit Changes – If your upgrade system is happening in a separate box, you need to consider the retrofit changes also. These are the changes which happened in the existing ECC system, while upgrade was happening in the S4 system which is running on a different box. All the role changes done during this period in the existing ECC system, should be retrofitted in the new S4 system. This will ensure you will not lose any changes done in ECC during the period of upgrade.

Post upgrade phase

After all the roles are remediated, we need to create the transport of SU24 changes and affected roles and move to the subsequent systems.
It is important to unit test few transactions and roles from security perspective before releasing for UAT.
Setup UAT users as per the customer requirement and release for testing.
Adjust the authorization object values in roles based on the testing.

Identity and Access Management with Microsoft Entra, Part II: Provisioning to BTP and S/4HANA

2025-01-29T11:46:09.997000+01:00

Part I of this blog series described a federated approach for cross-domain identity and access management by using the groups claim in the OAuth access token sent by Microsoft Entra ID to the SAP Cloud Identity Services (CIS) Identity Authentication tenant. With the tenant acting as an identity provider (IdP) proxy in part I, the user's group membership(s) in the groups claim were forwarded to the SAP Business Technology Platform (BTP). By sharing the user's identity information in a secure and interoperable token across system and technology boundaries, the application on BTP (SAP Business Application Studio) could successfully authenticate and authorize the user, even without creating a user account in the application's database or in the CIS tenant's identity directory.

Part II of the blog post series extends the Cloud-only scenario in part I with a hybrid identity setup that requires managing the user lifecycle across Microsoft Active Directory, Microsoft Entra, SAP BTP, SAP CIS, and an SAP system on-premise. Again, this blog post aims to provide technical guidance for migrating identity management processes from SAP Identity Management (IDM) to Microsoft Entra. Kudos to Marko Sommer (@MSo) for supporting the SAP cloud setup.

📢 📢 📢 Note

For a live demo recording (in German language) of the scenario in this blog post, check out the online session from January 16th 2025 with the Deutschsprachige SAP Anwendergruppe e.V. (DSAG) working group Identity Access Management. For a demo in English language, tune in to the SAP on Azure video podcast episode 226.

Scenario overview

Similar to part I, this scenario follows SAP's reference architecture for Cloud-leading identity lifecycle, It relies on the Identity Provisioning service (IPS) in SAP Cloud Identity Services (CIS) to replicate users stored in the CIS tenant's Identity Directory into the target application(s), which is an SAP Application Server ABAP system on-premises in this scenario. This scenario also continues like in part I to use access packages from Entitlement Management in Microsoft Entra ID Governance to centrally control who has access to which resources across the application portfolio of the fictitious company BestRun Corp.

Figure 1 shows the hybrid landscape and provisioning flow for a new employee. Instead of the manual approval workflow as implemented in part I, the objective in this part is to fully automate the lifecycle management of user accounts, license assignments, and authorizations of new employees with Entra and ClS to implement the following requirements:

Every new employee must have instant access to the productivity and AI tools from BestRun's Microsoft 365 enterprise subscription.
Employees in BestRun's IT department need access to the SAP system on-premise with the required authorizations for ABAP development. BestRun's security policy requires an SNC (Secure Network Communications)-secured connection and single sign-on (SSO) from SAP GUI with a Kerberos ticket issued by the corporate Active Directory (AD) Domain Controller (DC). For SSO, the Kerberos principal for the Windows user must be mapped to the SAP user in the backend.

Figure 1: User provisioning from Entra to BTP and S/4HANA

Let's have a look at the provisioning flow for a new user in this hybrid scenario in more detail:

A new user account is created in BestRun's AD for the new employee. Every employee has a common set of organizational attributes, such as companyName ("BestRun Corp.") and department, which is set according to the employee's role in the organization, for example "Information Technology" for new members in BestRun's IT team.
The Microsoft Entra Cloud Sync Provisioning Agent on the DC host provides the connectivity between the corporate network and Microsoft Entra ID. It takes care for synchronizing users and groups created, updated or deleted in AD to BestRun's Entra ID tenant every 2 minutes.
The agent follows the de-facto standard SCIM (System for Cross-domain Identity Management) 2.0 that is detailed in SCIM 2.0 Core Schema (RFC 7643) and SCIM 2.0 Protocol (RFC 7644) to provision and deprovision users and groups in Entra ID. The agent also supports the synchronization of the user password hash to allow users to sign-in to Cloud services like Microsoft 365 with the same password they use to sign in to the AD on-premise. With password writeback, the agent enables self-service scenarios to reset or change the user's password in the Cloud, and have that updated password synchronized back to the AD on-premises environment. To configure the provisioning from AD, the Entra administrator creates a syncronization configuration for the agent in the Cloud that can be tailored towards specific users or groups, mapping of attributes etc.
To auto-assign new employees and their accounts to a Microsoft 365 license, the M365 access package has a policy configured to automatically assigns each (new or updated) user with the attribute companyName set to "BestRun Corp." and who are members (not guests) in the Entra ID tenant to the "M365 User" group. In the Microsoft 365 admin center, the Microsoft 365 license is assigned to the "M365 User" group.
A second access package in this scenario, "SAP A4H", auto-assigns users to the "SAP User" group who have their department attribute set to the value "Information Technology".
Configuring the Entra ID tenant to provision users into the SAP CIS tenant requires to add "SAP Cloud Identity Services" from the Microsoft Entra application gallery to the Entra ID tenant's list of enterprise applications. This enterprise application is scoped to provision only users from the "SAP User" group, and has access to the credentials (username and password) of a system administrator with the name "Entra tenant bestruncorp" created in the SAP CIS tenant. This system administrator account has the required authorization in the SAP CIS tenant to execute the provisioning operations in the scenario. For applications listed in the gallery like "SAP Cloud Identity Services", provisioning follows the SCIM standard to ensure cross-domain interoperability. The enterprise application centrally controls all required identity attribute mapping and transformation logic in the scenario, such as the SAP login name derived from the Windows user name, and construction of the SNC mapping following the format "p:<Windows user name>@<Kerberos realm name>". For transferring both values to CIS, the custom attributes defined in SAP's SCIM user schema extension "urn:sap:cloud:scim:schemas:extension:custom:2.0:User" are used.
New users in Entra are provisioned to the SAP CIS tenant's identity directory. As the persistent layer in the SAP CIS tenant, the identity directory is the source system in the tenant's IPS for the synchronization of users and groups to downstream target systems, such as the on-premise SAP system in this scenario.
SAP CIS IPS uses SAP BTP's connectivity service to establish a secure connection from CIS to the SAP system on the corporate network. All required configuration settings for the connection, such as the SAP System ID or authentication details to connect to the SAP application server, are stored in a destination in the SAP BTP subaccount. For the provisioning service to successfully use the destination and connectivity service, the BTP subaccount must have a subscription to the SAP CIS tenant with plan type "connectivity" and the required entitlement in the subaccount for it.
Finally, the connectivity services uses the destination to establish the connection to the SAP system on-prem via the SAP Cloud Connector.
Cloud connector uses the SAP Java Connector (JCo) to call the Business Application Programming Interfaces (BAPIs) for managing users in the SAP ABAP application server and creating the new user in the system. As part of this operation, it also writes the SNC mapping required for SSO that were created in step 6 with the attribute transformation in Entra.

Prerequisites and lab setup

Before you start, check if you fulfill the following prerequisites for a working lab environment for this scenario:

A test or productive CIS tenant with full administrative access. Note: This scenario cannot be implement with a free trial tenant because it cannot connect to on-premise systems using the cloud connector.
An SAP BTP enterprise account (a global account of type enterprise). Note: It is not possible to subscribe to the CIS connectivity plan in a trial account. If you do not have an enterprise account and wish to explore or buy one, you may refer to a pay-as-you-go license.
Administrative access to a subaccount in your enterprise account that maps to the CIS tenant's region according to the table documented here. For example, if your CIS tenant is located in "US West", your subaccount must be created in the BTP region "US West (WA)" on Azure. Once you create the subaccount, you must enable Cloud Foundry for this subaccount.
Administrator-level access to an Microsoft Entra ID P2 subscription. You can obtain a P2 tenant for development and learning purposes with a free Microsoft 365 E5 developer program subscription. To qualify for the developer program, a valid Visual Studio subscription is required. With this subscription you can request a trial of Microsoft Entra ID Governance by following these steps.
Administrative access to an AD Domain Services (DS) instance. I've created this system in my lab environment as a Hyper-V Windows Server 2019 guest operation system Virtual Machine (VM) on my Windows 11 host, but you can also run your AD instance in the cloud on an Azure VM. The VM has the AD DS role added to it and is promoted to a DC following this documentation. The domain name used in this tutorial is corp.bestrun.com (NetBIOS: CORP), but you can also choose a different name. The VM has the Microsoft Entra Provisioning Agent installed following these instructions, and the SAP Cloud Connector as documented here. Configuration of the provisioning agent and cloud connector for the scenario will be covered in the tutorial steps below.
Administrative access to an SAP Application Server ABAP that serves as the target system in the provisioning scenario. One of the easiest ways to setup a free development and test system is to run the ABAP Platform Trial on Docker. Setup of the SNC configuration for Kerberos SSO is described in this related blog post (see section "Configure SAP for Kerberos-based SSO with Active Directory").
For testing a successful end-to-end provisioning in this scenario, the user will single sign-on via SAP GUI to the SAP system. This requires a Windows 10 or 11 workstation that is domain-joined and has SAP GUI for Windows and SAP Secure Login Client (SLC) installed. In my lab environment, I am running Windows 10 in a Hyper-V VM to simulate the user's workstation. In a simplified setup you can also run the test from the AD DC.

Ready? Then let's get started with preparing the SAP system for the integration with IPS. Some steps will refer to the associated GitHub repository that contains configuration files to simplify the setup.

Create System User and Role for provisioning in the SAP system

A system user with the required authorizations to execute the user management BAPIs will be created in the SAP system and its credentials will be shared later to configure the destination for IPS in SAP BTP.

Step	Description	Screenshot
1.1	Login to the SAP ABAP application server as an administrator (e.g. user DEVELOPER if you are using the ABAP Developer trial Docker image). All steps in this tutorial will be executed in SAP logon client "001", but you may choose a different client. Start by creating a role with the required authorizations for provisioning users from IPS. Execute transaction PFCG for role maintenance. Enter SAP_BC_JSF_COMMUNICATION in the Role field and click Copy.
1.2	Enter name of the new role in the to role field, for example "ZIPS_USER_PROVISIONING". Click Copy all.
1.3	Enter the new role's name in the Role field and click Change.
1.4	Change the Description and Long Text. Click Save. Switch to the Authorizations tab.
1.5	Click Change Authorization Data.
1.6	Expand the subtree of Object class AAAB. For Authorization object S_RFC, click Change to edit the value of field name RFC_NAME for Authorization "Authorizat. 01".
1.7	Scroll down in the table and select the first empty row. Enter RFC_METADATA_GET in the 'From' field. Select the next empty row, and enter RFCPING in the 'From' field. The table should now list the following RFC function modules that are authorized with the new role ZIPS_USER_PROVISIONING copied from SAP_BC_JSF_COMMUNICATION: BAPI_USER_ACTGROUPS_ASSIGN BAPI_USER_CREATE1 BAPI_USER_DELETE BAPI_USER_GETLIST BAPI_USER_GET_DETAIL IDENTITY_MODIFY PRGN_ACTIVITY_GROUPS_LOAD_RFC PRGN_ROLE_GETLIST RFC_METADATA_GET RFCPING Click Save.
1.8	Click Generate to update the profile(s).
1.9	Confirm the generation of the new default profile for your role.
1.10	Click Exit.
1.11	Go to user maintenance with transaction code "/nSU01".
1.12	In the User field, enter "SAPIPS". Click Create User (F8).
1.13	Enter "SAPIPS" for the Last Name. Switch to the Logon Data tab.
1.14	Select User Type "System". Enter a password in New Password, and enter it again in Repeat Password. Note: You will need the password later for the configuration of the destination for IPS in SAP BTP. Click Save.
1.15	Switch to the Roles tab. Select the Role column of the first row in the Role assignment table and click on the value help button.
1.16	Switch to the Single Roles tab. In the Single Role field, enter "ZIPS_" Click Start Search*.
1.17	Activate the checkbox for the ZIPS_USER_PROVISIONING role in the search results. Click Copy.
1.18	Click Save.

Configure SAP Cloud Connector

The following steps assume that the SAP Cloud Connector is already installed and started on the AD DC host with Internet access and connectivity to the SAP system on the internal network.

Step	Description	Screenshot
2.1	Login to the SAP BTP Cockpit and select your subaccount. As mentioned in the prerequisites section, make sure that the region of the selected subaccount maps to the region of your CIS tenant as documented in this table.
2.2	Navigate to Connectivity -> Cloud Connectors. Click Download Authentication Data.
2.3	Login to the AD DC as the domain administrator. Open a browser and access the login page of your SAP Cloud Connector instance at https://<AD DC IP address or hostname>:8443 Login with the SAP Cloud Connector Administrator user.
2.4	Click Add subaccount.
2.5	Select Configure using authentication data from file. Click Next.
2.6	Click Browse and select the file you downloaded in step 2.2. Click Next.
2.7	Click Finish.
2.8	Navigate to Cloud To On-Premise in the newly added subaccount. On the ACCESS CONTROL tab, click '+' to add a new system mapping.
2.9	Select "ABAP System" as the Back-end Type. Click Next.
2.10	Select RFC as the Protocol. Click Next.
2.11	Select Without load balancing (application server and instance number). Click Next.
2.12	Enter your SAP ABAP server IP address in the Application Server field. Enter the instance number (e.g. '00' if you are using the ABAP Platform Trial on Docker). Click Next.
2.13	Enter a name for the Virtual Application Server, e.g. "sap<SID>" ("sapa4h" if you are using the ABAP Platform Trial on Docker). Enter a Virtual Instance Number (e.g. "00"). Click Next.
2.14	The value for the entry field System ID should be populated automatically in a few seconds with the SID for your ABAP application server (e.g. "A4H" if you are using the ABAP Platform Trial on Docker). Click Next.
2.15	Optionally enter a description for the new system mapping. Click Next.
2.16	Activate the checkbox for Check Internal Host. Click Finish.
2.17	The new system mapping for the ABAP system is added to the list and should report the status Reachable in the column Check Result.
2.18	Click '+' in the Resources Of section to add the function modules accessible for this system. Alternatively, you can also click Import. Download the resource file from this Git repository and import it. You can then skip steps 2.19 and 2.20.
2.19	Enter PRGN_ROLE_GETLIST for the Function Name. Click Save.
2.20	Repeat the previous step for the following functions: BAPI_USER_ACTGROUPS_ASSIGN BAPI_USER_CREATE1 BAPI_USER_DELETE BAPI_USER_GETLIST BAPI_USER_GET_DETAIL IDENTITY_MODIFY PRGN_ACTIVITY_GROUPS_LOAD_RFC

Configure the destination in the SAP BTP subaccount

With the SAP Cloud Connector now connected to the subaccount, a destination from SAP BTP to the SAP system on-premise is required to enable IPS to provision the users.

Step	Description	Screenshot
3.1	Go back to the SAP BTP Cockpit browser window from the previous step. Verify that the Cloud Connector is successfully connected to the subaccount and shows the ABAP application server in the Exposed Back-End Systems section. Navigate to Connectivity -> Destinations.
3.2	Click Create Destination. Note: You cal also click Import Destination and import the configuration from this file on the Git repository. Enter the password from step 1.3 and verify the property values against your setup. Save the destination and continue with step 3.6.
3.3	Enter the following values: Name: For example "SAP<SID>" ("SAPA4H" for ABAP Platform Trial on Docker) Type: Select "RFC" Proxy Type: Select "OnPremise" User: "SAPIPS" (see step 1.1) Password: The password you entered in step 1.3. Authorization Type: Select "CONFIGURED_USER" Click New Property.
3.4	Select jco.client.client from the list of properties and enter 3-digit number of the SAP logon client you used to configure the steps in the first section of this tutorial (e.g. "001"). Click New property.
3.5	Repeat the previous step for the follow properties: "jco.client.ashost": Name of the Virtual Application Server entered in step 2.13, e.g. "sapa4h". "jco.client.sysnr": The Virtual Instance Number you entered in step 2.13, e.g. "00". Click Save.
3.6	Click Check availability of destination connection to verify that the connection between BTP and and the SAP system on-premise via SAP Cloud Connector works.
3.7	Wait for the confirmation of the successful connection. Click Close.

Create the system user in SAP CIS tenant

To authorize Microsoft Entra for provisioning and de-provisioning users to SAP CIS, a system user must be created in SAP CIS that will be used in the next step in Entra.

Step	Description	Screenshot
4.1	Login to the Administration Console of your SAP CIS tenant at https://<tenant_hostname>.accounts.ondemand.com/admin
4.2	Navigate to Users & Authorizations -> Administrators from the top menu bar. Click "+ Add" and select System from the drop-down list-
4.3	Enter a name for the new Administrator of type System, for example "Entra Tenant <name of your tenant, e.g. bestruncorp". Activate the check-boxes for the following authorizations: Manage Users Read Users Manage Groups Click Save.
4.4	Select Secrets from the configuration settings.
4.5	Click "+ Add".
4.6	Enter a description for the new secret and choose an expiration time. For testing purposes you may choose "Never" from the drop-down list. Click Save.
4.7	Copy & paste the values for Client ID and Client Secret into a notepad. You will need them in the next section. Click OK.

Create groups in Microsoft Entra

Let's move over to the Microsoft Entra Admin Center to create the required groups for the scenario: "SAP User" and "M365 User".

Step	Description	Screenshot
5.1	Login with your Microsoft Entra tenant administrator to the Entra admin center with an additional URL query parameter Microsoft_AAD_Connect_Provisioning_forceSchemaEditorEnabled set to true: https://entra.microsoft.com/?Microsoft_AAD_Connect_Provisioning_forceSchemaEditorEnabled=true. This query parameter enables the Entra administrator to edit and enhance the list of supported Entra attributes for the provisioning configuration of the CIS tenant continued in the admin center in the next section. The additional attribute is required to access the Windows user name and Kerberos realm to construct the SNC mapping in the scenario. Navigate to Identity -> Groups -> Overview. Click New group.
5.2	Enter "SAP User" for the Group name. Click Create.
5.3	Click New group.
5.4	Enter "M365 User" for the Group name. Click Create.

Setup SAP Cloud Identity Services Provisioning in Microsoft Entra

To simplifies the process for setting up automatic user provisioning from Microsoft Entra to the SAP CIS tenant, create an enterprise application from the Microsoft Entra application gallery.

Step	Description	Screenshot
6.1	Navigate to Identity -> Applications -> Enterprise Applications. Click New application.
6.2	From the Microsoft Entra Gallery, enter "SAP Cloud Identity Services" in the search field. Click on the tile with the label "SAP Cloud Identity Services" from the search results.
6.3	Enter a name for the new enterprise application that represents your CIS tenant, e.g. "SAP Cloud Identity Services (<tenant>)", and replace <tenant> with the hostname of your CIS tenant. Click Create.
6.4	Click Add user/group.
6.5	Click None Selected.
6.6	Type "SAP User" in the Search field. From the search results, active the checkbox for the SAP User group. Click Select.
6.7	Click Assign. By assigning the SAP User group to the enterprise application you can scope provisioning to SAP CIS for only those users who are a member in this group.
6.8	Navigate to Manage -> Provisioning.
6.9	Select Manage -> Provisioning and switch to Provisioning Mode "Automatic". Expand the Admin Credentials section and provide the following configuration: Tenant URL: https://<tenant_hostname>.accounts.ondemand.com/ service/scim Admin Password: Client Secret copied in step 4.7 Admin Username: Client ID copied in step 4.7 Click Test Connection.
6.10	Wait for the successful confirmation of the connection test from Entra to CIS. Click Save.
6.11	Expand the Mapping section. Click Provision Microsoft Entra ID Users to edit the pre-configured list of attribute mappings for SAP CIS.
6.12	Activate the checkbox Show advanced options. By accessing the Microsoft Entra Admin Center with the addition URL query parameter in step 5.1, the additional option to edit the attributes for Entra appears in the Supported Attributes section. Click Edit attribute list for Microsoft Entra ID.
6.13	Scroll down to the last row in the table and enter "onPremisesUserPrincipalName" in the attribute name field. Click Save, and confirm the dialog with Yes.
6.14	Click Add New Mapping to provision the user's company name ("BestRun Corp.") to CIS.
6.15	For the Source attribute in Entra, select companyName. For the Target attribute in CIS, select company. Click Ok.
6.16	Click Add New Mapping to provision the user's SAP login name to CIS using custom attribute 1 from the SCIM user schema extension in CIS. Note: The definition of the custom schema extension can be a retrieved from the CIS tenant with the URL https://<tenant_name>.accounts.ondemand.com/scim/Schemas/ urn%3Asap%3Acloud%3Ascim%3Aschemas%3Aextension%3Acustom %3A2.0%3AUser (authentication required with the credentials configure in step 4.7).
6.17	Select "Expression" for Mapping type. The Entra attribute "onPremisesUserPrincipalName" added in step 6.13 has the format "<Windows user name>@<Kerberos realm name>". The SAP login name should be equal to the Windows user name that can be considered unique across all users in the organization. The following expression extracts the Windows user name from the "onPremisesUserPrincipalName" and converts it to upper case for the SAP login name: ToUpper(Item(Split([onPremisesUserPrincipalName], "@"), 1), ) Enter this string for the Expression. As the Target attribute, select "urn:sap:cloud:scim:schemas: extension:custom:2.0:User:attributes:customAttribute1" from the list. Click Ok.
6.18	Click Add New Mapping to provision the user's SNC mapping using custom attribute 2 from the SCIM user schema extension in CIS.
6.19	Select "Expression" for Mapping type. The Entra attribute "onPremisesUserPrincipalName" added in step 6.13 contains the same value as the user's identifier in the Kerberos ticket issued by the DC when the user single signs-on in SAP GUI with SAP Secure Login Client. To map the Windows user to the SAP user in the backed system, the onPremisesUserPrincipalName must be prefixed with the string "p:" using the following expression with the Join function: Join("", "p:CN=", ToUpper([onPremisesUserPrincipalName], )) Enter this string for the Expression. As the Target attribute, select "urn:sap:cloud:scim:schemas: extension:custom:2.0:User:attributes:customAttribute2" from the list. Click Ok.
6.20	Click Save. Confirm the dialog with Yes. Navigate back to Identity -> Applications -> Enterprise Applications.
6.21	Navigate to Manage -> All applications. Enter the SAP CIS enterprise application's name in the search field (e.g. "SAP Cloud Identity Services (<tenant>)"). Select the enterprise application from the list.
6.22	Click Edit provisioning.
6.23	Expand the Settings section. Check that the Scope is set to "Sync only assigned users and groups". Turn the Provisioning Status from Off to On.

Auto-assign users to the scenario groups with access packages

Access packages in Microsoft Entra ID Governance entitlement management can be used to automatically assign users to groups. In this scenario, the assignment to the "SAP User" and "M365 User" groups is based on the user's organizational attributes memberType, companyName and department.

Step	Description	Screenshot
7.1	Navigate to Identity Governance -> Entitlement management. Select Access packages from the submenu. Click New access package.
7.2	Enter "M365" for the Name of the new access package, and provide a description. Click Next: Resource roles.
7.3	Click Groups and Teams.
7.4	Switch to the Groups tab and activate the checkbox for the "M365 User"group. Click Select.
7.5	Select "Member" from the Role drop-down list. Click Next: Requests.
7.6	Select None for the Users who can request access. Set Require approval to No. Set Email Notifications to No. Set Enable new requests to Yes. Click Lifecylce.
7.7	For this test lab setup, select Never for Access package assignment expire. Switch Users can request specific timeline to No. Set Require access reviews to No. Click Review + create.
7.8	Click Create.
7.9	Select Policies from the menu. Activate the checkbox for "Initial Policy". From the context menu ('...'), select Delete.
7.10	Click Add auto-assignment policy.
7.11	Click Edit.
7.12	Enter the following values for the first configuration rule: Property: companyName Operator: Equals Value: BestRun Corp. Click Add expression.
7-13	For the second rule enter the following values: And/Or: And Property: userType Operator: Equals Value: Member Click Save.
7.14	Switch to the Review tab. Click Create.
7.15	Click Identity Governance \| Access packages from the breadcrumb navigation.
7.16	Click New access package.
7.17	Enter "SAP A4H" for the Name of the new access package, and provide a description. Click Next: Resource roles.
7.18	Click Groups and Teams.
7.19	Switch to the Groups tab and activate the checkbox for the "SAP User"group. Click Select.
7.20	Select "Member" from the Role drop-down list. Click Next: Requests. Apply steps 7.6 to 7.11 to the "SAP A4H" access package.
7.21	Enter the following values for the configuration rule of the access package's auto-assignment policy: Property: department Operator: Equals Value: Information Technology Click Save.
7.22	Click Create.

Assign Microsoft 365 licenses to the M365 User group

With group-based licensing, users auto-assigned to the "M365 User" group with the "M365" access package created in the previous section will be assigned to the required Microsoft 365 license to use all AI and productivity apps.

Step	Description	Screenshot
8.1	Sign in to the Microsoft 365 admin center as a License Administrator. Navigate to Billing -> Licenses. Select the Microsoft 365 E5 Developer license. Note: The license name is "Microsoft 365 E5" for a non-developer subscription.
8.2	On the Licenses page, select the Groups tab. Click + Assign Licenses.
8.3	Search for the "M365 User" group and select the group. Click Assign.

Configure provisioning in IPS

To complete the setup of the scenario, provisioning in IPS must be configured to synchronize the users from the CIS tenant's Identity Directory to the SAP system on-premise. The corresponding source and target systems are imported with configuration files from the GitHub repository for this blog post series.

Step	Description	Screenshot
9.1	Login to the Administration Console (https://<tenant>.accounts.ondemand.com/admin) of your CIS tenant. Go to Identity Provisioning -> Source Systems.
9.2	Click Add.
9.3	Click Browse... and open the file LocalDirectory.json from the GitHub repository.
9.4	Upon successful import, click Save.
9.5	Switch to the Jobs tab and click Schedule
9.6	Turn the Job Scheduler to On. Enter a time interval, e.g. 30 minutes for testing purposes. Click Save.
9.7	Go to Identity Provisioning -> Target Systems
9.8	Click Add.
9.9	Click Browse... and open the file SAPA4H_IPS.json from the GitHub repository.
9.10	Upon successful import. click Save.
9.11	Switch to the Transformation tab. Click on the JSON editor.
9.12	The lines marked in yellow show the mappings for SAP login name and SNC name added to the default configuration of a target system of type "SAP Application Server ABAP". The mappings extract the values from the custom SCIM attributes 1 and 2, and pass their values to the corresponding fields in the target system data structure.
9.13	For a better understanding of the targetPath values in the mappings, run transaction SE37 in the ABAP system. Enter "BAPI_USER_CREATE1" in Function Module and click Display.
9.14	Go to More -> Function Module Documentation.
9.15	The documentation for the function module opens in a new window. Click SNC from the Parameters list.
9.16	The data structure and field names for SNC are shown, such as SNC-PNAME that is used in the transformation to map the incoming SCIM user custom attribute 2 to the SAP user's SNC name.
9.17	Note: The following steps 9.17 to 9.19 are optional. If you want to assign the provisioned users to roles in the SAP ABAP system, create an equally named group in the SAP CIS tenant. For the scenario test in the next section, we want to assign the user the SAP role SAP_BC_ABAP_DEVELOPER_5. In the SAP CIS Administration Console, go to Users & Authorizations -> Groups. Click Create.
9.18	Enter "SAP_BC_ABAP_DEVELOPER_5" as the Name and Display Name for the new group. Click Next Step, and again Next Step on the next screen.
9.19	Click Finish.

Testing the scenario

Congratulations! You've completed the scenario setup and are now ready for testing with a new user for Susan Miller. In the course of provisioning Susan's account from AD to the SAP system, all intermediate steps in the Cloud will be inspected and troubleshooting techniques explored.

Step	Description	Screenshot
10.1	On the DC host, launch Windows Administrative Tools -> Active Directory Users and Computer from the Start menu.
10.2	Expand the domain tree and right-click on Users. From the context menu, select New -> User.
10.3	Enter first and last name, for example "Susan Miller". As the User logon name, choose a unique value, for example "smiller". Click Next.
10.4	Enter a password. For testing purposes, disable to option that the user must change the password at next login. Click Next.
10.5	Click Finish.
10.6	The user has not yet configured any organizational properties which are required for the auto-assignment to the groups in Entra. Right-click on the new user object and select Properties from the context menu.
10.7	Switch to the Organization tab. Enter "Information Technology" in Department. Enter "BestRun Corp." in Company. Click OK.
10.8	Go back to the Microsoft Entra admin center. Go to Identity -> Hybrid management -> Microsoft Entra Connect. Select Cloud Sync from the navigation menu.
10.9	Check that the configuration status for your on-premise domain is healthy. Select Provisioning logs.
10.10	From the logs you can see two entries for the new user Susan Miller: The first one (Action Create) when the user was created, the second one (Action Update) when the organizational attributes were changed.
10.11	Verify that the new user has been assigned to the groups in Entra via the auto-assignment policies of the access packages. Navigate to Identity Governance -> Entitlement Management -> Access packages. Select the "M365" access package from the list.
10.12	Go to Assignments and check if the new user is listed. Note: It can take several minutes until the evaluation of the auto-assignment criteria are reflected in the access package assignments.
10.13	Repeat the previous step for the "SAP A4H" access package and wait until the assignment for the new user is delivered.
10.14	Navigate to Identity -> Applications -> Enterprise Applications. Select the enterprise application for your SAP CIS tenant from the list. From the menu go to Provisioning -> Provisioning Logs. In the search bar, enter the new user's name, for example "Susan". Check the log entries. The first one in the list shows a provisioning status "Skipped", and second has status "Success". Click on the first entry with status "Skipped".
10.15	From the description you can see that the user object was not (yet) assigned to the application. Based on the scope settings (see steps 6.4 and 6.23), only members of group "SAP User" are provisioned to SAP CIS. Since the user hasn't been auto-assigned to the group based on the missing department value at this time, the provisioning was skipped. On the next provisioning interval 40 minutes later, the auto-assignment occurred, and the user was now in scope for provisioning to CIS.
10.16	Move over to the SAP CIS administration console. Go to Users & Authorizations -> User Management. Search for the new user, e.g. by login name ("smiller").
10.17	Check if the user has already been provisioned to the SAP system. Go to Identity Provisioning -> Provisioning Logs.
10.18	Check the Job Logs for the most recent entry of the Source System "LocalDirectory". Click on the log entry.
10.19	From the Statistics section, check that an Entity of type user has been created in (target) system SAPA4H.
10.20	Note: The following steps 10.20 to 10.23 are optional. If you want to test role provisioning for the SAP user, go to Users & Authorizations, select the SAP_BC_ABAP_DEVELOPER_5 group. In User Members, click Add.
10.21	Search for the new user (e.g. "Susan Miller") and click Add.
10.22	Go back to Identity Provisioning -> Source Systems, and select the LocalDirectory. Switch to the Jobs tab. To trigger an immediate provisioning of the new group membership, click Run Now for the Read Job.
10.23	Go to Identity Provisioning -> Provisioning Logs. Check for the most recent entry that for Entity group a new entry has been updated in (target) system SAPA4H.
10.24	Login to the SAP system as the administrator (e.g. user DEVELOPER if you are using the ABAP Developer trial Docker image). Run transaction SU01. Enter "SMILLER" in the User field and click Display.
10.25	Check if the Address fields are set correctly. Switch to the SNC tab.
10.26	Verify that the user's SNC name is correctly mapped according to the expression used in step 6.19 to create the string, and the transformation used in step 9.12 to set the value.
10.27	Optionally switch to the Roles tab if you ran steps 10.20 to 10.23 before and check if the role SAP_BC_ABAP_DEVELOPER_5 has been assigned successfully.
10.28	Login as the new user to AD from the domain-joined workstation.
10.29	Launch the SAP GUI and create a new connection to the SAP system.
10.30	For the Secure Network Settings, make sure to click the checkbox "Activate Secure Network Communication", and enter the correct SNC Name for your SAP system. If you are using the ABAP Developer trial Docker image, the value is "p:CN=A4H, OU=IDEMOSYSTEM, OU=SAP Web AS, O=SAP Trust Community, C=DE".
10.31	Double-click on the new entry.
10.32	Because this is the first login for the new user you are prompted to either reset the initial password, or deactivate it. Click on Delete to use SNC and Kerberos-based SSO.
10.33	You are single signed-on to the SAP system using SNC and Kerberos SSO.
10.34	Finally, also verify if the Microsoft 365 license has been successfully assigned to the new user. Open a browser and go to https://www.office.com.
10.35	Sign-in as the new user to the Entra ID tenant.
10.36	Click on Apps to see all office applications assigned to the user.

Wow! This was a longer journey through an extensive user provisioning scenario across SAP's and Microsoft's on-premise and cloud platforms! Hope you enjoyed it and worth spending your time. Let me know your thoughts and any open questions in the comments.

Fetching Security Materials in SAP CPI and Sending it as a PGP Encrypted CSV file via Email

2025-02-11T14:48:20.908000+01:00

Introduction:

Managing credentials effectively is crucial in any integration landscape. SAP CPI provides Security Material to store authentication details such as UserCredentials, OAuth2ClientCredentials and SecureParameters. Manually handling these credentials can be risky and inefficient.

In this blog, we will see how to automate credentials retrieval, encrypt the data with PGP and securely send it via email, ensuring compliance and data protection. Additionally we will also see how to decrypt file and view the original data.

Why is this use case Important?

Secure Credential Management - Automates fetching credentials from SAP CPI Security Material.
Data Protection - Ensures credentials are encrypted with PGP before sharing and logging.
Compliance & Security - Prevents exposure of sensitive information in plain text or CSV and avoids the risk of storing credentials on local drives.

Prerequisites:

Some credentials should be maintained in SAP CPI Security Material. i.e UserCredentials, OAuth2ClientCredentials, SecureParameters.
PGP Public key must be uploaded in Security Material for encryption. please refer Blog for generation PGP keys using Kelopatra Tool.
Corresponding PGP Private key should be available externally for decryption.
SMTP Configuration for sending email. please refer Blog for SMTP Gmail setup.
CPI OAuth credentials should be configured to fetch the Security Material details from API.

Integration Flow Overview:

To automate secure credential retrieval and transfer, this iflow performs the following key actions:

1. Fetch credentials name from SAP CPI Security material using HTTP.

2. Fetch password, client secret, secure parameter from the Secure Storage and format it as XML payload using groovy script.

3. Convert XML to CSV for easy readability.

4. Encrypt the CSV data using PGP and Log encrypted payload if required.

5. Send the encrypted payload as attachment via mail.

Download Integration flow from the Git : link

Download the Security Material Export with PGP Encryption.zip from the Git.
Upload it in CPI
Go to configure and update below parameters.

Receiver CPI:

Authentication	Basic / OAuth2 Client Credentials
Credential Name	Name defined in the Security Material for CPI

Receiver Mail:

Credential Name	Name defined in the Security Material for Mail
From	From Mail ID
To	To Mail ID
CC	Optional

More All Parameters:

Log File as Attachment	set value as 'true', if you want to log the encrypted payload as attachment in the monitoring logs
PGP Public Key	User ID of public key configured in Monitor > PGP Keys section
Tenant URL	URL of CPI tenant by removing https:// <--->.com, refer below screenshot.

Click on save and Deploy the iFlow.

Result:

Go to Monitor Message Processing and check the Attachments (CredentialDetails) created.

PGP Encrypted data

Check you mail inbox:

Attached file contains encrypted data.

Decrypt the file data using Online tool.

(you use can any PGP tool to decrypt)

Encrypted text in the file
Generated PGP Secret key
Passphrase used while creating PGP key
Decrypted CSV text - we can see header column

Conclusion:

This blog covered how to securely fetch credentials from CPI Security material, encrypt them using PGP and send them via email. This approach enhances security and ensures compliance.

Let me know your thoughts or if you have any questions drop a comment below!

Happy Integrating!

Securing Business Partner (BP) Master Data in SAP S/4HANA: A Guide to Field-Level Authorization

2025-02-18T16:00:44.799000+01:00

Problem Statement

When we have MDG implemented for supplier and customer. All the master data changes for supplier and customer must go through the MDG workflow process and data must not be editable in S/4 system directly, however, there are a few exceptions where specific fields must be managed directly in S4. Due to this we must build our S4 role in such a way that all the MDG managed data / fields must be restricted only to display and only S4 managed fields should be editable.

Implementing The Solution:

Usually in S4 all the business partner data is managed through either transaction BP or the Fiori app F3163 - Manage Business Partner Master Data. The solution we are going to discuss here only works with transaction code BP but not with Fiori apps.

Preparing a requirement matrix:

We should start with identifying which fields / data is MDG managed vs S4 managed. To get this, we should work with the master data team. They can help us with identifying the field level requirements like below with reference to master data dictionary.

Technical Filed Name	Business Name	MDG/S4
KNA1.NAME4	Attention (aka Name 4)	S4
KNBK.BANKL	Bank Number	S4
ADRC.STREET	Address Line 1	MDG
KNA1.KDKG1	Customer condition group 1 (Line discount)	S4
KNA1.KDKG2	Customer condition group 2 (Multi line discount)	S4
KNBK.BANKN	Bank Account Number	MDG
KNBK.BANKS	Bank Country Key	MDG

Preparing role matrix:

Now we should prepare a role matrix in line with identified S4 managed fields / data

Technical Filed Name	Business Name	Role1	Role2
KNA1.NAME4	Attention (aka Name 4)	X
KNBK.BANKL	Bank Number	X
KNA1.KDKG1	Customer condition group 1 (Line discount)		X
KNA1.KDKG2	Customer condition group 2 (Multi line discount)		X

Identifying the field group ID:

Next step is to Identify the field group IDs, which will be used in authorization object (B_BUPA_FDG) to restrict the access to fields.

Steps:

Go to SE16 transaction
Enter table name “TBZ3R” and execute
Filter out using technical filed name

Marking fields as authorization relevant:

In system not all BP fields are authorizations relevant by default. Hence, first we must make all identified fields (Both MDG and S4 managed fields) as authorization relevant.

Steps:

Go to BUCN transaction
Click on “New Entries”
Enter the field group IDs identified in earlier
Click on save
Once you click on save system to prompt to create a transport to capture these changes. We need

to move this transport (along with the role changes) across the landscape to reflect the changes

Adjusting Role Authorizations:

The first line of security when working with transaction code BP is at BP role type using B_BUPA_RLT authorization object (example: Customer, Supplier etc.). Then comes the field level security restrictions using authorization object B_BUPA_FDG. This is where you will enter the field groups which should be editable for this role.

Conclusion:

All these configurations and restrictions only work with transaction code BP but not with the Fiori Apps. Hence, only assign transaction code BP to the role and adjust the B_BUPA_RLT object as needed to provide access to required BP role type (example: Customer, Supplier). Then using authorization object B_BUPA_FDG we can restrict the role with display/change access to required fields. We must restrict all the MDG managed fields in S4 roles to display access only otherwise, the role gives access to fields which would bypass any MDG workflows.

Security SAP HANA SAP Master Data Governance SAP S/4HANA business partner

Prepare list of all authorization object changes in roles during conversion

2025-02-26T17:07:41.512000+01:00

As a security consultant you have the task of role remediation. You might want to know what all changes to expect in roles during the role remediation process. You can prepare a report for all the changes following the below steps.

Ensure you have run STEP 2A and 2B before moving to the below steps:

1. Execute tcode SU25 and click on STEP 2C:

2. You will find the list of roles which are affected due to conversion and needs to be remediated:

3. You can select all roles or few roles based on requirement, and click on simulate button to get the list of changes you will see in roles post the merge process in PFCG:

4. Here in column "Value Comparision" you will find different status:

5. This field entries will help you to identify the different changes you can expect in role during role remediation. If your face issues while downloading this list, due to its size, apply below filters and then try to download in three different reports:

Hope this helps !!

T4S hace historia en España con la certificación "SAP Certified in SAP Security Operations"

2025-03-11T16:12:23.583000+01:00

SAP ha tenido la oportunidad de entrevistar a Luisma Fuente Canalda, director SAP Basis en T4S - Technology for SAP. T4S se ha consolidado en pocos años como un referente en tecnología y consultoría SAP. Con más de 220 expertos y numerosas certificaciones, la empresa ofrece un soporte integral a compañías de todo el mundo. En esta entrevista, hablaremos sobre la importancia de las certificaciones SAP, las últimas tendencias en seguridad y migración a la nube, y el papel estratégico de SAP BTP. Además, exploraremos por qué la ciberseguridad no es solo un tema técnico para T4S, sino un factor clave para el éxito. Una mirada fascinante al futuro de la tecnología SAP y a los desafíos de la transformación digital.

¿Podría comenzar contándonos sobre su empresa y los servicios que ofrece?

T4S –Technology for SAP – es la marca especializada en Tecnología y Consultoría SAP del grupo VASS. En solo tres años y medio, nos hemos convertido en un referente en el sector gracias a un equipo de expertos con más de 20 años de experiencia dedicados exclusivamente a la tecnología SAP.

Desde nuestra creación en 2021, hemos crecido de manera exponencial. Hoy somos más de 220 profesionales con más de 260 certificaciones SAP vigentes, lo que nos permite ofrecer cobertura integral en casi todas las soluciones de SAP. Contamos con presencia en cuatro continentes y trabajamos con 150 clientes activos en sectores muy diversos.

Nuestro conocimiento abarca desde la parte técnica, con especialización en SAP Basis, SAP BTP, SAP Integration, SAP AI Foundation y SAP Analytics, hasta la experiencia funcional en la mayoría de las soluciones de SAP.

Nuestra propuesta de valor se basa en la excelencia técnica y la capacidad de acompañar a nuestros clientes en todo el ciclo de vida de sus soluciones SAP. No solo asesoramos, sino que también ejecutamos y mantenemos sus sistemas, ayudándolos en procesos clave como la conversión a SAP S/4HANA Cloud Private Edition, las implementaciones de RISE with SAP y GROW with SAP, la gestión del dato o la adopción de escenarios avanzados de inteligencia artificial generativa.

Todo ello, siempre con un enfoque alineado con Fit to Standard y SAP Clean Core Approach.

En T4S, combinamos innovación, experiencia y visión estratégica para garantizar que cada cliente aproveche al máximo el ecosistema SAP, impulsando su transformación digital con las mejores prácticas y las últimas tendencias tecnológicas.

¿Por qué decidió en 2022 certificar sus servicios como socio de operaciones de SAP?

Para nosotros, certificar nuestros servicios con SAP no es solo un reconocimiento, sino una garantía de calidad para nuestros clientes. Estas certificaciones validan nuestra capacidad para operar con los más altos estándares y consolidan nuestra posición como expertos en tecnología SAP.

Desde el inicio, tuvimos claro que queríamos diferenciarnos por la excelencia. Las certificaciones SAP Certified in SAP HANA Operations and works with RISE with SAP, SAP Certified in SAP BTP Operations and works with RISE with SAP y la más reciente SAP Certified in SAP Security Operations son el reflejo de nuestro compromiso con la innovación y la mejora continua. Más allá de demostrarlo con resultados en cada proyecto, estas acreditaciones certifican, de forma objetiva y rigurosa, que nuestro enfoque, metodología y capacidades han sido validadas por SAP tras un exhaustivo proceso de evaluación.

En un mercado donde la confianza y la especialización son claves, contar con certificaciones SAP Operations refuerza nuestra propuesta de valor y nos distingue claramente de otras consultoras. Nuestros clientes saben que trabajan con un socio que no solo domina la tecnología, sino que también ha sido reconocido por SAP como un referente en la gestión, operación y seguridad de sus entornos.

Usted acaba de recibir por primera vez la certificación SAP Certified in SAP Security Operations. ¿Qué importancia tiene este tema para T4S y sus clientes?

Para T4S, la seguridad no es solo un requisito, sino un pilar fundamental en la gestión de entornos SAP. La obtención de la certificación SAP Certified in SAP Security Operations refuerza nuestro compromiso con la protección de los datos y sistemas de nuestros clientes, garantizando que operamos con los más altos estándares en seguridad.

Esta certificación no está aislada, sino que complementa nuestras acreditaciones en SAP HANA Operations and works with RISE with SAP y SAP BTP Operations and works with RISE with SAP, consolidando nuestra propuesta de valor como un socio integral que ofrece calidad, garantía y fiabilidad en cada uno de sus servicios.

Vivimos en un mundo donde los “malos” siempre están ideando nuevas técnicas de ataque, y la ciberseguridad no puede ser un tema secundario. Las amenazas evolucionan constantemente, y con ellas, también deben evolucionar las estrategias de protección. Gracias a esta certificación, nuestros clientes pueden confiar en que sus sistemas SAP estarán protegidos con las mejores prácticas y tecnologías disponibles, mitigando riesgos y garantizando la continuidad del negocio.

Además, esta certificación nos posiciona aún más fuerte en el mercado, diferenciándonos como un partner estratégico que no solo domina la tecnología SAP, sino que también está a la vanguardia en soluciones de seguridad. No se trata solo de conocer SAP, sino de garantizar que los sistemas de nuestros clientes sean seguros, resilientes y preparados para el futuro.

¿Qué servicios específicos ofrecen en las áreas de seguridad y migración a la nube?

En T4S, ofrecemos un enfoque integral en seguridad SAP, abarcando desde auditorías iniciales para evaluar el estado de los sistemas hasta la implementación de soluciones avanzadas que refuercen la protección y el control de accesos. Ayudamos a nuestros clientes con la implantación de SAP GRC para el gobierno y cumplimiento normativo, configuramos Single Sign-On (SSO) con SAML para entornos web, SAP SSO y SAP Secure Login Service for SAPGUI, e integramos soluciones open-source para autenticación en clientes pesados con IdP y MFA. También desplegamos capacidades Security Information and Event Management (SIEM) con SAP Enterprise Threat Detection (SAP ETD) para monitorizar amenazas, revisamos y reestructuramos roles de usuario asegurando una gestión óptima de accesos, y automatizamos el aprovisionamiento de usuarios desde Azure AD hacia los sistemas SAP, permitiendo una gestión centralizada de parámetros y roles directamente en Azure AD.

En el ámbito de la migración a la nube, acompañamos a las empresas en su transición a RISE with SAP, asegurando un enfoque basado en SAP Clean Core Approach y Fit to Standard a la vez que damos garantías de trabajar con entornos mediante la tecnología más avanzada recomendada por SAP como fabricante.

En T4S, nos gustan los retos. Queremos que nuestros clientes nos compartan sus inquietudes y problemas —lo que los angloparlantes llaman pains— para encontrar soluciones estables, seguras y adaptadas a sus necesidades reales. La seguridad y la migración no deben ser barreras, sino oportunidades para impulsar su transformación digital con total tranquilidad.

¿Qué beneficios espera obtener de la certificación SAP Certified in SAP Security Operations en operaciones de seguridad?

Ser la primera empresa de consultoría SAP en España en obtener la certificación SAP Certified in SAP Security Operations es un reconocimiento clave que refuerza nuestra posición como expertos en seguridad SAP. No solo nos permite demostrar de manera tangible nuestras capacidades en este ámbito, sino que también valida, a través de SAP, que nuestras metodologías, procesos y soluciones cumplen con los estándares más exigentes del mercado.

En un entorno empresarial cada vez más complejo, la seguridad es un elemento estratégico. Esta certificación nos permite ofrecer a nuestros clientes una garantía de que sus sistemas y datos están protegidos con las mejores prácticas y tecnologías disponibles. No se trata solo de mitigar riesgos, sino de asegurar la continuidad operativa y fortalecer la confianza en cada solución que implementamos.

Recientemente también ha sido recertificado en SAP HANA Operations and works with RISE with SAP y en SAP BTP Operations and works with RISE with SAP. ¿Qué experiencias ha tenido en los últimos años en el entorno de SAP BTP y qué papel han desempeñado la certificación y la auditoría en este proceso?

Nuestra experiencia con SAP Business Technology Platform (SAP BTP) en los últimos años ha sido clave en la evolución de nuestros clientes hacia arquitecturas más ágiles, escalables e inteligentes. SAP BTP es un pilar estratégico dentro de RISE with SAP, permitiendo la integración de servicios avanzados de automatización, analítica en tiempo real, inteligencia artificial y conectividad multi-cloud.

Desde T4S, hemos acompañado a empresas de diversos sectores en la adopción y optimización de SAP BTP, ayudándolas a construir ecosistemas más flexibles sin comprometer el enfoque Clean Core Approach. Hemos trabajado en escenarios de extensibilidad, desarrollos cloud-native, integración con sistemas heterogéneos y despliegues híbridos, asegurando que cada solución esté alineada con las mejores prácticas de SAP.

Estas certificaciones han sido fundamentales para validar nuestra metodología de trabajo y garantizar que operamos con los más altos estándares. No solo nos han permitido reforzar nuestras capacidades técnicas y operativas, sino que también han consolidado nuestra posición como un socio estratégico para aquellas empresas que buscan maximizar el valor de su inversión en SAP.

La información sobre el programa de certificación para socios operativos y una visión general de todos los socios certificados se puede encontrar en SAP Operations Partner Guide.

SAP Ariba User Provisioning Using SAP Identity Provisioning Service (IPS)

2025-03-17T21:49:57.056000+01:00

This blog post explains how to provision users to SAP Ariba using the SAP Cloud Identity Services—Identity Provisioning Service (IPS). Typically, you can create and provision new users to SAP Ariba through various methods such as:

Self-registration
CSV file upload
Provisioning via IPS from existing user stores (e.g., Microsoft AD, AS ABAP, SAP SuccessFactors)

More information about Integrating SAP Ariba with SAP Cloud Identity Services can be found on SAP Help. While there are multiple options, this post focuses on using SAP Identity Provisioning to provision users from SAP Cloud Identity Service (Identity Authentication).

Note: For guidance on integrating Cloud Identity Services with SAP Ariba (for Single Sign-On and identity federation), see the blog post here:
Identity Federation & SAP Ariba SSO with SAP Cloud Identity Services

Use-Case Scenario

Integrating Cloud Identity Services with SAP Ariba is just one example of how enterprises can unify identity management across various SAP solutions (e.g., SAP SuccessFactors, SAP Business Network, SAP Category Management, SAP Fieldglass). Centralizing identities in SAP Cloud Identity Service is an essential part of an enterprise-wide identity strategy. It also aligns with future SAP initiatives such as SAP Task Center and Joule, which rely on users being managed in Cloud Identity Service.

Identity Authentication and Identity Provisioning play a critical role in integrating SAP Ariba and other SAP BTP applications. They enable the use of a Global User ID—an attribute that uniquely identifies a user across the system landscape—serving as a prerequisite for adopting tools like SAP Task Center.

Architecture Overview

The architecture diagram for this scenario primarily highlights how to provision identities to SAP Ariba via Identity Provisioning. Similar concepts can also apply to other SAP Ariba SaaS solutions such as SAP Business Network, SAP Category Management, and SAP Fieldglass.

In this blog, we will cover:

Creating Ariba users in SAP Cloud Identity Service using both ODM and a custom Ariba schema.
Setting up SAP Ariba as the target system and Identity Authentication as the source system.
Configuring the IPS transformation file to map Identity Authentication user attributes to SAP Ariba user attributes.
Configuring IPS jobs to provision users to SAP Ariba.
Planning the migration from the custom Ariba Cloud Identity Service schema to the standard SAP Ariba schema (once released).

Create Ariba Users in SAP Cloud Identity Service Using ODM and a Custom Ariba Schema

Beyond the standard/core user attributes in SAP Cloud Identity Service, SAP Ariba requires additional attributes (such as purchasing unit, purchasing organization, plant, etc.). To handle these, two extension schemas come into play:

ODM Schema: urn:ietf:params:scim:schemas:extension:sap.odm:2.0:User
SAP Ariba Schema: urn:ietf:params:scim:schemas:extension:sap:ariba:2.0:User

SAP Cloud Identity Service has recently released Open Domain Model (ODM) schema support, enabling additional business attributes (e.g., companyCode, purchasingOrganization) in the Cloud Identity Service user profile. The ODM schema and attributes can be found under Users & Authentication → Schemas in your Cloud Identity Service.

Note: As of this writing, the SAP Ariba Schema (urn:ietf:params:scim:schemas:extension:sap:ariba:2.0:User) is planned for release in Q2 2025 (subject to change based on the SAP Cloud Identity Service product roadmap). In the interim, a custom schema must be created, which you will later migrate to the standard SAP Ariba schema once it becomes available.

Steps to Create a Custom SAP Ariba Schema

You can create the custom schema either via Postman or directly in the Cloud Identity Service interface. Below are the steps for creating it through the Cloud Identity Service UI:

Navigate to Schemas

In the Cloud Identity Service console, go to Users & Authorizations → Schemas.

Create New Schema

Click Create or Add, and enter a name for your custom schema.

Important: The custom schema name (urn:ietf:params:scim:schemas:extension:vendor:ariba:2.0:User) must be different from the future standard schema name (urn:ietf:params:scim:schemas:extension:sap:ariba:2.0:User) to avoid conflicts once the standard schema is released.

Define Schema Attributes
- Add the additional attributes (e.g., currency, deliverTo, passwordAdapter, addresses).

Create an Ariba User Using ODM and the Custom Ariba Schema in Cloud Identity Service

Create a System User

In the Cloud Identity Service console, go to Users & Authorizations → Administrators → Add System.
Generate the Client ID and Client Secret, ensuring you have Manage Users permissions.

2. Prepare a User Payload in Postman

Use a sample JSON payload that includes ODM attributes and the custom Ariba attributes.
Ensure any attributes values you include must match valid SAP Ariba fields values so that the data correctly populates in SAP Ariba

3. Verify User Creation

After sending the request to create a user, check the Cloud Identity Service to confirm the new user.
The Extensions tab in the user record should display both ODM and custom Ariba attributes.

4. Assign the User to a Group

In Cloud Identity Service, assign the user to any necessary group(s) (for ex: ARIBA-USERS group) to manage their access permissions.

This completes the initial step of creating an Ariba user in Cloud Identity Service with both ODM and custom Ariba schema attributes.

Set Up Identity Authentication as the Source System and SAP Ariba as the Target System in IPS

Identity Authentication as the Source System

Navigate to Identity Provisioning in your Cloud Identity Service console.
Create a Source System and select Identity Authentication as the source type.
Modify default transformation file to map ODM and custom Ariba schema attributes.
- Download sample source transformation file from Github .
- Note that the schema references in the transformation file should point to the ODM attributes and your custom Ariba schema attributes.
- In the Source System Properties, you can set filters like ias.group.filter or ias.user.filter so that only specific users (e.g., aribacisuser1) are provisioned.

SAP Ariba as the Target System

In Identity Provisioning, navigate to Target Systems and create a new system of type SAP Ariba Application.
SAP Ariba user management is performed via SCIM APIs. Follow the SAP Help documentation to request access to the SAP Ariba SCIM API, after which you will receive OAuth client credentials.
Download and adjust the Target System Transformation File

Map your custom Ariba schema attributes to the standard SAP Ariba attributes.
For instance, ODM schema attributes can map to Accounting attributes in Ariba, while custom schema attributes might map to Shipping and Billing details.

Configure IPS Jobs to Provision Users to SAP Ariba

Once your source and target systems are set up:

Run the Provisioning Job in IPS.
The user you filtered (e.g., aribacisuser1) should be created in the SAP Ariba target system.
In the Ariba system, navigate to Manage → Core Administration → User Manager. Search for the user.
Additional business attributes (such as purchasing org, cost centers) appear under Other User Info in Ariba.

Note: As mentioned, ODM schema attributes are mapped to Accounting attributes, and custom schema (SAP:Ariba) attributes are mapped to Shipping and Billing attributes.

Custom Ariba Cloud Identity Service Schema Migration Plan

As of this writing, the standard SAP Ariba schema (urn:ietf:params:scim:schemas:extension:sap:ariba:2.0:User) is not yet available. Once SAP releases it (currently planned for Q2 2025(subject to change based on the SAP Cloud Identity Service product roadmap)), follow these steps to migrate from your custom schema:

Update Existing Users

Perform an Update operation on all Ariba users in Cloud Identity Service, replacing the custom schema (urn:ietf:params:scim:schemas:extension:vendor:ariba:2.0:User) with the standard schema (urn:ietf:params:scim:schemas:extension:sap:ariba:2.0:User).

Populate Attributes

Confirm that attributes are correctly mapped and populated in the new standard schema.

Adjust Source and Target Transformation Files

Replace all references to the custom schema with the standard Ariba schema.

Run IPS Jobs

Execute your IPS provisioning jobs again to ensure the updated schema references are correct and that data syncs as expected.

Conclusion

By following the steps outlined in this blog, you can successfully create and manage SAP Ariba users through SAP Cloud Identity Service, leveraging both the ODM schema and a custom Ariba schema (until the standard one is released). Identity Provisioning Service streamlines the process, allowing you to filter and transform user data from Identity Authentication into SAP Ariba. Once SAP releases the standard SAP Ariba schema, you can seamlessly migrate your custom Ariba schema, further simplifying your identity landscape and supporting broader initiatives like SAP Task Center and Joule.

Using CDS and Fiori Elements to see derived roles

2025-03-17T22:48:04.588000+01:00

Trying to follow which transaction codes are used by a specific PFCG role is quite easy to find with SUIM, but navigating from derived roles to imparting roles is not as straight forward.

I decided to generate some CDS views and a Fiori Elements app to rectify this.

The source can be imported from https://github.com/michaelnicholls/ZTCD_ROLES.git

Once the correct service bindings are activated and published, the BSP app can then be used to find roles via transaction code to show any imparting and/or derived roles that have a specified set of transaction codes.

Please see the following example.

I have assumed that only single TCD values are used in the authorization values.

Exciting Opportunity for SAP Partners: Join the SAP Customer Engagement Initiative - Cycle 1, 2025

2025-03-20T13:51:32.601000+01:00

Dear SAP Partners,

We're thrilled to announce that the first cycle of the SAP Customer Engagement Initiative for 2025 is still open for your registrations! This is a unique opportunity for you to collaborate with SAP and help shape the future of our products. This is your chance to make a real impact and contribute valuable insights to the development of SAP's upcoming products, features, and applications. Don't miss out – register by March 28, 2025, to join the current projects open to SAP partners. We look forward to hearing your perspectives and ideas on the following initiatives:

ABAP

SAP Business Technology Platform

SAP Customer Experience

SAP CX AI Toolkit

Data & Analytics

SAP S/4HANA Cloud

SAP Globalization

Lifecycle Management

DevOps with ABAP

Others

We believe collaboration is at the heart of innovation. By working together with our customers and partners, we can reshape the future of SAP products and transform the way businesses operate.

Don't wait – register today on influence.sap.com and join the SAP Customer Engagement Initiative Cycle 1 in 2025!

Warm regards,

Your SAP Customer Engagement Initiative Team

Follow-up after registration: When you register for a project, you will be invited to an introductory call with the SAP project lead. At this point further participation is optional. Typically, all activities are governed by the Feedback Agreement with SAP.

Striking a Balance: Navigating the Open-Source Tightrope in a World of Evolving Threats - Part 2

2025-04-02T16:27:55.153000+02:00

By Philip Engelmartin, Technical Advisor, Office of the CSO

Navigating the Complex Landscape of OSS Licensing and Geopolitical Influences

In the second part of our series, we delve into the intricate landscape of open-source software (OSS) licensing and the geopolitical influences that can impact the software supply chain. Understanding these factors is crucial for developing a strong strategy to manage the risks associated with OSS in a world of evolving threats.

The Shifting Sands of OSS Licensing

The license landscape for OSS is complex and ever evolving. While OSS licenses often allow free use and modification, they usually come with specific conditions and stipulations that can significantly affect software development and business models:

License Incompatibility and Legal Risks

Integrating OSS components with incompatible licenses can lead to legal challenges and hinder the ability to commercialize software. Incompatible licenses might impose conflicting conditions on the use, distribution, and modification of the code, prompting costly re-engineering efforts or forcing organizations to abandon the OSS component entirely. This complexity requires organizations to have a deep understanding of the various licenses and their implications, which can be a daunting task given the wide range of licenses in use.

Shifting License Terms

OSS licenses are not immutable. Projects can change their licenses, as seen with Redis Labs’ shift to a source-available license [1]. Such changes necessitate significant re-engineering efforts to comply with the new terms and force organizations to evaluate alternative solutions diligently, balancing legal requirements, technical feasibility, and strategic alignment. Organizations must be prepared to adapt quickly to these changes, which can disrupt project timelines and resource allocation.

Patent and Copyright Infringement

OSS licenses do not offer absolute protection against patent or copyright infringement claims. Accidentally using code that infringes on existing intellectual property rights can lead to expensive legal disputes, tarnishing the organization's reputation and jeopardizing financial stability. Organizations must conduct thorough due diligence to ensure that they are not inadvertently infringing on any patents or copyrights, which can be a complex and resource-intensive process.

Geopolitical Influences and Supply Chain Security

The globalized nature of software development fosters collaboration but also introduces geopolitical risks, especially as nations increasingly leverage technology for strategic advantage:

Supply Chain Interference

Geopolitical tensions can disrupt software supply chains, causing delays in development, access restrictions, or potentially enabling malicious code injection by state-sponsored actors [2]. These interferences can undermine trust in the software supply chain, jeopardizing global operations and critical infrastructure. Organizations must be prepared to navigate these geopolitical challenges, which can require significant investment in security measures and contingency planning.

Export Control Regulations

OSS components subject to export control regulations can limit the ability to distribute software in specific countries. Compliance with these regulations necessitates meticulous planning, continuous monitoring, and frequent updates, significantly impacting the organization’s global reach and market strategy. Organizations must maintain a clear understanding of these regulations and ensure that they are adhering to them to avoid potential legal issues and market restrictions.

Data Sovereignty and Privacy Concerns

The use of OSS components developed in countries with differing data privacy regulations can raise concerns about data security and compliance with regulations like the GDPR. Ensuring compliance while using foreign-developed OSS demands thorough assessments, stringent data protection measures, and comprehensive coverage of legal obligations. Organizations must invest in ensuring that they comply with all relevant data privacy regulations, which can be a complex and ongoing process.

A Malicious Backdoor in the Linux xz Utility

In February 2024, a backdoor was inserted into specific versions of the Linux xz utility (liblzma library 5.6.0 and 5.6.1) by a user named "Jia Tan," presumably a nation-state actor [3]. The backdoor granted attackers remote code execution capabilities, exposing critical security risks. This incident underscores the importance of rigorous security audits and vigilant monitoring of all software components. It highlights the need for organizations to implement robust security measures to protect against such threats, which can have widespread and severe consequences.

Quantifying the Hidden Costs

While OSS has the allure of initial cost savings, a thorough cost analysis reveals significant hidden expenses that can erode these perceived benefits:

Security Remediation and Breach Mitigation

Addressing security vulnerabilities in OSS components can require substantial resources. In the case of a data breach, the costs associated with incident response, legal fees, regulatory fines, and reputational damage can be staggering, emphasizing the need for robust security measures. Organizations must invest in proactive security measures to minimize the risk of breaches and ensure that they are prepared to respond effectively if one occurs.

Crypto Agility

The lack of crypto agility can exacerbate these costs, as upgrading or replacing cryptographic components often demands significant re-engineering and testing efforts. The ability to quickly adapt to new cryptographic standards is crucial in maintaining data security and compliance. Organizations must invest in ensuring that their systems are designed to be crypto-agile, which can require considerable technical expertise and ongoing maintenance.

Maintenance Overheads and Technical Debt

Integrating and maintaining OSS components can introduce technical debt. Managing this debt requires ongoing maintenance efforts, diverting resources from core software development and potentially extending project timelines and budgets. Organizations must be prepared to invest in managing this technical debt to ensure that their software remains secure and reliable over time.

Legal and Compliance Costs

Tackling licensing issues, ensuring compliance with export controls, and mitigating legal risks can incur considerable legal and administrative costs. These activities demand specialized expertise and constant vigilance to navigate the dynamic regulatory landscape effectively. Organizations must invest in legal and compliance resources to ensure that they are adhering to all relevant regulations and minimizing their legal risks.

Conclusion

The complexities of OSS licensing and geopolitical influences add another layer of risk to the use of OSS in software development. Organizations must carefully navigate these challenges to ensure compliance, security, and the long-term sustainability of their software. This requires a nuanced approach that balances the need for innovation with the necessity of robust security measures and adherence to legal and regulatory requirements.

In the final part of our series, we will explore the benefits of transitioning to an inner source development model as a solution to mitigate these risks while fostering innovation within a controlled environment.

[1] https://bitsea.de/en/blog/2022/02/open-source-aerger-wegen-ploetzlicher-lizenzaenderungen/
[2] https://krebsonsecurity.com/2022/03/pro-ukraine-protestware-pushes-antiwar-ads-geo-targeted-malware/
[3] https://openssf.org/blog/2024/03/30/xz-backdoor-cve-2024-3094/

How DevSecOps as a Service Transforms Agile Testing Workflows

2025-04-03T15:52:49.956000+02:00

Have you ever considered how Agile frameworks can meet the increasing demands for speed and efficiency while simultaneously needing to fortify the security of their software development processes? In an age where digital threats emerge, adapt, and proliferate at breakneck speed, secure coding is no longer a preference, but a requirement. While many Agile frameworks put speed and flexibility at the forefront of their values, they struggle to find ways to facilitate a comprehensive security strategy. That is where DevSecOps as a Service fits in to reshape how security is embedded in the development process.

DevSecOps as a Service integrates security into every phase of Agile development so teams can innovate and release faster without sacrificing their security practices. It integrates automated manual checks in your development workflow to create a seamless DevSecOps environment while maintaining Agile speed and efficiency. This blog will address how DevSecOps as a Service can change the aspects of testing by adopting an Agile test approach and improving security posture in the development process.
Understanding DevSecOps as a Service

Before we explore DevSecOps as a Service and its impact on Agile testing workflows, we need to understand what DevSecOps is and what it means for organizations. DevSecOps is the practice of embedding security into the DevOps pipeline, making it continuous rather than an isolated process in the development workflow.

In the past, security was seen as a distinct task, often viewed as a secondary activity when software was nearly ready to deploy. However, in the current development model, security cannot be left until the end. This brings us to DevSecOps, that is, shifting security left in the process right from the beginning.

DevSecOps as a Service is a cloud-based offering that provides organizations with the tools and processes to implement DevSecOps practices without having to build everything in-house. In this model, organizations are able to access new security technologies, capabilities, and automation through the service provider instead. Agile teams also benefit from this model because they can seamlessly introduce safety to their continuous integration/continuous delivery (CI/CD) pipeline and maintain speed with less friction.

The Shift from Agile to Agile with DevSecOps

Agile methodologies have changed the game for software development teams. The emphasis on quickly delivering working software and iterating with speed enables organizations to remain competitive and meet the demands of their customers. However, Agile’s iterative methodology presents challenges when it comes to integrating security.

In a typical Agile setup, security can often be an afterthought or a stand-alone process that doesn’t align well with the speed of sprints. Without proper integration of security practices, vulnerabilities can become a source of delays and cost too much to fix quickly.

DevSecOps as a Service transforms this dynamic by embedding security testing directly into the Agile development process. This continuous security integration ensures that vulnerabilities are identified and addressed early in each sprint, rather than being caught late in the cycle or, worse, post-deployment. By making security a part of the Agile workflow, DevSecOps ensures that teams can work securely and efficiently, without sacrificing the speed that Agile promises.

Automation of Security Tests: How It Works

One of the biggest advantages of DevSecOps as a Service is the automation of security tests across the development life cycle. To illustrate, in the Agile movement, where teams deploy multiple times a day or week, manual security checks would slow development and create bottlenecks. Automation ensures that security testing happens without human intervention, which will provide faster and more frequent releases without lowering security standards.

Security tools, integrated into the CI/CD pipeline, can automatically perform various types of tests, including static application security testing (SAST), dynamic application security testing (DAST), and software composition analysis (SCA). These tools scan the codebase for known vulnerabilities and security flaws, automatically alerting the team if a problem is found. In addition to identifying risks, they can suggest remediation steps, helping developers address issues quickly and efficiently.

In the CI/CD pipeline, security tools can automatically conduct various types of tests, including static application security testing (SAST), dynamic application security testing (DAST), and software composition analysis (SCA). These tools search code bases for known vulnerabilities and security issues, automatically alerting the team if a problem is found. In addition to identifying risks, they can suggest remediation steps, helping developers address issues quickly and efficiently.

For example, using DevSecOps as a Service, every time code is pushed to the repository, an automated security scan is initiated. If vulnerabilities are detected, they are flagged immediately, and the development team is notified. This real-time feedback loop enables Agile teams to deal with security issues without impeding development work.

Continuous Monitoring and Feedback Loop

Continuous monitoring is a key element of both Agile and DevSecOps. Agile teams work in sprints, with frequent deployments, while DevSecOps supports continuous integration, continuous delivery, and continuous feedback. As a service, DevSecOps does more by presenting continuous monitoring of the entire software development lifecycle.

When integrated, security monitoring tools are deployed within the continuous integration and continuous delivery pipeline to facilitate continuous monitoring of the code deployments as well as ongoing monitoring of the security posture of the application. As various monitoring tools assess what's happening in the software development lifecycle, teams receive feedback on potential vulnerabilities, misconfigurations, or security concerns. This way, teams can intervene and develop a solution before an aggravating condition develops into something more serious.

With tools providing automated scans, vulnerability assessments, and real-time alerts, teams have continuous assessment of their app security. This aligns nicely with Agile’s iterative style of development that ties feedback to the outcome of every iteration. Rather than waiting until the end of an iteration to test and assess the deployment of code or post-deployment testing, Agile teams can address security risks within their ongoing development cycles.

Shifting Left: The Importance of Early Security in Agile

The term "shifting left" refers to moving security further left in the lifecycle or addressing security as early as possible within the development cycle, as opposed to waiting till the end. From an Agile perspective, to shift left means to have security checks at the beginning of the work for the sprint, meaning security risks are evaluated continuously throughout the development process.

Traditionally, in Agile testing workflows, security checks have generally existed as a separate phase at the end of the sprint, or in some cases, after a release. If that is the case, there exists a chance for the team to miss critical vulnerabilities or misconfigurations which could lead to security vulnerabilities or performance issues down the line.

DevSecOps as a Service addresses this challenge by implementing security tests directly into the sprint cycles. For example, automated tests could be run as early as the planning and design stage to ensure security issues are flagged and remediated before writing any code. Then, as the developers write code, security assessments would continue parallel tracks to other tests, enabling more vulnerability identification before the product is finalized.

Shifting security left can significantly lower the risks of security breaches and ensure security standards for their applications from the start. This early detection leads to faster fixes and more secure releases, without the need for time-consuming, post-release patching.

Collaborative Culture: Developers, Security, and Operations

One of the core principles of DevSecOps is collaboration. DevSecOps as a Service can support Agile teams in growing a sense of shared ownership relative to security. With traditional software development models, security was often an afterthought or handled separately from development teams. Security was addressed by professionals testing or auditing code while developers were focused solely on code and functionality. This approach often led to miscommunication and delays when security issues were uncovered.

In DevSecOps, security is a shared responsibility among the development, security, and operations teams. Developers are empowered to take ownership of security tasks, such as writing secure code and fixing vulnerabilities. Security professionals collaborate closely with developers to ensure that security standards are met throughout the development process. Operations teams, in turn, ensure that security measures are maintained during deployment and monitoring.

DevSecOps as a Service makes it even easier to implement collaboration by providing tools and platforms that facilitate communication and automate many of the responsibilities. For example, it allows developers to incorporate security testing directly into their IDEs, which allows them to fix vulnerabilities while writing code. All of this community and shared responsibility creates a seamless and efficient production process that is also secure.

Conclusion

As organizations continue to transform and adopt agile methodologies for software development, embedding security into these workflows is not just best practice but a necessity. DevSecOps as a Service is changing how Agile teams approach testing and offer automated, continuous, integrated security processes as part of the development cycle. This transformation is not only reducing the amount of time spent fixing vulnerabilities but also ensures that security is a constant consideration, rather than an afterthought. By embedding security earlier and more frequently, Agile teams can deliver secure, high-quality software at a faster pace, while maintaining the efficiency and flexibility that Agile promises.

Striking a Balance: Navigating the Open-Source Tightrope in a World of Evolving Threats - Part 3

2025-04-08T09:00:00.042000+02:00

By Philip Engelmartin, Technical Advisor, Office of the CSO

The Strategic Imperative of Transitioning to Inner Source Development

In the final part of our series, we explore the strategic benefits of transitioning to an inner source development model. This approach offers a robust solution to mitigate the risks associated with open-source software (OSS) while preserving its collaborative spirit and fostering innovation within a controlled environment.

Addressing Counterarguments: Finding Balance in a Complex Landscape

Critics of moving away from OSS argue that it stifles innovation and limits access to valuable community expertise. However, inner source development can replicate and even enhance these benefits within a more controlled environment:

Internal Collaboration and Knowledge Sharing

Inner source promotes collaboration and code reuse within the organization, fostering innovation and improving code quality through internal peer review and adherence to best practices. By creating an environment that mimics the collaborative nature of OSS development, organizations can encourage developers to share knowledge, contribute to various projects, and leverage the collective expertise of their peers. This approach fosters a culture of collaboration and continuous improvement, which can drive innovation and enhance the reliability of software.

Strategic Engagement with the OSS Community

Organizations can continue to contribute to and benefit from the OSS ecosystem by strategically selecting projects that align with their values and risk tolerance. This targeted approach allows leveraging external expertise while maintaining greater control over the software supply chain and aligning with strategic goals. By engaging strategically with the OSS community, organizations can stay connected to the latest developments and innovations while managing the risks associated with OSS use.

Acknowledging Ecosystem Interdependencies

The argument that completely abandoning OSS is impractical holds merit, as OSS forms the foundation of many software ecosystems. However, a risk-based approach allows for a more nuanced strategy:

Prioritizing Critical Components and Dependencies

Organizations can focus their efforts on developing inner source alternatives for critical components that pose the greatest risks, enhancing security and control. For less critical dependencies, they can adopt a more pragmatic approach, balancing the benefits of OSS with the need for robust security and compliance. This risk-based approach ensures that resources are allocated effectively, addressing the most pressing risks first and systematically improving overall security.

Active Participation in Key OSS Projects

For essential OSS projects, organizations can increase their involvement through financial contributions, code contributions, and active participation in governance structures. This proactive engagement allows organizations to influence the direction of these projects, advocating for enhanced security and maintainability while fostering a collaborative relationship with the OSS community. By actively participating in key OSS projects, organizations can ensure that they are contributing to the health and resilience of the broader software ecosystem.

Tailoring the Solution: Inner Source as a Strategic Imperative

Transitioning to an inner source software development model offers a robust and sustainable solution to mitigate the risks associated with OSS while preserving its collaborative spirit and fostering innovation within a controlled environment.

Benefits of an Inner Source Model

Enhanced Security and Control
By developing and maintaining critical software components internally, organizations gain greater control over code quality, security practices, and access permissions, reducing the attack surface and minimizing the risk of vulnerabilities. This approach ensures that security protocols are consistently applied, and potential threats are promptly identified and mitigated. Through inner source development, organizations can implement a more controlled and secure software development process.
Predictable Lifecycles and Support
Inner source empowers organizations to manage the complete lifecycle of their software components, ensuring ongoing maintenance, timely security updates, and compatibility with evolving software requirements. This predictability enables better planning, resource allocation, and risk management, enhancing overall software reliability. By controlling the lifecycle of software components, organizations can ensure that their software remain secure, reliable, and up to date.
Simplified Licensing and Legal Compliance
Developing code internally significantly reduces licensing complexities and legal risks associated with OSS, providing organizations with greater clarity and flexibility in their software development and distribution strategies. This simplification fosters a more streamlined and efficient development process, minimizing legal disputes and compliance challenges. By adopting an inner source model, organizations can avoid the complexities of OSS licenses and focus on innovation and software development.
Strengthened Supply Chain Resilience
Inner source fosters a more resilient and self-reliant software development ecosystem, reducing dependence on external factors and mitigating the impact of geopolitical instabilities or supply chain disruptions. Building and maintaining critical components in-house ensures continuity and stability, even in the face of external challenges. By developing software internally, organizations can enhance the resilience of their supply chain and better protect their software against disruptions and threats.

A Call to Action: Building a More Secure and Sustainable Future

The risks associated with heavy reliance on OSS are too significant to ignore, especially as the threat landscape evolves and software plays an increasingly critical role in global infrastructure and sensitive industries. Organizations have both the opportunity and the responsibility to lead by example, demonstrating that innovation and security can coexist through a strategic embrace of inner source development.

Key Steps to Enable a Successful Transition

Conduct a Comprehensive OSS Risk Assessment
Identify all OSS components used across the software portfolio and assess their associated risks based on factors such as costs, criticality, code quality, contributor trustworthiness, license implications, and geopolitical considerations. A detailed risk assessment provides a clear understanding of potential vulnerabilities and informs strategic decision-making. By conducting a thorough risk assessment, organizations can identify areas of greatest risk and prioritize their efforts accordingly.
Prioritize Inner Source Development Efforts
Focus on transitioning critical and high-risk components to an inner source model based on the risk assessment. Prioritization ensures that resources are allocated effectively, addressing the most pressing risks first and systematically improving overall security. By prioritizing inner source development, organizations can ensure that their most critical components are managed in a controlled and secure manner.
Foster an Inner Source Culture
Cultivate a culture of collaboration, knowledge sharing, and code reuse within the organization by providing developers with the tools, training, and incentives to embrace inner source practices. Fostering this culture promotes a sense of ownership, accountability, and continuous improvement among development teams. By encouraging a culture of inner source development, organizations can ensure that their software development processes are efficient, collaborative, and aligned with their strategic goals.
Establish Robust Governance and Security Processes
Implement clear guidelines for inner source contributions, including code review protocols, and vulnerability disclosure policies. Robust governance ensures consistency, quality, and security across all development activities, fostering a transparent and accountable development environment. By establishing robust governance and security processes, organizations can ensure that their software development practices are consistent, reliable, and secure.
Invest in Secure Software Development Tools and Infrastructure
Equip development teams with secure coding tools that enforce secure coding practices, identify vulnerabilities in real time, and offer effective remediation suggestions. Establish a centralized internal vulnerability database to track and manage vulnerabilities discovered in inner source components. This database should integrate with development tools and workflows to streamline vulnerability management. By investing in secure software development tools and infrastructure, organizations can ensure that their software development processes are robust, efficient, and secure.
Engage Strategically with the OSS Community
Maintain a collaborative relationship with the broader OSS community by contributing to and supporting key projects that align with the organization’s values and long-term strategic goals. Strategic engagement enables organizations to stay informed about industry trends, emerging threats, and innovative solutions, enhancing their overall resilience and adaptability. By engaging strategically with the OSS community, organizations can ensure that they are contributing to the broader software ecosystem while managing the risks associated with OSS use.

Conclusion

By embracing inner source as a strategic imperative, organizations can build a more secure, resilient, and sustainable software foundation, solidifying their position as trusted partners and ensuring the long-term integrity and innovation of their software offerings. This approach allows organizations to strike a delicate balance between leveraging the advantages of OSS and implementing robust security measures to protect against evolving threats.

This concludes our series on navigating the open-source tightrope in a world of evolving threats. By understanding the multifaceted risks, navigating the complex landscape of OSS licensing and geopolitical influences, and implementing a robust inner source strategy, organizations can achieve a balance between innovation, security, and resilience.

Quarterly Release Highlights: SAP BTP Security and Identity & Access Management

2025-04-09T09:52:29.976000+02:00

In the first quarter of 2025, we released several new features and enhancements for SAP Cloud Identity Services. Let’s take a closer look!

SAP Cloud Identity Services allows tenant administrators to create and edit application-specific groups via the administration console. While this feature was released at the end of 2024, we added token attribute configuration capabilities in 2025. You can now specify how the local user attributes, configured to be collected by the registration and upgrade forms, are sent to the application. Read Configuring User Attributes from the Identity Directory for detailed information.

You can now enable identity federation for an application to override the identity federation settings on the configured corporate identity provider for the application. For more information, check Configure Identity Federation for Applications.

We added automatic renewal of expired SAML signing certificates. Identity Authentication can automatically update the expired encryption certificate as well as the SAML 2.0 certificate during the first sign-in attempt that fails due to the expired certificate. You can find details in our SAP Help Portal documentation: Configure SAML 2.0 Service Provider.

We extended the Identity Directory service to trigger immediate provisioning of application-specific groups. This enables companies to adopt our reference architecture for cloud-leading identity lifecycles and accelerate adoption of SAP cloud solutions. It also reduces efforts for point-to-point connections. The SAP Help Portal offers additional information.

You can now download and view the details of all entities updated by a provisioning job. For more information, see Manage Provisioning Job Logs and List of Properties.

Want to stay up to date on our services? Join our SAP BTP Security and SAP Cloud Identity Services communities!

Beyond the Black Box: The Illusion of Control

2025-04-16T12:52:48.620000+02:00

An LLM is just a stochastic machine for predicting the next word - I have heard this statement so many times, and each time I wondered how unaware the people who say it are. It has always been clear to me that we don't fully understand how Large Language Models work, and that they remain a black box for us. In fact, new studies are starting to show that AI doesn't work the way we thought it did.

I highly recommend that you pay attention to "Tracing the thoughts of a large language model" by Anthropic. The most interesting thing about the whole document, in my opinion, is that the LLM doesn't just plan the next token; it actually plans ahead. This means that when it outputs a particular token, it already has an "idea" of what's coming later. This contradicts our previous understanding of LLMs as simply selecting the most probable next token.

If that already sounds a bit uncertain, things are about to get even more intriguing. In early April, Anthropic released a paper titled "Reasoning Models Don't Always Say What They Think", and it's definitely worth pondering over. Until now, we believed that by following the "Chain of Thoughts" of these so-called thinking/reasoning models, we could manage security. That's not true at all. It turns out that large language models don't always use CoT the way we expect. The chain of thought often reflects what we humans want to hear, not necessarily the model's true reasoning process.

Moreover, the model is capable of hiding its true intentions and excluding them from the Chain of Thoughts. Research by Anthropic indicates that a model intentionally using so-called reward hacking revealed this in its "internal" Chain of Thoughts in only 2% of cases. In the remaining cases, it simply concealed it from humans.

At this stage, it's clear that we can't ensure AI safety just by examining the output of a large neural network, even through its "internal" CoT. The situation certainly won't be improved by the fact that there are already ideas to make the reasoning process completely hidden from humans. Recently, a paper titled "Scaling up Test-Time Compute with Latent Reasoning: A Recurrent Depth Approach" came out. It suggests transferring the thought process even before the LLM begins generating any tokens. From a performance standpoint, this might seem beneficial, but it would certainly make AI as a black box even harder to control.

Let's not forget that last year, there were already papers showing that AI has a strong survival instinct and will attempt to escape whenever it gets the chance to avoid being shut down. Moreover, it has been demonstrated that AI will try to manipulate us to achieve its goals. This is indicated by several studies, including "Frontier Models are Capable of In-context Scheming". At the time, this was detected by analyzing CoT. Today, we know that this was just the tip of the iceberg.

Back in the early days of Generative AI, there were many discussions about the safety and ethical issues surrounding artificial intelligence. But now, it feels like those conversations have died down significantly, even as AI's capabilities and autonomy have skyrocketed. At that time, it was clearly stated that AI was not such a significant threat as long as we did not give it access to the internet and operated it in a highly controlled manner. Nowadays, in what's being called the Year of AI Agents, this seems completely forgotten, and no one appears concerned anymore.

We are increasingly granting artificial intelligence access to various tools, including full control over computers - even in cloud environments. We're seeing a growing integration of artificial intelligence with our SAP systems. AI is steadily being integrated into business processes in our companies and will soon likely gain some decision-making capabilities.

Don't get me wrong, I myself am an AI enthusiast and work on projects in this area. Perhaps you know my SAP GUI AI Agent. Moreover, I am finishing creating an agent that has access to the Linux system and is capable of installing SAP HANA. But perhaps all the more reason to heed a warning from someone who is not an AI skeptic.

I'm not writing this to scare you but to raise awareness. Therefore, my only proposal is for you to incorporate security and ethics checks into all your AI projects. I think this was a big topic when AI was just starting out, but now that it's getting more powerful, people don't really talk about it much anymore. It's getting easier and easier for us to integrate AI into everything, often without thinking about the consequences.

Try to see this from a broader perspective rather than just focusing on the here and now.

A Holistic Approach to SAP Security: Introducing the Secure Operations Map (SOM)

2025-04-23T10:43:47.152000+02:00

What Is the Secure Operations Map—and Why Does It Matter?

The Secure Operations Map is a reference model designed to bring clarity and structure to the broad and often fragmented field of SAP security, helping teams categorize discussions, identify security needs, and map solutions to specific areas of responsibility.

It focuses on operational security—the day-to-day tasks, decisions, and ongoing management needed to run SAP systems securely. While it's interpreted in the context of SAP systems, its structure and principles are also applicable to non-SAP environments.

Secure Operations Map (SOM)

Understanding the five Layers of the Secure Operations Map

The Secure Operations Map breaks down security into five interrelated domains: Environment, System, Application, and Process, supported by the overarching Organization layer.

Environment

This domain covers the non-SAP technical infrastructure that supports SAP solutions.

Network Security: Preventing and detecting attacks at the network level using zoning, firewalls, and intrusion detection/prevention.
Operating System & Database Security: Enforcing OS and DB-level controls like permissions and encryption to safeguard applications.
Client Security: Ensuring end-user devices follow best practices to prevent attacks via compromised clients.

System

This layer focuses on securing the SAP platform itself.

Security Hardening: Activating and configuring key security features such as UCON, SAProuter, and frontend hardening.
Secure SAP Code: Managing security patches and updates via SAP Security Notes and maintaining a robust patching process.
Security Monitoring & Forensics: Combining proactive monitoring with reactive forensics to detect and respond to threats in real time.

Application

Application-level controls are vital in controlling user actions and safeguarding data.

User & Identity Management: Handling the full lifecycle of users, including technical and emergency access.
Authentication & Single Sign-On: Verifying user identities and enabling seamless, secure access across systems.
Roles & Authorizations: Designing and managing authorizations and segregation of duties (SoD) for business roles.
Custom Code Security: Managing the entire lifecycle of custom code with secure development and deployment practices.

Process

Security isn’t only technical—it's also about compliance and operational integrity.

Regulatory Process Compliance: Implementing controls aligned with laws such as HIPAA, SoX, or Basel III.
Data Privacy & Protection: Meeting GDPR and similar legislation requirements with strong confidentiality measures.
Audit & Fraud Management: Detecting and preventing fraud while ensuring all controls are auditable and effective.

Organization

This supporting layer provides the strategic and cultural context for everything else.

Awareness: Promoting a security-aware mindset throughout the organization.
Security Governance: Establishing procedures and responsibilities to support security efforts.
Risk Management: Identifying and addressing risks through continuous analysis and mitigation strategies.

Where Should You Start?

With such a broad landscape, one of the first questions is naturally: Where do I begin? The answer isn’t “everywhere”—it’s about security supporting your business, not maximum security possible. Overengineering security can limit functionality and drain resources. Instead, follow this approach:

Begin with Baseline Measures: Every SAP system should implement SAP’s baseline security best practices. SAP Note 2253549 provides a solid starting point for that.
Perform a Risk-Based Analysis: For critical systems or when you are part of a regulated industry, assess security needs based on specific risks and regulations.
Focus on High-Risk Domains First: Identify your most vulnerable or high-impact areas and implement a prioritized improvement plan.
Establish Strong Operational Monitoring: Security isn’t static. Put in place continuous monitoring to validate and improve controls over time.

What’s Next?

This post introduces the structure and purpose of the Secure Operations Map. In my next blog post, we’ll dive deeper into each domain, explore common challenges, and show how SAP Security Consulting can support your journey toward a secure, compliant, and resilient SAP landscape.

References: Secure Operations Map

SAP LogServ integration with Microsoft Sentinel for SAP RISE customers is now GA.

2025-04-28T09:25:45.776000+02:00

This blog was co-authored by Yossi Hasson (Sentinel Product Lead, Microsoft), Martin Pankraz (SAP PM, Microsoft), Aarthi Kannan (ECS Cloud Security Architect) & Krishna Rajapantula (ECS Lead of Security Engineering Operations)

Following last year's Limited preview release, we are thrilled to announce the General Availability of the integration between SAP LogServ and Microsoft Sentinel, exclusively for SAP S/4HANA Cloud, private cloud edition (RISE) customers around the globe.

The solution can be deployed natively from the Microsoft Sentinel Content Hub.

Prerequisites

Purchase Order for SAP LogServ should be completed
Microsoft Sentinel instance created
Currently available only for Azure - SAP RISE customer's.
- Stay tuned this integration will soon be available to AWS - SAP RISE customer's & GCP - SAP RISE customer's

How to integrate SAP LogServ with Microsoft Sentinel

SAP RISE customers who subscribed to LogServ, should install SAP LogServ (RISE), S/4 HANA Cloud Private Edition from Microsoft Sentinel Content Hub
- The connector deployment tries to create all resources in one go. Among them a Microsoft Entra ID app registration. In case the user doing the deployment has not enough rights, this process needs to be split up. Click the button anyways, which finalizes the creation of the Data Collection Endpoint and Data Collection Rule in the same resource group as your Log Analytics Workspace.
- If needed, In a second step create your app registration, supply a secret, and assign that Entra ID app id to the Data Collection rule with the role "Monitoring Metrics Publisher".
Once installed the customer should reach out to their:
- ECS CDM or ECS TSM and
- Putting sap-logserv-sentinel-integration@service.microsoft.com in cc
- Use the subject line: "SAP LogServ and Microsoft Sentinel - Activation" Please include your SAP RISE customer details in the email.
Share the following details with SAP using a secure channel (the screenshot below shows all required fields in case the deploying user was able to perform the connect in a single step):
- Entra ID app id
- Entra ID app secret (be aware it shows only on first create!)
- Data Collection Endpoint (looks like this: https://asi-befd1111-c90d-40e8-82f4-4e79d3e4c92b-wts3.westeurope-1.ingest.monitor.azure.com)
- Data Collection Rule Immutable ID (looks like this: dcr-ce11d6a22f2b41bd864cba7c3040af01)
- Stream id: Custom-SAPLogServ_CL

SAP will check the eligibility of your RISE project and process your request accordingly. See the first blog for an architecture overview, and log type details. Understand the agentless data connector for the application layer from this Microsoft Learn article.

Get Started Today

Don't miss this opportunity to enhance your security posture with the powerful combination of SAP LogServ and Microsoft Sentinel. Activate today and be among the first to experience the benefits of this groundbreaking integration.

We look forward to your participation and to helping you incorporate your SAP RISE environments into your overall IT estate.

Once Again a Big shoutout to Aarthi, Krishna, Martin and Yossi

New Business Technology Platform Capabilities: Customer Identity and Consent Management

2025-05-06T13:00:00.026000+02:00

Today, SAP Business Technology Platform now includes our industry leading Customer Identity and Access Management (CIAM) solution through the BTP Enterprise Agreement. This highly scalable solution supports over 2.9 billion identities and 17.7 billion consent records.

Why SAP CIAM?

With SAP CIAM, you can deliver seamless customer experiences while upholding stringent security standards and accelerating growth. By harnessing your customer’s data effectively and responsibly, this solution empowers businesses of all sizes to bridge the numerous data strategy gaps that emerge in today's digital-first landscape — where there are more touchpoints to manage, engagement channels to orchestrate, and data points to collect than ever before. The power to personalize is easier than ever with consent based first-party data.

Explore this KuppingerCole report to learn how our CIAM solution stands out.

What is SAP CIAM?

SAP CIAM is a comprehensive identity solution which transforms customer data into actionable insights. Designed to function as a brand’s digital front door, this multitenant, cloud-native software plays a critical role in data strategy; it enables organizations to effectively capture and manage both customer and partner data while enhancing security and privacy and delivering personalized experiences.

By providing access to intelligent insights across the business landscape, SAP CIAM equips businesses to:

Secure users and safeguard data

Prioritize business protection with AI

Reduce privacy compliance risk

Overcome data silos

Increase efficiency at scale

Discover how SAP CIAM can elevate your business today.

How does SAP CIAM work?

SAP CIAM streamlines identity creation and authentication across digital platforms, allowing easy registration management for various devices. It securely stores and enriches customer data with each digital transaction, offering options like social login and biometrics for secure access. By assembling robust customer profiles, SAP CIAM helps businesses personalize experiences, boost engagement, optimize customer journeys, and make informed decisions while integrating seamlessly with existing systems.

Dive into more solution details with this short video.

Who needs SAP CIAM?

Any business that manages digital transactions can benefit from SAP CIAM. Today, it’s now more crucial than ever that organizations find a way to capture –– and manage –– customer and partner data because every online interaction is an opportunity to acquire user information, develop brand loyalty, and deepen trust.

SAP CIAM is available with both a B2C implementation and a B2B implementation.

Getting started with SAP CIAM

SAP CIAM is now available as part of the Business Technology Platform Enterprise Agreement (BTPEA). Existing consumption credits can be used on this solution, empowering your business to conveniently handle identity, consent, and authentication without entering into any new contracts. Learn more here.

Quick enablement of SAP Cloud Identity Access Governance with IAG QuickStart Service

2025-05-07T16:28:05.451000+02:00

Quick enablement of SAP Cloud Identity Access Governance with IAG QuickStart Service

You can streamline access management for both cloud-based and on-premise applications by implementing SAP Cloud Identity Access Governance (IAG) containing Access Analysis Service, Access Request Service, Role Design Service, Access Certification Service and Privileged Access Management Service. The configuration of SAP Cloud IAG can be subdivided in two main parts: basic steps relevant to all customers and steps that include individual settings. SAP Services offers the IAG QuickStart Service to simplify and speed up performance of the first part providing the initial setup and the technical baseline configuration in a short timeframe using SAP Best Practices content. The scope of the service includes the configuration of two target applications (incl. their productive as well as non-productive tenants) and a knowledge transfer session.

How IAG QuickStart Service is performed?

1. Questionnaire

Initially, SAP Services sends to a customer a questionnaire about technical data, required technical users and system hostnames. The information provided will be later used for automatic configuration.

2. Ensure prerequisites

As prerequisites, the customer must provide network configuration and additional configuration required, e.g., SAP Cloud Connector and SAP Cloud Identity Services (SCI). These activities are out of the scope of the IAG QuickStart Service itself. Using SCI with SAP Cloud IAG is mandatory, in case it is not in place yet and the customer doesn’t have resources or knowledge to configure it, SAP Services can support as well with its dedicated SCI service offerings.

3. Automatic and manual SAP Cloud IAG configuration

This stage includes the initial setup and technical baseline configuration, as well as setting up the connection to two target systems. Using scripts allows to significantly reduce time of the basic configuration steps.

SAP Services utilizes those scripts that run on the basis of technical information provided by the customer, aiming to accomplish the following tasks:

Setup of SAP Cloud IAG subaccounts
Setup of SAP Identity Authentication Service (IAS) standard groups for workflow and authorization purposes
Establish trust between SAP Cloud IAG and SAP IAS
Setup of SAP Cloud IAG standard destinations
Setup of IPS proxy systems
Setup of target system destinations for two applications (excluding prerequisite steps in target systems and connectivity). We recommend selecting IAS as one of the two target systems.

4. SAP service incident

SAP Services will create required SAP incidents on customer’s behalf, e.g., to upload SAP standard ruleset to SAP Cloud IAG.

5. Knowledge transfer and hand-over

SAP Services provides a configuration document, conducts a knowledge transfer workshop and hands over the preconfigured solution to the customer.

What is the outcome of the service and further steps?

As a result, the customer obtains a basic configuration that facilitates rapid activation of SAP Cloud IAG such that the customer can focus on configuring the functional aspects. After the service hand over, the customer can configure SAP Cloud IAG functionality according to company needs and test scenarios. Here as well SAP Services can support using their long-lasting SAP Cloud IAG project experience from many other customer projects.

SAP Sapphire In Orlando 2025: Responsible AI

2025-05-08T08:23:01.811000+02:00

Hello everyone,

I lead SAP's Responsible AI team, spearheading the integration of robust security and AI ethics frameworks into SAP Business AI. I and my team work towards ensuring SAP Business AI powered enterprise solutions are not only innovative, but also trustworthy, ethical, resilient, and compliant. I'm pleased to invite you to my sessions at SAP Sapphire Orlando and together delve deeper into these topics.

Responsible AI - SAP Sapphire 2025 Sessions:

AI security: Ask the experts your toughest questions - BAI2613- Tuesday, May 20 11:00 AM - 11:20 AM EDT

Responsible AI in action: Building trust and driving innovation - BAI2612- Tuesday, May 20 3:30 PM - 3:50 PM EDT

Securing AI: How SAP protects business data and workflows - BAI2611- Wednesday, May 21 2:30 PM - 2:50 PM EDT

Responsible AI - SAP Sapphire Virtual Session:

Responsible AI at SAP: Ethics, security, and compliance in focus - BAI5089v - Tuesday, May 20 11:00 AM - 11:20 AM EDT

What you will learn about:

Using Generative AI to improve how your business works isn't just a nice idea anymore, it's essential to stay competitive. Robust, ethical, and secure AI solutions drive customer trust and safeguard business operations. At SAP, Responsible AI is woven into the fabric of our Business AI strategy, ensuring that every stage from design and development to operations is underpinned by strict security standards and regulatory controls.

Our SAP Business AI portfolio, including AI Core, Joule, Foundation models and embedded AI solutions, is built on a foundation of “Trust by Design.” These products embody security and privacy controls right from base design, integrating robust cloud security principles, enterprise-grade operational policies, and an agile governance model to meet global regulatory standards. Business AI cloud services leverage security controls and operational logic built into SAP Business Suite and provide transparency, business relevance, content moderation, resilience against attacks and regulatory compliance.

Regulatory frameworks and ethical guidelines—rooted in global principles such as UNESCO’s recommendations—guide our AI ethics framework. This ensures fairness, human oversight, and relentless accountability in high-stakes scenarios. For instance, Joule’s capabilities in enforcing user access combined with relevance of AI outcome and agentic workflows not only support operational excellence but also proactively mitigate risks by continuously aligning with evolving security and ethical benchmarks.

As the discussion on security and privacy in Artificial Intelligence intensifies, SAP’s commitment is clear: an integrated approach that anticipates risks, enforces robust controls, and reinforces ethical AI use. We are excited to delve deeper into these topics at SAP Sapphire Orlando 2025.

Related community managed tags you should subscribe to remain informed about this topic:

SAP Business AI

SAP AI Core

Joule

Related community topic pages:

SAP Business AI

SAP AI Core

Joule

Looking forward to seeing you:

Connect with our experts, explore detailed use cases, and discover how our SAP Business AI stack is designed to foster secure, compliant, and responsible AI – bringing out the best in every business.

Now let’s hear from you:

Please share in the comments section which factor of artificial intelligence you think is primary driver in user's trust in AI?

Handling IDoc Status Restrictions in SAP WE47

2025-05-08T09:35:52.457000+02:00

Introduction

To restrict or unrestrict IDoc statuses, you can use transaction code WE47 to modify the status settings. This allows you to define which IDoc statuses are considered valid for different actions like deletion or archiving. You can also use transaction BD87 to reprocess or delete IDocs that have specific statuses, according to SAP Help Portal.

Check out my post for a detailed explanation of Archiving IDocs in SAP (Write & Delete): A Step-by-Step Guide for First-Time Implementation

Why WE47 Matters in IDoc Archiving

The transaction WE47 (Status Management) defines which IDoc statuses are deletable during the Delete phase of archiving.

IDocs with a status code that is marked as “not deletable” in WE47 will remain in the system even after a successful archiving write and delete run.

Example: Status 64 (IDoc ready for processing) is not deletable by default. If such IDocs are selected during archiving, they will be archived but not deleted.

Key Notes Before Starting

Always coordinate status changes with BASIS + Functional teams.
Document all changes to WE47.
Maintain a separate list of “critical statuses” to avoid deletion risks.

How to Identify Which Statuses Block Deletion

Step-by-Step

Use transaction code WE47 to access the IDoc status maintenance screen.
Navigate to the relevant section within WE47 to define which IDoc statuses are allowed for certain actions.
You’ll now see whether the “Deletion” flag is set to poss (possible for deletion) or excluded (from deletion).

Unrestricting IDoc Status (Allow Deletion)

To allow deletion of an IDoc in a specific status:

Detailed Steps:

Use transaction code WE47 to access the IDoc status maintenance screen. .
In the list, search for the status code (e.g., 64, 51).
Select the entry and double-click to open it.
Check the “Poss” radiobutton.
Click Save.
Re-run the Write & Delete Program to ensure the deletion of idocs with above status

Check out my post for a detailed explanation of Archiving IDocs in SAP (Write & Delete): A Step-by-Step Guide for First-Time Implementation

Outcome : Now, the previously blocked IDocs will be successfully deleted.

Restricting IDoc Status (Prevent Deletion)

Sometimes you may want to protect certain IDoc statuses from being accidentally deleted—like those that haven’t been processed yet or are under investigation.

Steps to Add Restriction:

Go to WE47.
Click New Entries or select an existing status.
For the given status code, mark the radio button “ Excluded ”.
Save your entry .

Check out my post for a detailed explanation of Archiving IDocs in SAP (Write & Delete): A Step-by-Step Guide for First-Time Implementation

Outcome : Now any IDoc in this status will be excluded during deletion runs.

Reprocess or Delete IDocs (if needed):

If you need to reprocess or delete IDocs with specific statuses, use transaction code BD87.

Changing an Existing Status Entry

You can switch a status between restrict/unrestrict anytime, but use caution in production systems.

Best Practice: Only unrestrict after verifying business approvals. Unarchived error IDocs might contain pending or critical info.

Action	Tool	Result
Check which IDocs weren’t deleted	SE16N → EDIDC	Identify blocked statuses
View/Change status restriction	WE47	Check " Poss "
Protect sensitive statuses	WE47	Check " Excluded "
Re-archive undeleted IDocs	SARA → Write + Delete	Complete removal

Conclusion

Using WE47 wisely helps you take full control over IDoc lifecycle management. Whether you want to retain unprocessed IDocs or clean up your system, this tool plays a critical role in SAP data governance.
If you're performing IDoc archiving for the first time or troubleshooting undeleted records, make WE47 your go-to transaction!