SAP Community - SAP BTP Security

Integrate app into Work Zone from a different subaccount

2024-01-29T10:26:44.538000+01:00

I'm Julian Kuipers, a Full Stack SAP Developer in The Netherlands, currently working with a company called INNOV8iON. We focus on creating new and better ways to use SAP.

Introduction

Not long ago, I was given a task that looked easy at first but turned out to be quite a puzzle. My job was to integrate a custom Fiori application, which has its own standalone approuter, into SAP Build Work Zone, standard edition. The tricky part was that the Fiori app and the SAP Build Work Zone were in different subaccounts, which made things more complicated.

To figure out how to do this, I first looked at the official SAP instructions, which you can find here: SAP Help Portal. These instructions are pretty good, but I found they didn't cover everything I needed to know.

So, I came up with my own plan to make it work:

Turn on something called allowListService in the Fiori app: This is like saying, "It's okay for this app to be used in the SAP Build Work Zone."
Use whitelistService in the standalone approuter: This makes sure the router activates the whitelist-service.
Add specific user-provided variables to the app: This will add Work Zone as trusted URI to embed this app as an iFrame.
Make a trusted connection in the subaccount for the app: This is like making sure the app has a secure line to talk on.

I also learned a couple of important tips along the way:

SAP says it's best if the app and the Work Zone use the same custom domain. This makes a lot of the setup simpler because you don't have to do extra steps to make them work together.
The way I made it possible for users to log in isn't the fanciest solution, but it works well if you're only using one IDP (Identity Provider).
This project really made me think and helped me learn a lot about how SAP works and how to make different parts of it work together. I wanted to share what I learned so others who might be trying to do the same thing can find it a bit easier.

Solution

Following the steps outlined in the SAP Documentation, along with the additional instructions I’ll provide, will ensure a smooth integration process for your custom Fiori application into SAP Build Work Zone. Let's break down these steps for clarity and implementation ease:

1. Activate the allowListService in the Custom Fiori App

To activate the allowlist service in your application, you'll need to insert a specific script before the sap-ui-bootstrap code in your HTML file. This script configures the allowlist service, enabling the application to determine if it's allowed to run within a given frame. Here's the code snippet you should place:

<script> 
    window["sap-ui-config"] = { 
        allowlistService: '/allowlist/service', 
        frameOptions: 'trusted', 
        frameOptionsConfig: { 
            callback: function (bSuccess) { 
	        if (bSuccess) { 
	            console.log("App is allowed to run!"); 
	        } else { 
	            console.error("App is not allowed to run!"); 
	        } 
            } 
        } 
    }; 
</script>

index.html

This snippet ensures your application checks if it's permitted to run, based on the allowlist service configuration. For further details, visit the SAPUI5 SDK Documentation.

2. Activate the whitelistService in the Standalone Approuter

In your standalone approuter configuration, add the following segment to activate the whitelistService, pointing to the allowlist service endpoint:

"whitelistService": { 
    "endpoint": "/allowlist/service" 
}

xs-app.json

This configuration enables your approuter to utilize the whitelist service, ensuring it recognizes and permits communications from your Fiori application. For comprehensive instructions, refer to the SAP Documentation.

3. Add User-Provided Variables to the Application

To allow the SAP Work Zone to embed your application in an iFrame securely, you must specify certain variables and HTTP headers. This involves declaring a whitelist of origins that are permitted to frame your content without risking click-jacking attacks. Here's how you configure it:

properties:
    CJ_PROTECT_WHITELIST: '[{"host":"<WORKZONE_RUNTIME_HOST>"}]' 
    httpHeaders: '[{"Content-Security-Policy":"frame-ancestors <WORKZONE_RUNTIME_HOST>"}]'

mta.yaml

This configuration ensures that your application can only be framed by the SAP Work Zone, enhancing security and compliance with SAP's guidelines. More details on these settings can be found in the SAP Developer Guide.

4. Adding Work Zone Host as a Trusted Domain

The last piece of our integration puzzle is to ensure that the Work Zone runtime host is recognized as a trusted domain by the XSUAA service of the Fiori app. This step is vital for embedding the app securely within the SAP Build Work Zone environment, ensuring that authorization and authentication flows are handled correctly without compromising security.

To accomplish this, you'll need to follow the guidelines outlined by SAP for configuring trusted domains specifically for the SAP Authorization and Trust Management service. The detailed steps for this configuration can be found in the SAP documentation: Configure Trusted Domains for SAP Authorization and Trust Management Service. This resource provides a comprehensive guide on how to add your Work Zone host as a trusted domain, ensuring that your custom Fiori app can be securely embedded and accessed within the SAP Build Work Zone.

Implementing these steps will facilitate the integration of your custom Fiori application with SAP Build Work Zone, ensuring both functionality and security are maintained.

Conclusion

As I've journeyed through the process of integrating a custom Fiori application into SAP Build Work Zone, it's clear that while the steps are straightforward once understood, there's a particular aspect of this integration that merits a closer look—the propagation of user login information, especially in contexts where multiple Identity Providers (IDPs) are involved.

This workaround is okay for now if you're just dealing with one IDP. It's not the slickest solution, but it does the job. However, if you're trying to make things work with several IDPs, that's where it gets trickier. If you're stuck in this spot, I found a blog that might just be your lifesaver. It's all about figuring out SAP Cloud Identity Services and making them work with SAP Build Work Zone when you've got multiple IDPs. Check it out right here: De-mystifying SAP Cloud Identity Services Integration.

Now for some good news—SAP's got our backs and is working on making this whole process a lot easier. They've hinted at some new improvements that are on the way, which you can sneak a peek at in their roadmap right here. I'm all in for seeing how they're going to make our lives simpler in the near future.

So, as we wrap this up, I just want to say it's been quite the ride figuring out all these SAP integration quirks. The thought of SAP making things smoother down the road is something I'm really looking forward to. In the meantime, we've got our workarounds and the helpful tips we've shared along the way.

Thanks for sticking with me through this journey. Here's to making things work and looking forward to easier days ahead!

Kind regards,

Julian Kuipers

PFCGMASSVAL – Detailed Features | Best Practices | Best Use Cases

2024-01-29T11:50:36.103000+01:00

What is PFCGMASSVAL?

SAP S/4HANA offers a significant transaction code - PFCGMASSVAL that allows consultant to perform mass maintenance on authorization data of roles. It is essentially a tool for making bulk changes to user permissions across multiple roles, saving great deal of time and effort compared to modifying them individually.

Important Note :

It works exactly on 1 to Many propagation on role(s)
ONE Authorization Object | Organizational Level update for N number of roles
Multiple Fields of an Authorization Object can be updated at one execution
Not possible to Add | Delete Transaction Code from Role Menu

Change Functionality of PFCGMASSVAL

For each type of field change you define whether you want to Add | Delete | Replace values. The following generally applies: As many changes as possible are made. This means: If you are adding a value and the required authorization is missing, or the value is already contained in the authorization, this value is removed from processing.

Add : Choose "Values" to enter the values that you want to add

Delete : Choose "Values" to enter the values that you want to delete

Replace All : All existing values of the organizational level or authorization are deleted. Choose "Values" to enter the values that you want to add

Replace : Choose "To Replace" to enter the values that you want to replace. Choose "Values" to enter the values that you want to add instead. This action only takes place if all values to be replaced of all fields exist. You cannot make partial replacements

Roles with Authorization Data :

This multi select options allows you to filter roles based on different selection criteria so that you can curate and refine specific set of roles for authorization maintenance.

Key Features of PFCGMASSVAL

PFCGMASSVAL transaction code offers a range of features, including the ability to :

Change Organizational Level value :

You change the values of organizational levels of the selected roles across all objects (global maintenance). This action does not affect authorizations whose organizational levels have already been maintained individually.

Change Field Values of an Authorization Object :

When you select an authorization object, all its authorization fields are displayed. Maintain the values for those fields that you want to change. If any of these fields is an organizational level, a warning icon is displayed.

This tells you that the value changes you make to this field only apply to individual authorizations and result in the maintenance status "Changed". The values from the global maintenance (see above) no longer apply for these authorizations.

Change Field Values of an Authorization Object (Cross-Object) :

With this type of field change you change the field values of authorizations for a specific authorization field, but for all authorization object that contain this field. Enter the name of the authorization field and maintain the values that you want to change. Entering the authorization object is optional; an input help is available for you to select the fields of the object.

If you are in the "Activity" (ACTVT) field and have specified an object, you are shown which activities are allowed for this object and can make your selection. Again, if a field is an organizational level, a warning icon is displayed. The same applies as in the previous section.

Add a Manual Authorization to an Object :

This function supplements the selected roles with a manual authorization for exactly one authorization object. Values can be entered for the fields of the authorization to be added, but they can also be left open. When maintaining organizational level fields, note the statements made for the previous two options.

The manual authorization is added to roles even if they already contain authorizations with the required field value combination. To avoid adding superfluous authorizations, use the processing mode "Execution with Previous Simulation" (Check out first picture).

This produces a results list containing the authorization to be added and also all existing authorizations for the same object, so that you can exclude any roles that do not need the new authorization before further processing.

Delete Manual Authorizations for an Object :

You use this function to delete manual authorizations for exactly one authorization object in the selected roles. The function only deletes those authorizations that contain all values of all fields that are maintained on the selection screen. If you do not maintain any values, all manual authorizations of this object are deleted.

Add F4 as Default Value without changing to status “Changed” :

The authorization default values of many applications values now have the additional value F4 in different authorization fields. This makes it possible to distinguish between displaying objects and listing them in input helps. You can use this function to Add F4 to authorizations of single roles whose menus contain the relevant applications. Since the maintenance status of the enhanced authorizations is retained, the new value can be used very quickly without any individual editing of roles.

Old Authorization Status :

The change can be restricted to authorizations with the status "Standard", "Maintained", "Changed", or "Manual".

No Switch to Status "Changed" :

If this option is active, any changes that would result in the authorization status changing from "Standard" to "Changed" or from "Maintained" to "Changed" are discarded or ignored.

Note the following: Maintaining organizational levels individually also results in a status change from "Standard" to "Changed".

Supplement Long Text :

By choosing 'Text', you can save a description that is appended to the long text for all changed roles. However, the long text of a role can only be maintained if you are logged on in its original language.

Therefore, if you use this option, authorizations are only changed if the logon language matches the original language of the role. You can either “Type-in” or upload a “TXT” format file to load the text.

Best Practices for Using PFCGMASSVAL

It is recommended to :

Always use a Selection for roles to avoid affecting all roles
Run the Simulation first before making any changes. This mode simulates the changes you want to make and displays them in a results list
Use the selection options carefully to avoid changing authorization status ‘Standard’ and ‘Maintained’ into ‘Changed’
Generate the Profile for impacted roles to have updated profile and authorizations
After changing authorization data of root roles, adjust derived roles using PFCG for every root role using the menu path Authorizations -> Adjust Derived Roles
Activate the checkbox “Exclude Derived Roles” to avoid touching derived roles by mistake

Best Use Cases for Using PFCGMASSVAL

Presenting few use cases where PFCGMASSVAL can be of higly beneficial

Mass update of Display authorization to Multiple Parent Roles

Example: Change Field Values of Authorizations for a Field (Cross-Object) used to Add Activity - ACTVT field of multiple authorization objects with values: “03 | F4”

Converting maintenance role to Display only role

Example: Change Field Values of Authorizations for a Field (Cross-Object) used to Replace All Activity - ACTVT field of multiple authorization objects with values: “03 | F4 | 33 | A6”

Mass update of an Authorization Object Field Values to Multiple Parent Roles

Example: Change Field Values of an Authorization Object used to change Document Status - STATUS and Document Type - DOKAR for Authorization Object: C_DRAD_OBJ

Similar case can be used to update Authorization Field of an Authorization Object to multiple roles

Conclusion

PFCGMASSVAL transaction code is a powerful tool in SAP S/4HANA that allows for efficient and effective management of authorization data. By understanding its features and following best practices, a Security Consultant can achieve mass operations simplified at a streamlined process through SAP Standard program without involving additional scripts. Unleash the power of SAP.

SAP Security Configuration Recommendations

2024-02-02T08:21:41.559000+01:00

The list of Security Recommendations for major SAP cloud products is published on the SAP Trust Center, as shown in Figure 1.

Figure 1: Security Recommendations published on SAP Trust Center

Customers have been asking for a unified view of the security configuration of their deployed cloud solutions. This central visualization should report on the configuration status of SAP services and compare it against recommended settings.
To achieve this goal, we initially had to provide a check list with human readable security recommendations documents.
Together with SAP BTP and SAP Customer Success (owners of the SAP Security Baseline standards [1], mostly covering on premise), we drafted the main structure of the security recommendations. Let us highlight the main differences between the security recommendations and the security guides:

A security guide is a holistic document, describing all the relevant security parameters as well as their possible values in detail (for example: defining supported encryption settings or enabling or not multifactor authentication);
Whereas a security recommendation document provides recommendations of specific values for a security setting and restrictions about their usage to enable customers to securely operate production systems. A security recommendation document extracts a list of parameters that customers can influence (namely user-configurable security settings) and it describes, for each setting, the recommended secure values.

Finally, we introduced the requirement for a standardized security recommendation documentation in our software development lifecycle, targeting major SAP cloud products.

[1] Access to SAP customers only

SAP Security Configuration Dashboard using SAP Analytics Cloud (Template)

2024-02-02T08:22:13.348000+01:00

Overview

SAP provides an SAP Analytics Cloud Story for a template of a Security Configuration Dashboard delivered as Community Content. Customers can either use it directly or as a starting point to develop their own more extensive dashboard. The template consumes security configuration data from the SAP Cloud ALM API. Details on the SAP Cloud ALM API can be found in this blogpost.
While SAP Cloud ALM provides basic search and display functionality for the collected data, a security configuration dashboard template based on SAP Analytics Cloud might be useful to complement this visualization.
A documentation including a description on the connection to SAP Cloud ALM system and the consumption of the API to retrieve the data is part of the delivered content.

Visualization Examples

The story is prepopulated with sample data to provide an overview of the security dashboard capabilities to customers.
Thus, a compliance officer or a cloud security administrator, responsible for the operation and the security & compliance can use SAP Analytics Cloud dashboard template as a single source of truth for gathering information to get analytical insights into the security status of their SAP Cloud Solutions and to identify a risk score.
As displayed in the example in Figure 1, one can see that 5 cloud systems are connected against their dashboard and overall, 30 security controls are in place. For these security controls, 16 items are reported to the dashboard as non-compliant. Out of these 53% of non-compliant items, one can notice 40% of critical items, 37% with a high criticality and 23% with medium items to solve. Worth noticing as well that over the last 24 hours no new items have been received; a security compliance officer might be interested in what happened on the last day, when the last input came in.

Figure 1: Compliance View Example 1

The visualization example in Figure 2 shows the different compliance status by different aggregation attributes. Overall, it displays the compliance status per categories like the risk level, or the cloud application that are affected and the components, the topics and the items spread over the SAP secure operations map. The SAP Analytics Cloud dashboard template offers the possibility to click on any item and to drill-down to the related categories. For instance, one can spot the most critical non-compliant items and check which cloud application is the most affected. Another view can provide more details on the component, for instance Destination Service, which contains the most critical non-compliant items to fix. The view on the topic provides additional input, showing for instance, that the token lifecycle is impacted. Finally, the view of the compliance per SAP´s secure operations map reflects which area, in this case, Authentication & Sign-On, is concerned.
More visualization screens are also available, so as to facilitate the analysis of the security status of SAP Cloud Solutions.

Figure 2: Compliance View Example 2

Security Configuration APIs for major Cloud Products

2024-02-02T08:22:36.575000+01:00

According to the cloud shared responsibility model, customers shall be aware of security-related settings they are responsible for. To enable e.g., a compliance expert or a cloud security administrator to monitor the adherence of the security-related settings to the expected values, key services and applications are required to send this data to SAP Cloud ALM. Here, an external API is provided to enable a central consumption of the aggregated data. For this, Cloud ALM Next Generation – Data Collection Infrastructure (NG-DCI) is leveraged. It provides a standardized way to collect data using OpenTelemetry. Performance Monitoring, Integration Monitoring and Exception monitoring from Managed-Cloud services are some examples of the various use cases of OpenTelemetry within SAP Cloud ALM.
As shown in Figure 1, services and applications push their security configuration data to a Central Data Receiver (Data Collection Runtime). SAP Cloud ALM collects the data using its Central Data Receiver and persists it in a Configuration & Change Database (aka CCDB) in the SAP Cloud ALM tenant of the customer. From there, it can be visualized through a list view in SAP Cloud ALM UI.
Configuration data can also be consumed externally via the API Framework of SAP Cloud ALM (cf. Figure 1). The API framework supports delivery of aggregated data for analytics, metrics for alerting and a log format for raw data (i.e., customer settings on the service side).

Figure 1: High-level architecture.

Services and applications send their prevalidated customer managed security configuration settings to SAP Cloud ALM. There, it is routed to the customer’s SAP Cloud ALM tenant and persisted in its Configuration and Change Database (CCDB). By default, services and applications will not send the security configuration data before a customer has turned this feature on in their SAP Cloud ALM tenant. Once it is turned on, data is synchronized daily.

The SAP Cloud ALM Analytics API can be used to retrieve this data for external consumption. This blog post gives an example how to connect to and call the API. More information can be found on the official help pages and the API hub.
A security configuration dashboard template based on SAP Analytics Cloud is available to complement the visualization, as described in this blog post.

First BTP services successfully implemented this integration with SAP Cloud ALM and are now publicly available. Further BTP services as well as other SAP cloud solutions are planned to provide their data in the future. You can check the progress on the SAP Cloud ALM release note page.

Join the Innovation Journey with SAP Enterprise Threat Detection, cloud edition

2024-02-04T19:00:00.037000+01:00

Picture 1

Embark on a Journey of Growth and Innovation and secure customers Businesses Now and Tomorrow with SAP Enterprise Threat Detection, cloud edition.

At a time when threats are constantly evolving, SAP Enterprise Threat Detection, cloud edition is a robust solution. We are pleased to announce our expansion journey and officially invite like-minded partners. Be part of our journey of progressive growth and innovation and take advantage of this exciting opportunity. Let's secure the digital landscape together and foster an environment that is not only secure but also conducive to innovation.

Picture 2

Current State of application security & corporate compliance

The need for robust cybersecurity measures has been amplified by our increasingly digital economy. Statistics reveal that 81% of data breaches result from lost, stolen, or weak passwords, of which three-quarters are instigated by outsiders. Alarmingly, a quarter of these breaches are carried out from within the organizations showing that cybersecurity threats do not solely exist externally but also pose a significant internal risk that demands attention.

Increasing Importance of Cybersecurity

Organizations now readily recognize the relevancy of their cybersecurity posture, with 64% rating it as either important or very important. These businesses understand the integral link between a robust cybersecurity framework and reduced risk of data breaches for all involved - employees, customers, and partners. As many as 65% of the organizations acknowledge this correlation in our intensively digitized business world, where data security is of paramount significance.

The Talent Gap

However, a considerable challenge remains - the acute scarcity of security talent in the industry. A staggering 87% of organizations are struggling with a shortage of cybersecurity specialists. As a result, the number of global cybersecurity job vacancies has drastically increased by an impressive 350%, from 1 million in 2013 to an anticipated 3.5 million in 2021. With the increasing proliferation, sophistication, and scale of cybercrimes, this glaring lack of qualified talent creates a significant hurdle for businesses globally.

Cost of Cybercrime

From a broader perspective, the extraction of an alarming $6 trillion annually from the global economy due to cybercrime reinforces the severity and urgency of reinforcing cybersecurity measures. It is worrying to find that only a mere 38% of organizations can proactively spot risks before they develop into serious threats.

Picture 3

Cybersecurity as a Business Risk

Cybersecurity, once considered a specialized branch and an IT domain challenge, has escalated to command serious attention at executive levels within organizations. Recent data show that a substantial 88% of board members view cybersecurity as a critical business risk, marking a significant shift from 2016 figures - when only 58% shared the same view. This shift signifies a growing seriousness about cyber threats and their potential to impact businesses at large.

Security and Compliance

Importantly, it must be noted that organizations cannot be compliant without establishing thorough security measures. Compliance to industry standards and regulatory requirements, while providing a guide, cannot alone ensure security. It is insufficient to just adhere to compliance checklists. The rising surge in cybersecurity threats calls for more elaborate and dynamic security protocols, which go well beyond basic compliance frameworks.

The Impact of Security Inadequacies

Failures in the security domain can render organizations susceptible to cyber-attacks, breaches, and violations, inevitably affecting compliance outcomes. These cyber risks disrupt business processes, putting at risk confidential and sensitive information and thus impacting overall compliance with industry standards. Hence, it is fundamental for an organization to incorporate security measures not merely for compliance, but to safeguard vital assets, secure data, uphold reputation and provide assurance to stakeholders.

Picture 4

Embedding Security into Organizational Fabric

Therefore, if compliance is the goal, weaving security into the very fabric of an organization is essential. This necessitates transforming approaches to view cybersecurity as an inherent part of the business strategy, thus amplifying overall compliance and resilience to cybersecurity threats.

Picture 5

Benefits of leveraging SAP Enterprise Threat Detection

SAP Enterprise Threat Detection (ETD), cloud edition, is a cutting-edge SAP Business Technology Platform Software-as-a-Service (SaaS) solution. Moreover, it incorporates managed services from SAP or one of our specialized partners, dedicated to identifying, analyzing, and reporting malicious activities in your SAP applications before they can inflict serious damage.

Along with presenting a detailed audit trail of all activity and detecting anomalies, ETD provides best practice advice for monitoring SAP applications. It also aids companies in complying with onerous regulatory requirements such as those outlined in the EU's NIS2 directive, the RCE, KRITIS, General Data Protection Regulation (GDPR), as well as various local security laws.

Picture 6

The Power of Partnership

As we, at SAP, expand our product and service horizons, we're inviting partners to join us on our journey of growth and innovation. We fervently believe that by synergizing our individual proficiencies and skills, we can significantly advance the way we serve our clients and deliver unparalleled value, not just to our direct customers, but to partners' customers as well.

By partnering with SAP, you as partner receive multi-fold strategic benefits. To start with, you can take advantage of our advanced cybersecurity solution which will instantly enable you to augment your service propositions and boost client confidence. With this service, your customers will benefit profoundly as it offers more than just data protection. It equips them with strengthened security measures, significantly reducing their threat to potential breaches. Plus, it delivers an invaluable sense of tranquility, knowing that their data is safeguarded. This secure atmosphere fosters trust and confidence, allowing your customers to focus on growing their businesses, rather than worrying about data security. Moreover, it elevates their experience with your partnership, reinforcing your reputation as a reliable, secure provider.

On top of this, leveraging SAP's extensive global network, you can amplify your reach in the market, acquire access to untapped industry sectors and widen your customer base. The sheer magnitude of our network ensures that associating with us instantly lends an additional layer of trust and reassurance to your customers, thereby bolstering their already existing confidence in your services.

Picture 7

Exploring New Opportunities

But that's not all! Your engagement with SAP Enterprise Threat Detection, cloud edition equips you with the resources to create unique security services and solution offerings tailor-made to address your customers requirements and objectives. This could take the form of customized managed security services, expert compliance and security consulting, or portfolio optimization. It opens up the gateway to innovative security opportunities, empowering you to stay abreast of competition and offer forward-looking, cutting-edge solutions to your customers.

Getting in Touch & Moving Forward

To explore potential collaboration, receive more information, or simply discuss synergies, feel free to reach out to Tobias Keller or Arndt Lingscheid.

Our doors (and inboxes) are always open to engaging discussions on combating cybersecurity threats together.

Explore our SAP Enterprise Threat Detection Partner Portal to delve deeper into our product and partnership framework.

We, at SAP, wholeheartedly invite all entities who are serious in their quest to enhance their cybersecurity strategies. Together, we can augment our defenses against the incessant tide of cyber threats and build a safer, resilient digital economy. Let's rise to the challenge, together.

SAP Enterprise Threat Detection | SAP Community

How SAP Data Custodian Addresses Data Privacy of SAP Signavio Process Insights

2024-02-14T00:23:31.407000+01:00

In today's digital age, data collection, storage, and utilization have become essential for business operations and personal interactions. However, the growing importance of data-driven processes and respective analyses has raised significant concerns about data privacy, security, and the need to comply with federal regulatory requirements.

Data Privacy for Guarding Digital Sanctity

Data privacy is a basic principle that governs the collection and use of personal information. With the increasing number of online platforms and interconnected devices, there is a higher risk of unauthorized access to sensitive data. People are becoming more aware of their rights to control the information they share online, and they expect organizations to handle their data responsibly.

Federal Data and Regulatory Landscape

Federal regulatory requirements are important for managing data in the SAP Ecosystem. Regulatory bodies like the General Data Protection Regulation (GDPR) in Europe and the Health Insurance Portability and Accountability Act (HIPAA) in the United States have strict rules for data privacy and security practices. These regulations aim to ensure that organizations collect, process, and store data in a way that respects individuals' rights and prevents misuse.

Safeguarding New Cloud Innovations of SAP

In today's fast-paced business world, it's crucial to stay ahead of the competition. That's why SAP has invested in innovative solutions and technologies to enhance efficiency and improve the customer experience. Among these innovations are SAP Signavio Process Insights, SAP Generative AI, SAP Datasphere, and SAP Build. These technologies are designed to overcome the challenges of rapid transformations and improve the quality of services. They will transform the way businesses operate, make decisions, and optimize processes. However, it's important to note that data privacy is critical, and it's essential to establish trusted communication between SAP Cloud Solutions and S/4HANA systems.

Infusing Privacy with SAP Data Custodian Features

The following are the key features of SAP Data Custodian.

Here is an example of how the Transparency and Control features of SAP Data Custodian can be integrated with the SAP Signavio Process Insights solution:

Contextual Application Control for SAP Signavio Process Insights

Scenario Description: A customer using SAP ECC or SAP S/4HANA stores federal data and has recently decided to use SAP Signavio Process Insights to analyze and improve their business processes. However, some of the data to be analyzed contains sensitive information and as such, should be excluded from the data collection. For instance, a particular sales organization shows exposure to such sensitive data as shown in the SAP Signavio Process Insights screen below. SAP Signavio Process Insights solution offers role-based access controls however, some of the data privacy aspects are still needed.

SAP Data Custodian Solution Offering:

SAP Signavio Process Insights periodically processes extracted data from SAP ERP systems and provides insights and recommendations on business processes. The ST-PI plugin is used to extract application data from SAP ECC or SAP S/4HANA and those data will be imported into SAP Signavio Process Insights for business process analysis. SAP Data Custodian can be used to control sensitive data at the point of extraction. This means the data excluded via SAP Data Custodian will not leave your ERP system. The integration code for the Data Custodian S/4HANA Add-on is embedded natively into ST-PI, eliminating the need for any additional integration steps.

Prerequisites

SAP Data Custodian, add-on for SAP S/4HANA SP15 is installed and configured.
SAP Data Custodian tenant is configured including control policies.
ST-PI SP25 installed in SAP ECC or SAP S/4HANA
SAP Signavio Process Insights source system prerequisites for SAP ECC or SAP S/4HANA are met.

High-Level Steps:

S/HANA: Configure Org-Level Data for Filtering in SAP Data Custodian Application Controls (IMG via transaction /n/sdcac/img)
SAP Data Custodian Tenant: Create an SAP Data Custodian policy to remove sensitive data from S/4HANA Extractions (via Unions Management in SAP Data Custodian Tenant). After synchronization, the resource facts configured in the SAP S/4HANA system are available in your SAP Data Custodian tenant. These resource facts can be configured in SAP Data Custodian policies to remove sensitive data from SAP ERP extractions.
S/4HANA: Setup Data Transfer to SAP Signavio Process Insights (via transaction /n/sdf/pins_setup)
SAP Signavio Process Insights tenant: SAP Signavio Process Insights Filtered Sales Organization which was restricted in Data Custodian Policy
Data Custodian generated alert for the filtered Sales organization
Benefits of the SAP Data Custodian Integration with SAP Signavio Process Insights:
- Address Global Data Privacy Regulations
- Natively built into SAP Data Custodian Transparency and Control Add-on
- No ABAP Customizations required
- Policy-based configuration setup and no special development needed
- Establishing a Privacy Foundation for achieving Data Privacy and Control with features such as Anonymization, Data Blocking, Data Masking, and Pseudonymization

Key SAP Contacts:

SAP Data Custodian Product Management: Priyank Patel, Peter Whibley

SAP Signavio Product Management: Dirk Jendroska, Sandra Meier, Till Trautewig

SAP MaxAttention CoE: Kiran Kola, Rohit Dwivedi

Getting started with SAP BTP Solution Diagram

2024-02-23T07:41:25.143000+01:00

SAP BTP Solution Diagram is finally released to harmonize the domain specific architectural diagrams on SAP Business Technology Platform. Though it wouldn't be a detailed blog, I'll list down some important points and references on it.

So, what' new & different :

Diagram Harmonization on all the BTP offerings.
Can serve architectural diagram creation on different use cases. Has three layered levels : L0, L1 & L2 to cater different expectations of recipients.
Reusable diagram structures
Can be used with raw.io or Microsoft PowerPoint.

Guideline to use : https://d.dam.sap.com/a/UbBJrVh/SAP-BTP-solution-diagram-design-guideline-v1-public.pdf?rc=10

How to use : SAP BTP Solution Diagrams can be used in two different ways as follows:

draw.io - The recommended option. It is an online diagram software for making flowcharts, process diagrams, org charts, UML, ER and network diagrams. it can be installed from Releases · jgraph/drawio-desktop (github.com) & upon installing, SAP BTP Solution Diagram libraries need to be imported from https://github.com/SAP/btp-solution-diagrams.git .
Microsoft PowerPoint - Microsoft PowerPoint can also be used with some limitations. The custom shapes and guidelines are present in this template https://d.dam.sap.com/a/e7KMGSu?rc=10

The entire project guidelines are present here : BTP Solution Diagrams | BTP Solution Diagrams (sap.github.io)

What else? Happy exploring just like I'm doing right now 😊

SAP GUI MFA with SAP Secure Login Service and Microsoft Entra ID

2024-02-26T17:05:25.982000+01:00

This blog post guides you through the setup of an end-to-end scenario for implementing multi-factor authentication (MFA) for SAP GUI with Microsoft Entra ID (formerly known as Microsoft Azure Active Directory, AAD). The integration with Microsoft Entra ID is accomplished by SAP Cloud Identity Service and the SAP Secure Login Service for SAP GUI. Kudos to @Christian_Cohrs for supporting the setup of the test environment and thoroughly reviewing this blog post.

Tune in to the SAP on Azure video podcast episode 183 to see Christian and me explaining the concepts and to see a live demo of the scenario.

Scenario walk-through

Figure 1 (source draw.io file attached to this blog post) illustrates the setup for the scenario and the end-to-end communication flow for the MFA-secured and SSO (Single-Sign-On)-enabled login process:Figure 1 SAP GUI MFA scenario

The test user in this scenario, Jack Davis, logs on to his workstation with his Active Directory (AD) domain account. Upon successful login, AD issues a Kerberos ticket. Jack then launches SAP GUI and SAP Secure Login Client (SLC).
In SLC, Jack starts the authentication process with the SAP Secure Login Service for SAP GUI (SLS) via the SLS Profile.
The authentication request from SLC is delegated by SLS to the SAP Cloud Identity Services - Identity Authentication (IAS) tenant that is configured as a trusted identity provider in the SAP Business Technology Platform (BTP) subaccount of the SLS subscription.
The IAS tenant delegates the authentication request from SLS as an identity provider (IdP) proxy for the SAML (Security Assertion Markup Language) 2.0 protocol to Jack’s corporate Cloud IdP, the Entra ID tenant. This requires setting up a mutual trust relationship between the IAS and Entra ID tenants by exchanging each other’s SAML 2.0 metadata, which includes public cryptographic information in the format of X.509 certificates to verify the authenticity and integrity of the SAML messages sent in this step. In the Entra ID tenant, an Enterprise Application registration represents the IAS tenant with its SAML 2.0 metadata, and the corresponding Corporate Identity Provider in IAS gets created by importing the Entra ID tenant’s metadata.
The SAML request sent by IAS to Entra ID requires Jack to authenticate with his credentials. To offer a seamless single-sign-on (SSO) experience, Jack’s user account in Active Directory is securely synchronized with the Entra ID tenant by the Microsoft Entra Provisioning Agent running on the domain controller. With the seamless SSO feature enabled, Jack can sign-in to his Entra ID tenant from a domain-joined device connected to the corporate network without typing in his username and password. Instead, Entra ID verifies the Kerberos ticket issued to Jack on his domain-joined workstation to sign him in silently.
An Entra Conditional Access (ECA) policy enforces the second authentication factor. The policy is applied to the Enterprise Application registration for IAS in the Entra ID tenant and kicks-in for every new login request received for the app after first-factor authentication is completed. ECA continues the login process by asking Jack to enter a secure, time-based one-time passcode (TOTP).
To enter the code, Jack must install an authenticator app that supports TOTP verification, such as the Microsoft Authenticator app, on a device he owns. For the initial setup of Jack's account in Entra ID for MFA, Jack scans a QR code generated by Entra ID with the authenticator app. On subsequent sign-ins, the authenticator app generates a new TOTP every 30 seconds that Jack can type in to complete the MFA process.
Entra ID returns a SAML response to the (SAML) request from IAS in step 4. Likewise, IAS generates a SAML response to the SAML request from SLS in step 3, which finally results in a short-lived X.509 client certificate for Jack generated by SLS in response to step 2. The client certificate has the Common Name (CN) set to Jack’s user principal name (UPN) in Entra ID (e.g. jdavis@bestruncorp.onmicrosoft.com). It is signed by the SAP Cloud Root Certificate Authority (CA), and has a default lifetime of 12 hours. SLC provides the X.509 certificate for SSO and Secure Network Communications (SNC) between SAP GUI and the SAP Application Server (AS) ABAP. For SSO to work, the administrator of the SAP system must maintain the mapping from Jack’s user account in SAP to Jack’s CN (UPN). Furthermore, the backend must have a trust relationship established to the issuer of the client certificate, the SAP Cloud Root CA.

Prerequisites

The setup instructions in this tutorial assume that you've met all of the following prerequisites:

Administrative access to an Entra ID P1 or P2 tenant to enable hybrid identity management with provisioning of the users from the on-premise Active Directory to the Microsoft Entra ID tenant, and multi-factor-authentication using Entra Conditional Access (CA). This requires Conditional Access Administrator, Security Administrator, or Global Administrator privileges. If you need to, you can request a free Microsoft 365 Developer license, which includes a P2 tenant for development and testing purposes. The domain name of the tenant used in this tutorial is bestruncorp.onmicrosoft.com, but you can also choose any other name. Please follow this tutorial to install the Entra provisioning agent in your lab environment and configure Entra Connect Cloud Sync for your domain and tenant.
Administrative access to an IAS tenant.
Administrative access to an SAP BTP subaccount that has trust established to the IAS tenant (see instructions).
A valid license for the SAP Secure Login Service for SAP GUI service to be visible as an entitlement in your BTP subaccount. You should have already created an instance of the service in your subaccount following these instructions.
Administrative access to an Active Directory (AD) domain controller (DC) and a domain-joined workstation for simulating the corporate network. You can create the required systems in your lab environment as Hyper-V VMs and configure them according to the table below:

System	Configuration
Domain Controller	Windows Server 2019 or later Active Directory Domain Services (AD DS role). Installing the AD DS role and promoting a Windows Server to a domain controller is documented here. The domain name used in this tutorial is corp.bestrun.com (NetBIOS: CORP), but you can also choose any other name. Microsoft Entra provisioning agent (for installation see this tutorial or these instructions)
Workstation	Windows 10 Pro or later, domain-joined SAP GUI 7.70 or later SAP Secure Login Client 3.0 SP02 Patch Level (PL) 16 or later

A non-administrator account used for testing the scenario in your local domain that is synchronized with the Entra ID tenant
Administrative access to an SAP Application Server ABAP for testing the SNC SSO with SAP GUI and the SLS-issued client certificate. One of the easiest ways to setup a development and test system is to run the ABAP Platform Trial on Docker. Setup of the SNC configuration will be covered in the following tutorial steps.

Download the SAP Cloud Root CA certificate

The chain of trust or certification path for the short-lived client (user) certificates issued by SLS has its trust anchor in the SAP Cloud Root CA and two intermediate CAs (SAP PKI Certificate Service Client CA and SAP BTP Client CA) as shown in the following picture:

Figure 2: SLS client certificate chain of trust

To successfully verify the SLS-issued certificates for SSO, the SAP Cloud Root CA certificate must be downloaded and distributed to all domain-joined workstations and the SAP system.

Step

Description

Screenshot

1.1

Open a web browser and go to https://www.pki.co.sap.com to download the SAP Cloud Root CA certificate (or click this link).

Store the file on shared folder that is accessible from the domain-joined workstation.

Configure SNC in the SAP AS ABAP

You will setup SNC for X.509-based SSO in the SAP AS ABAP using transaction SNCWIZARD. Make sure that your lab environment’s ABAP application server (such as the Docker-based ABAP Platform Trial in my setup) uses the SAP Cryptographic Library (CommonCryptoLib) as the default cryptographic library for SNC.

Step	Description	Screenshot
2.1	Login with your test user to the workstation and start SAP GUI. Login to the SAP AS ABAP with your admin user (e.g. DEVELOPER for the ABAP Platform Trial system).
2.2	Start transaction SNCWIZARD. If you see the error message "DEFAULT profile in the DB and in the file system are different" then run transaction RZ10 first, and select Utilities → Import Profiles → Of active servers, and return to the SNCWIZARD.
2.3	On the Start page of the SAP Single Sign-On Wizard, click Continue.
2.4	Accept the default values for profile parameters and click Continue.
2.5	Click Close.
2.6	Log off from the SAP system.
2.7	You must restart the application server. If you run the server in Docker, go to your running container instance in Docker Desktop, select the Exec tab, and enter the command su <SID>adm As SAP system user <SID>adm, use the commands sapcontrol -nr <instance_number> -function Stop and sapcontrol -nr <instance_number> -function Start to restart the server. Replace <SID> with your system ID (e.g. “A4H”), and <instance_number> with the number of your application service instance (e.g. "00").
2.8	Login with your admin user and start the SNC Wizard again with transaction code SNCWIZARD. Click Continue.
2.9	Since we don’t want to configure SNC for Kerberos, click Skip on the Kerberos Credentials page.
2.10	On the X.509 Credentials page, copy the Distinguished Name (DN) of the system’s SNC private key from the Subject field into the clipboard.
2.11	Click Continue. This will start the Trust Manager with transaction STRUST.
2.12	Double-click on the SNC SAPCryptolib entry in the PSE list. Click the Display/Change button or Ctrl+F1 to enter edit mode.
2.13	Click Import certificate.
2.14	Stay on the File tab and select the file path for the downloaded SAP Cloud Root CA certificate. Click OK.
2.15	Click Add to Certificate List. Click Save (or press Ctrl+S).
2.16	Click the Display/Change button or press Ctrl+F1 to switch to display mode.
2.17	Click Exit.
2.18	Click Complete.

Configure SNC in SAP GUI

Step

Description

Screenshot

3.1

Right-click in SAP GUI on the system connection for your SAP system and select Properties... from the context menu.

3.2

Switch to the Network tab.

Activate the checkbox Activate Secure Network Communication.

In the SNC Name field, paste the SAP system's SNC private key DN copied in step 2.10. and add the prefix "p:" (e.g. "p:CN=A4H, OU=IINITIAL, OU=SAP Web AS, O=SAP Trust Community, C=DE").

Click Finish.

Distribute the SAP Cloud Root CA Certificate

To ensure that the client workstation can verify SLS and ultimately its trust anchor, the SAP Cloud Root CA, as a trusted issuer for the short-lived client certificates, the SAP Cloud Root CA certificate must be imported into the workstation’s local certificate store. In an Active Directory domain, Group Policies provide a centralized management, configuration and software distribution tool to the domain-joined devices. You will use the Default Domain Policy to distribute the SAP Cloud Root CA certificate to the workstation.

Step	Description	Screenshot
4.1	Login to the Domain Controller and open the Control Panel from the Start menu. Start the Group Policy Management editor from System and Security > Administrative Tools.
4.2	Select your domain name and right-click on Group Policy Objects > Default Domain Policy. Click Edit... from the context menu.
4.3	Go to Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies. Right-click on Trusted Root Certification Authorities and select Import… from the context menu.
4.4	The Certificate Import Wizard starts. Click Next.
4.5	Click Browse… and open the SAP Cloud Root CA certificate file downloaded in step 1.1.
4.6	Click Next.
4.7	Select the Trusted Root Certification Authorities to store the certificate. Click Next.
4.8	Click Finish.
4.9	Login to the client workstation and open a command line window. Group Policy is automatically refreshed when the domain-joined workstation restarts, or when a user logs on to the computer. In addition, Group Policy is periodically refreshed every 90 minutes with a randomized offset of up to 30 minutes. You can also run a Group Policy update to install the SAP Cloud Root CA certificate in the workstation’s local certificate store with the command gpupdate.exe /force

Configure the Secure Login Client

Download the client authentication policies of the Secure Login Service (SLS) to the Secure Login Client (SLC) in a profile group.

Step	Description	Screenshot
5.1	Login to your BTP global account with SAP BTP Cockpit. Then select the subaccount in which your SLS instance is subscribed to. Select the SLS subscription from the list in Instances and Subscriptions and copy the instance URL to the clipboard.
5.2	Open the SLC on the workstation. Select File -> Options… from the menu.
5.3	Switch to the Policy Groups tab. In the Host field paste the URL of your SLS service instance you've copied in step 5.1. Click Refresh, then Apply.
5.3	The new SLS profile is added which can be used later to obtain the X.509 client certificate from SLS.

Register IAS tenant in Entra ID

The IAS tenant must be registered in Entra ID to establish the trust relationship, which enables IAS to act as a SAML proxy in the scenario.

Step	Description	Screenshot
6.1	Login to the Entra admin center at https://entra.microsoft.com/ Select Identity à Applications à Enterprise applications from the left-side menu. Click New application.
6.2	Enter “SAP Cloud Identity” in the search bar. Click on the tile with the title SAP Cloud Identity Services from the search results.
6.3	Enter a name (e.g. “SLSIASTenant”). Click Create.
6.4	Upon successful registration of the Enterprise application, click the Set up Single Sign-On tile.
6.5	Click the SAML tile.
6.6	Open the SAML 2.0 metadata URL of your IAS tenant in a new Web Browser tab. The URL has the following pattern: https://<IAS FQDN>/saml2/metadata e.g. https://myias.accounts.ondemand.com/saml2/metadata Save the XML file.
6.7	Go back to the Entra admin center. Click Upload metadata file.
6.8	Select the downloaded metadata.xml. Click Add.
6.9	The SAML 2.0 configuration for the new enterprise application for the IAS tenant has been automatically populated with the content from the metadata file. Click Save.
6.10	Copy the App Federation Metadata Url to the clipboard for the next step.

Configure Corporate Identity Provider in IAS tenant

The following step adds the Entra ID tenant as a corporate identity provider to the IAS tenant.

Step	Description	Screenshot
7.1	Login to the Administration Console of your IAS tenant. Select Identity Providers à Corporate Identity Providers from the menu.
7.2	Click Create.
7.3	Enter a Display Name, e.g. Entra ID Tenant. Select Microsoft ADFS / Azure AD (SAML 2.0) as the Identity Provider Type. Click Create.
7.4	On the Trust tab of the new corporate identity provider, select SAML 2.0 Configuration.
7.5	Paste the URL copied to the clipboard in step 6.10 into the Metadata URL field and click Load.
7.6	The SAML 2.0 configuration of the corporate identity provider has been automatically populated with the content from the metadata URL of the Entra ID tenant. Click Save.

Test SLC login with Entra ID without MFA

Let’s do a first test of the scenario to verify that the IAS tenant correctly delegates authentication of the user to Entra ID as the corporate IdP and seamlessly single signs-on the user. Enforcing a second factor with Entra CA will be configured in the next step.

Step	Description	Screenshot
8.1	In SLC, right-click on the new SLS profile and select Log In… from the context menu.
8.2	With seamless sign-on enabled in Entra Connect Cloud Sync, the currently logged in user on the domain-joined workstation gets single signed-on to the Entra ID tenant. If you closely watch the communication flow in the embedded browser window you can see that the authentication request is delegated from IAS to Entra ID and the final response comes from IAS.
8.3	The use should be successfully logged in with the new profile. Right-click and choose Copy SNC name to clipboard. This value will be used in the next step to configure the required user mapping in AS ABAP. Then choose Log Out from the context menu.

Configure user mapping in the SAP AS ABAP

With the SNC name copied from the short-lived certificate generated by SLS we can now go ahead and map it to the corresponding user account in AS ABAP.

Step	Description	Screenshot
9.1	Since there is no user mapping yet you have to login to the SAP system without SSO. Right-click on the connection entry in SAP GUI and select SNC Logon Without Single Sign-On.
9.2	Logon with your admin user name and password.
9.3	Start User Maintenance with transaction code SU01.
9.4	Select a user account (e.g. DEVELOPER in the ABAP Platform Trial system) and click Change (Shift+F6).
9.5	Switch to the SNC tab. Click Change SNC Name.
9.6	Paste the value from the clipboard in the text field. Click OK.
9.7	Click Save.
9.8	Log Off from the system

Setup the Entra CA policy for MFA

Entra Conditional Access (CA) enforces the multi-factor authentication in the scenario. This requires the assignment of your test user to a CA policy that also defines the cloud app(s) that trigger the policy. The cloud app in this scenario is the IAS tenant which has been registered in the Entra ID tenant in the previous steps. Finally, you configure the actions whenever the IAS tenant sends a login request for the specified user (or group of users) which require additional processing, such as prompting for multifactor authentication.

Step	Description	Screenshot
10.1	Go back to the Entra admin center at https://entra.microsoft.com/ Select Protection à Conditional Access from the left-side menu. Click New policy.
10.2	Enter a Name for the new CA policy, e.g. “SAPGUIMFA”. Click the link in the section Users under Assignments to select the test user. Choose Select users and groups and activate the Users and groups checkbox. Select a test user for the scenario from your Entra ID tenant.
10.3	Click on the link in the Target resources section.
10.4	Select Cloud apps from the drop-down list and choose Select apps from the options. Click None to select an app from your Tenant.
10.5	Search for the name of the IAS enterprise application you registered in step 6.3, e.g. “SLSIASTenant”. Select it by activating the checkbox in search results.
10.6	Click the link in the Grant section of the new policy.
10.7	Choose Grant access from the options. Activate the checkbox to Require multifactor authentication.
10.8	Click Select.
10.9	Choose On from the Enable policy options. Click Create.

Test the scenario with MFA

Before you start testing the scenario with MFA enforced for the test user by Entra CA, verify that your Entra ID MFA registration policy includes your test user to enforce MFA.

Step	Description	Screenshot
11.1	In the Entra admin center, go to Protection à Identity Protection. Select Multifactor Authentication Registration Policy from the menu. Check that the policy includes your test user and the status is Enabled.
11.2	Open SLC and select the SLS profile. Right-click and select Log in.
11.3	If the test user hasn’t signed-in with MFA yet, Entra ID will prompt the user to start the setup process. This includes downloading the Authenticator App and setting it up
11.4	If the test user has already setup a device for MFA, Entra ID will display a number in the browser to enter in the Authenticator App.
11.5	The user enters the number in the Authenticator App to sign in.
11.6	Upon successful validation of the second factor, SLC received a new short-lived X.509 certificate for the user.
11.7	Login to the SAP system uses the X.509 client certificate with SNC to single sign-on the user. The SAP system can map the user to a known account based on the SNC mapping (see status bar).

Conclusion

Congratulations! You've successfully completed the tutorial. With this integration scenario, an IT security administrator can now consistently enforce MFA across all types of SAP clients from Entra ID and Conditional Access as the central control plane.

Supporting crypto agility with the BTP Trust Store

2024-02-28T11:47:47.072000+01:00

You have all heard that change is the new normal. This is true in many ways, including for IT security. Whether it is the cryptographic algorithm, the key length, or an individual key, we must always be ready to change to something “better”, namely more secure. This might not even be due to an attack, but rather be part of continuous efforts to stay ahead of all potential threats.

When it comes to protocols like Transport Layer Security (TLS), the level of security also depends on the root certificates that are the anchor of trust for the TLS-protected communication. In the past, the validity of root certificates could be decades, so a change would be a once in a lifetime thing. Today however, even though the root certificates are not really short-lived, they will still have to be replaced now and then.

Changing the trust anchor of communication in a large landscape requires some preparation, to ensure that everybody can communicate securely and without disruption. If you miss to update the trust configuration across all involved parties, then the change of a root certificate may cause an outage for all scenarios that rely on the trust.

When SAP changes the root certificates that are the trust anchors of BTP, we ensure that all scenarios inside the platform are ready, and the communication is not affected. However, you may also have clients or 3rd party applications that integrate with BTP. For these, the trust is not managed by SAP and so you need to take matters into your own hands.

With the new BTP Trust Store, we want to help you avoid outages by providing information about changes in the trust anchors of SAP BTP early. This gives you the time to roll out new root certificates before they become mandatory.

You will find the required root certificates in several well-known formats in the BTP Trust Store at https://github.com/sap-software/btp-trust-store

The trust store includes 2 sets of root certificates:

The “Required” root certificates are mandatory for all clients or services that communicate via TLS with SAP BTP-based services. Ensure that your clients or services trust these root certificates, and that changes to the list of root certificates are reflected early on your side, such as once per quarter. This will ensure that you can continue to communicate with BTP even if SAP changes root certificates over time.

The “Optional” set of root certificates represents the SAP Global Trust List provided by SAP Global Security, as documented in SAP Note 2801396.

Why I love SAP and Blockchain Databases and why you should too 🚀

2024-03-06T10:07:44.299000+01:00

I am going to be writing a lot of blogs about two of my loves, SAP technology and Blockchain technology, and this is the first one, so buckle up, it's going to be an exciting ride, and there is so much to discuss it's going to be a marathon rather than a sprint.

We've got so much to talk about in this space, this blog is going to discuss the why and the how:

. Why Blockchain Databases or Distributed Ledger Technology Databases are so useful for SAP Customers

and

. UseCases, how Blockchain can solve existing challenges and enable re-imagining of business processes

and

. How Blockchain and SAP is no longer just a dream, just a hype, but how you can start doing Blockchain and SAP today solve old challenges with new(er) technology

A lot has been written about Blockchain and Blockchain Databases, in the SAP Community there is a very nice explanation which I recommend you to read.

In 2019, Gartner wrote to CIO's and said, "CIOs should begin to embrace blockchain to explore strategic business initiatives, but avoid falling for the hype", that's 5 years ago, and the point is, back then, as I know from first hand experience, as a SAP Customer, if you wanted to "do" Blockchain, it was complicated, even just trying to play with the technology was like a University Project. And here's the thing, fast forward 5 years to 2024, and now, within the SAP Partner Edge Open EcoSystem there are enabling technology Blockchain Products designed and built by SAP Experts specifically for the needs of SAP Customers to make doing Blockchain and SAP easy, and so today, you can do SAP and Blockchain, it's no longer hype, today it's real and there's nothing stopping you.

McKinsey & Company, in their December 2023 Featured Insights Publication, gave a beautiful description of what is unique and special about Blockchain, "Blockchain is a secure database shared across a network of participants, where up-to-date information is available to all participants at the same time". If we just pause for a moment and let that sink in, and think about what that means, to Business Processes, to Collaboration, to System Resilience, we start to see what is so special about Blockchain Databases and Distributed Ledger Technology.

Let's begin with the first deliverable of the Blog, Why I love SAP and Blockchain Databases and why you should too, and:

Why Blockchain Databases or Distributed Ledger Technology Databases are so useful for SAP Customers

As a 25 year career veteran of SAP Technology, [15 years SAP Basis and 10 years SAP Tech Arch including Tech, Integration, Security, Data from 3.1H to S/4HANA PCE on RISE and the BTP and everything in between, and former SCN Moderator and Mentor alumni], some of the biggest challenges which I've spent a greater part of my career solving for SAP Customers are:

. Protecting the Integrity and Originality and Confidentiality of SAP Data - making sure that only the people and system who need to see it can see it in the Business Processes [here's a Blog I wrote in 2013]

. Protecting the Availability and Resilience of SAP Data and SAP Systems for Business Processes

. Protecting the Movement of SAP Data across Business Process which include SAP and 3rd Party Systems

. Protecting SAP Data which is Shared in collaborative Business Processes

To do all of this in the world we had prior to Blockchain Databases, required layers and layers of technologies, often from different Vendors, and combinations of automation and human centric processes.

To do all of the above items needed amongst other things:

. Multiple Installations of SAP Systems and Databases

. Clustering and Replication Software running between

. Job Scheduling Software

. Multiple layers of Security

Additional Encryption of Data when it is stored (at rest)

Additional Encryption of Data on the move (in transit)

Key Store Management and Rotation

House Keeping

. Monitoring & Logging

. Different Security and Resilience approaches and tools for the different

So we had to take the out of the box products and we had to build security and resilience on top of them with even more products and human centric processes.

And here's the thing, guess what, Blockchain Databases, Distributed Ledger Technology Databases have all of that built in ! How cool is that ?

Really... how does it work ?

Blockchain Distributed Ledger Technology has four special characteristics:

What is a Blockchain atkrypto.io

Let's think of a Blockchain Database as a Database Server Software. And let's think of the Blockchain Ledger as a Database Table.

If you install two or more Instances of the Blockchain Database Software and connect those two Instances together, you have a Blockchain Database Network, or a Distributed Ledger Network. In Blockchain Architecture this is considered as Layer 0, the Blockchain Network.

Blockchain is a very simple form of database atkrypto.io

The Four Layers of Blockchain Architecture:

The four layers of Blockchain Architecture atkrypto.io

Let's go through the characteristics of the Blockchain and why they are so special.

The Blockchain Hash Mechanism

Every row [Block-Data] in the ledger contains a unique Hash identity [This-Block-Hash]

Every row in the ledger contains the Hash of the previous row [Previous-Block-Hash]

The Hashes tie the Blocks together in a Chain and this is what makes the Chain of Blocks [Blockchain]

This weaves the rows of data together into an impenetrable sequence [as shown below]

The Blocks tied together as Chain make it very hard for hackers to insert new data into the Blockchain

The Blockchain Hash Mechanism atkrypto.io

The Blockchain Is Decentralised / Distributed

Blockchain Software must be installed on more than one Server (Node) in more than one place

This is what makes the Blockchain Decentralised and Distributed

Consequently the Blockchain has built in resilience and high availability and disaster recovery

To hack and attack the Blockchain you would have to destroy every Server where it is running

Blockchain Decentralised Distributed atkrypto.io

The Blockchain Is Immutable

Data in the Blockchain cannot be modified or deleted because it is immutable by design

This makes it difficult for malicious actors to modify or delete the data

A malicious actor would have to hack the Blockchain on every Server to modify the data

The Blockchain is Immutable atkrypto.io

The Blockchain Concensus Mechanism

To add a new row of data to the Blockchain, a majority of the Blockchain Servers in the Blockchain have to agree (concede) that the data can be added to the chain – this is known as the Concensus Mechanism

Getting concensus among Blockchain Servers makes it extremely difficult for Hackers to maliciously attack the Blockchain because to attack the Blockchain the Hacker will need to be trusted by a majority of the Blockchain Servers in the Blockchain

The Blockchain Consensus Mechanism atkrypto.io

And this is why, and this is the key here, the key difference between Blockchain Databases and the previous generation of Databases, Blockchain Databases, natively, out of the box, have a level of security and availability resilience built in which is not there in the previous generation of databases.

With the Blockchain Database you have the High Availability and Disaster Recovery built in, you have your Business Continuity Plan built in, and not only because of the availability resilience but also because of the immutability of the data.

This is why Blockchain Database Technology is so exciting for SAP Customers, we can get rid of layers of security hardening and have all of these layers taken care of natively out of the box in one product.

And we can do it today, it is no longer just hype, there are products in the SAP Partner Edge Open EcoSystem which can enable SAP Customers to do Blockchain and leveraging their existing investments in the SAP BTP, and running Blockchain in the SAP BTP on the SAP BTP Kyma Runtime.

Let's pause and take a breath, have a cup of tea or a cup of coffee, and then let's move to next objective of this blog...

UseCases, how Blockchain can solve existing challenges and enable re-imagining of business processes

There are loads and loads of use cases for Blockchain, and people have been writing for years about the Enterprise Blockchain use cases and benefits. a quick search on google will lead you to years of articles about the benefits of Blockchain and the use cases.

What I am going to do here is list a few of them as headlines across the dimensions of Securing the Integrity and Originality of Data, enabling Data Sharing and Orchestration and Multi-Party Collaboration, and Resilience and Business Continuity, and in the subsequent Blogs I will deep dive into the use cases and Technologies both from SAP and from SAP Partner Edge OpenEcoSystem partners which you can already leverage today to implement these solutions and do these use cases in your Enterprises.

Enterprise Blockchain Use Cases for Protecting/Security the Integrity and Originality and Confidentiality of Data:

. Track and Trace across all Industries and Business Processes, Single Party & Multi Party

. Finance & Insurance Business Processes, Single Party & Multi Party

. ESG - proving that what happened did happen and the evidence cannot be manipulated

Enterprise Blockchain Use Cases for Data Sharing and Orchestration and Multi-Party Collaboration:

This is a really interesting one for the Blockchain, this is where McKinsey & Company, in their December 2023 Featured Insights Publication, really nailed it with, "Blockchain is a secure database shared across a network of participants, where up-to-date information is available to all participants at the same time".

Just think about that. Think about how Blockchain could be used as an irrefutable common store of data, across your Enterprise, or across Enterprises.

Imagine running Blockchain on SAP Edge Lifecycle Management, or between the SAP Integration Cell and instances SAP BTP CI.

We all know, as the number of parties involved in a transaction goes up, so the trust in the transaction goes down.

Just think about how in Business Process and Business Scenarios where the same data is shared between multiple Teams in your Enterprise, or multi Enterprises in a Business Transaction or Process, just think about how the Blockchain and its special native out of the box characteristics will enable everybody to trust the information they are sharing and working with.

And then think about how Blockchain could be used to orchestrate data, to communicate data, to share data.

Imagine you have to give an instruction to a third party and you want to be the most certain that you can be that nobody with bad intentions can manipulate the instruction... you set up a Blockchain between you and your Partner and you write the data to the Blockchain and let the Partner read the data from the Blockchain.

Blockchain Muiti Party Collaboration atkrypto.io

Enterprise Blockchain Use Cases for Resilience and Business Continuity:

This one is a really interesting Blockchain Use Case. All of the SAP Technical Architects out there take note, Blockchain can today, using Blockchain products within the SAP Partner Edge Open EcoSystem solve your BCP challenges.

In all of our Enterprises we have the Business Continuity Plan.

The Business Continuity Plan leverages technologies to ensure that in the event of a BCP situation the Business can continue to operate to some extent.

To be able to operate most Businesses to some extent, there needs to be Data, certain core Master and Transactional Data to enable the Business to keep running.

As SAP Technical Architects our job is to design Technical Solutions which will enable the BCP scenario.

The basis requirements for the BCP scenario are:

. Store the core Data somewhere where it will be available for a BCP scenario

. Make sure that the core Data cannot be modified, make sure we can trust the core Data

And this again is where the Blockchain shows its beauty. Thanks to the dimensions and characteristics of the Blockchain which were described above, it's Immutable, tick that box for BCP, it's Distributed and Decentralised, tick that box for BCP, all we have to do as SAP Technical Architects is set up a Blockchain and write the most important BCP data to the Blockchain. We could set up a Blockchain Server on the SAP BTP Kyma RunTime Service in three continents in three SAP BTP Regions, connect that Blockchain to our S/4HANA, write the data to the Blockchain, and voila, we have our BCP.

Blockchain for BCP Business Continuity Planning atkrypto.io

If you've got this far, good job, now we are on to the last section which will be a shorter one 🙂

How Blockchain and SAP is no longer just a dream, just a hype, but how you can start doing Blockchain and SAP today solve old challenges with new(er) technology

I've been interested in Blockchain for the Enterprise since about 2018. As a career SAP Basis and SAP Technical Architect, when I started looking at Blockchain, I wanted to play with it, and I wanted to set one up, connect it to our R/3's and the, back then, new S/4HANA, and see what we could do with it. My expectation was that it would be like, download the software, self extract it, run it, do a few configurations and then integrate it and bring data in to it. All of the Blockchains for Enterprise which I looked at back then were extremely complicated, it was like a University Project to try to figure out all of the pieces of the puzzle that were needed to get it running.

6 years later, times have changed, the Blockchain technology is on its journey and maturing, and now, there are Blockchain products which SAP Customers can implement today, and which are coming from the SAP Partner Edge Open EcoSystem partners and are designed for the needs of SAP Customers and to leverage existing SAP investments and run on SAP BTP Kyma Runtime and consequently natively integrate with SAP data sources, S/4HANA and the SAP Cloud Products and integrating through the common SAP integration channels, SAP CI, SAP APIM, SAP AEM etc.

So what are we all waiting for ?

Ok, that's the end of this blog. This blog is the first of many, you will be seeing a lot more SAP and Blockchain blogs coming from me, explaining how implement the Blockchain software within your SAP investment and talking about all of the SAP Enterprise Blockchain use cases and business cases.

What do you think, are the words Blockchain, Web3, Distributed Ledger Technology, starting to appear in your Company's visions and technology visions ? What use cases are you looking at ? Let's chat about it in the comments.

For today, over and out. 🚀

Andy Silvey.

Independent SAP Technical Architect and CEO of atkrypto.io

Author Bio:

Andy Silvey is a 25 years SAP Technology veteran [15 years SAP Basis and 10 years SAP Tech Arch including Tech, Integration, Security, Data from 3.1H to S/4HANA PCE on RISE and the BTP and everything in between, and former SCN Moderator and Mentor alumni].

Andy is also co-Founder of atkrypto inc, an startup whose ambition is to make Blockchain easy for Enterprise.

atkrypto.io's flagship product is the atkrypto Enterprise Blockchain Platform for SAP, and atkrypto.io is a SAP Partner Edge Open EcoSystem Partner.

The atkrypto Enterprise Blockchain Platform for SAP has been designed by SAP Independent Experts for the needs of SAP Customers and to be deployed on the SAP BTP Kyma Runtime Service and leverage native integration to SAP Products.

atkrypto Enterprise Blockchain Platform for SAP has a number of unique qualities, including being the only Blockchain software in the world which has a DataCenter version and a light mobile version which can run on Edge/IoT/Mobile devices and enables data to be written to the Blockchain at the Edge where that same Blockchain is running on a Server in the DataCenter, protecting the integrity and originality of data from the Edge to Insights. Taking Blockchain to the Data at the Edge instead of taking the Data to the Blockchain.

SAP Cloud Integration: Understanding the XML Encryption Standard

2024-03-07T15:16:11.555000+01:00

SAP Cloud Integration doesn’t offer an encryptor step for encrypting XML content according to the "XML Encryption" standard. That standard provides some benefits and flexibility specifically for xml content.
This article is intended to introduce into the "XML Encryption" standard, as preparation for future hands-on.
I'm trying to explain everything simple, with my simple understanding and my simple words - this is not a professional article.
In this blog post, I will try to answer many questions and show examples.
The next blog post shows how we can encrypt / decrypt XML payloads, according to the XML-Enc spec, manually in a Groovy script.

Overview

Historical Intro
Theoretical Intro
XML Sample Intro
Optional Outro

History

How I imagine that it started:
Timmy from Texas wanted to share some secret info with his friend Taku in Tokyo.
So he encrypted a message and sent it to Taku.
Taku was unable to decrypt and read the message.
So Timmy travelled to Tokyo to enjoy some food and to explain the way how he encrypts and packages his messages.
Afterwards, Taku in Tokyo was able to decrypt and read all messages (even before breakfast).
Some time later, same situation happened with his friend Toto in Togo.
Although the food is said to be great, Timmy decided not to travel, but to invite his friends for a conference at home.
They had international food, late-night discussions and at the end, they agreed on a common way of sending secure messages.
As a consequence, everybody in the world can send secure messages and the recipients can understand the message, as long as they follow that agreement.

Does that make sense?
Really makes sense, especially the section about the international food (which didn’t make it into the specification).

What do we learn from this story?
People communicating with each other need to agree on some basic principles:
- how encryption is done, which steps in which order
- what exactly is encrypted
- which algorithms are used
- certificate information
- where is that information stored

This intro was copied from my cms-post.

Introduction

We’re talking about sending data from somewhere to anywhere over the internet.
Instead of writing a letter, we use XML to structure the data which we send.
As we know that the internet is dangerous, we want to encrypt the data.

There are blogs out there?
Sure, we already have so fantastic blog posts like this one together with the intro blog.
It explains how to use the CMS standard for encrypting a message.

So why do we need this blog?
Actually, the CMS standard is not specific to any kind of payload, so it could be used for XML as well, why not.
But...
But we need this blog post because it is specific to XML payload.
As the message is written in XML, we can take advantage of the fact that the content is structured already.
This is a benefit.
So we have an extra standard.

OK. What is the benefit?
As we’re dealing with xml, which is a structured content, we have the advantage of choosing which content or part of content we want to encrypt.

Cool. Which content can we choose?
There are 3 possibilities:

Encrypt the whole document, i.e. the whole file or the entire message
Encrypt part of the document: choose one node of the XML document.
In this case, the node itself is not encrypted, but only the content below the node.
Means, the text content of the node is sensitive, but the node name is left as plain text
The content can be a subtree of child nodes as well.
Encrypt part of the document: again, choose one node of the XML document.
But in this case, the node itself is encrypted as well, along with all of it content.

Variant 1…?
Ummmmm - yes, it is similar as CMS....
AHA
Ehm, yes, here the benefit is less obvious, but nevertheless, the result is an XML with a specific structure, which can be understood by XML-Enc-aware tools.

Don’t understand.
Remember the funny history story?
At the end, a standard is an “agreement” between sender and receiver.
If they both adhere to the agreement, they can send and receive, encrypt and decrypt without trouble.
So even in case of variant 1, the receiver can find the info about how to decrypt, by reading XML.

What is the XML-agreement?
Basically, in case of "XML Encryption" agreement, the receiver knows where to find the information that he needs for decrypting:

The incoming XML contains a node <EncryptedData> which contains everything: the encrypted content and metadata.
There’s the info about which variant (see above) was used
The subtree of this node contains info about the algorithm used to encrypt the content
The subtree contains info about the key that was used to encrypt the content
The encrypted key itself
The encrypted content itself
. . .

Note that the standard is flexible and there are multiple ways to apply it.
In this blog post we’re sticking to one variant which is common and safe and makes sense.

How is encryption done?
During encryption, the sensitive content is replaced by an <EncryptedData> node.
The subtree of <EncryptedData> contains the sensitive content that has to be secured, in non-understandable way, i.e. encrypted.
After encryption, the result is encoded with Base 64, (this is common practice when sending data over the internet).

How is it encrypted?
We have to understand the 2 basic ways of encrypting:
Symmetric and asymmetric encryption

What is symmetric encryption?
Sounds normal: some content is encrypted with a key.
For decryption, the SAME key is used.
Means, the key must be handed over to the recipient in a safe way.
This is a disadvantage.
The advantage: fast and can handle big-sized content.

And asymmetric?
To avoid the problem of having to transmit the secret key:
Here we have 2 keys, which belong together: private and public keys.
This is called a key pair.
The public key is not secret, it can be sent to the encryptor.
The content is encrypted with the public key.
ONLY the private key can then decrypt the content.
Advantage: more secure.
Disadvantage: not applicable to big payloads and slow.

So both are unusable?
There's a solution: use both in a hybrid mode.
Use symmetric key to encrypt the (big) content.
Use asymmetric key to encrypt the (small) symmetric key.
That’s it.
The symmetric key can be safely sent together with the encrypted content.
Because the symmetric key is securely encrypted.
The receiver can decrypt the symmetric key, (because he has the private asymmetric key).
Then use the symmetric key to decrypt the content.

Confusing...
Let’s repeat:
We want to encrypt sensitive content
-> we use a “Content Encryption Key” == CEK
-> also called “Data Encryption KEY” == DEK
This key has to be encrypted with another key.
-> We use a “Key Encryption Key” == KEK

Why can't we just use the KEK to encrypt the message?
As mentioned, because KEK is asymmetric and thus not suitable for big content.

Ah, already forgot
No prob.

What is a key?
What we want to achieve is to hide secret content from someone but reveal it to us.
We want to make it look random, but be able to revert.
Thus we need to use a key, so we are able to revert.
Note:
A key can be just a sequence of bits, but longer key length ( key size) is more safe.

What is a DEK or CEK?
Data Encryption Key or Content Encryption Key.
This is a symmetric key for encrypting the payload content.

What is a KEK?
Key Encryption Key, this is usually an asymmetric key.
Also referred to as “Key Transport”.

How is encryption done?
Think about a rule, e.g. replace every ‘a’ with a ‘b’
Such rule is called “algorithm” or “cipher”.
To make the process reversible, a key is applied.
This makes it reversible only for the key owner.

Examples for symmetric algorithms?
AES, DES (not safe!), TDES (== Triple DES == 3DES == DESede), RC4 (etc, not safe)

Examples for asymmetric algorithms?
RSA, DSA, ECC

What is AES?
It stands for Advanced Encryption Standard.
It is a symmetric-key algorithm.
It works on blocks with size 128 bits.
It supports keys with sizes 128, 192 and 256 bits.

What is a Block Cipher?
In symmetric cryptography, 2 ways are used: block and stream ciphers.
In case of stream, the input is encrypted byte by byte.
In case of block, the content is cut into blocks, which are then encrypted.

What is block size?
The size of such blocks.
AES always operates on blocks of 128 bits.

What is padding?
Assume we have some content which has to be encrypted with AES.
Obviously, it is larger than 128 bits, or a multiple.
Which is the size of a block.
After cutting the content into blocks of 128 bits, there will be a remaining rest.
The rest has to be filled up until 128 is reached.
That’s what we call padding.

What is operation mode?
Assuming again, the content which has to be encrypted is larger than 128 bits.
So it is cut into multiple blocks.
Encryption will be applied to many blocks individually.
The way how this is done, will help to make the encryption more safe.
At the end we want a result that looks completely crazy (= random bytes).
Therefore, we can choose an encryption mode (= operation mode).
Examples:
ECB, Electronic Code Block, unsafe.
Note that ECB is often used as default, if no operation mode is specified.
So the recommendation is to always specify a secure operation mode.
CBC, Cipher Block Chaining, not recommended.
CTR, Counter
GCM, Galois Counter Mode, recommended.

Can we find an end?
We’ve talked about the XML structure and the encryption process.
Now we’ve found the end:
->here

Can we look at an example?
The next chapter is full of xml.

Sample XML

Let’s view a simplified example.
We have a Sales Service that sends info about an order:

Order number
Product Identifier
Customer info
Payment: credit card number
. . .

The service sends the payload in XML format.
XML is tedious to read, so trying to simplify:

We can quickly identify a security risk:
Sending credit card number via the internet is not acceptable.

So we could encrypt the number and send the XML as below:

However, it is better to stick to the XML Encryption standard:

The next screenshot below shows that the content of a node has been replaced with the <EncryptedData> subtree (simplified).
Remember the 3 variants above? So this is the second:
only the content is encrypted, not the whole element + content.
With other words: the credit card number is unreadable, but the <CreditCard> node is still readable.

Next screenshot shows the final result XML structure:

The last screenshot shows the final result:

What we can see:

The top level <EncryptedData> node has 3 children
- EncryptedData
--- EncryptionMethod
--- KeyInfo
--- CipherData

Explanation

🔸EncryptionMethod
This is the information about how the content was encrypted.
In our example, the symmetric cipher AES was used with a key size of 256 bits and operation mode GCM.

🔸CipherData
The result of encrypting plain text is called “ciphertext” and it is stored below this node.
Note that the cipher text is base64-encoded.

🔸KeyInfo
In our example, we chose to encrypt the symmetric key.
The <KeyInfo> node carries the information about this symmetric key
(Remember, this is the key that was used to encrypt the content).
The <KeyInfo> has the following children:
- KeyInfo
---- EncryptedKey
------- EncryptionMethod
------- CipherData

In our case, it contains the encrypted key itself and the method that was used for encryption.
Example: We use an RSA public key for encrypting the DEK, so the <EncryptionMethod> node will contain something with “…rsa…”

Note:
The algorithms are specified via URI, e.g.

<xenc:EncryptionMethod Algorithm=http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p />

We can see the nice little namespace xenc
I like this one 😁
It is specified at top level node:

<xenc:EncryptedData xmlns:xenc=http://www.w3.org/2001/04/xmlenc#

OK.
Let’s add one more last screenshot, where we can compare the XML payload before and after encryption:

Note:
The receiver has to know which variant was used:
If the only the content was encrypted, or the whole element.
This is specified in the “Type” attribute of the top-level element:

<xenc:EncryptedData Type=http://www.w3.org/2001/04/xmlenc#Content
or
<xenc:EncryptedData Type=http://www.w3.org/2001/04/xmlenc#Element

And here comes one last (really last) screenshot, showing the result of encrypting with the variant 3, which is of Type ...xmlenc#Element:

In above screenshot we can see that the <CreditCard> node has disappeared.
The node itself has been replaced with the <EncryptedData> node.
In the groovy script below, we’ll see the flag that decides upon the type.

Optional Info

The “XML Encryption” is also called “XML-Enc”.
It is a standard that is specified as a W3C Recommendation.
It is owned by the World Wide Web Consortium aka W3C.
The W3C owns most standards related to the World Wide Web.
The current version 1.1 of the specification for XML Encryption Syntax and Processing is from 2013.
It can be found here: https://www.w3.org/TR/xmlenc-core1/

Implementations of the standard are available for C, C++ and Java.
The Java implementation is used in our next blog post.

Summary

The XML Enc specification describes how to flexibly encrypt parts of an XML document.
(Or the whole).
The sensitive xml-section is replaced by a new <EncryptedData> section.
This xml-tree contains the encrypted content and metadata (method, key, etc)
The spec is flexible and open, but the common process of encryption would be:
▶️ Generate a symmetric key on the fly.
▶️ Encrypt the content with it.
▶️ Encrypt the symmetric key with an asymmetric key.

Next Steps

Go through the tutorial in the next blog post to gain hands-on experience.

Links

W3C recommendation XML Encryption Syntax and Processing V 1.1
Apache Santuario
Understanding CMS (PKCS 7) standard.
Security Glossary Blog

🌵

SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard 🚀

2024-03-08T19:19:41.200000+01:00

This blog, which follows on from the previous one in the series, "Why I love SAP and Blockchain Databases and why you should too 🚀", will deliver an approach to positioning Blockchain Technology as a Technology Standard in our Companies.

The goal of the previous blog in this series was to get us thinking about Blockchain Databases in our Companies, in the Enterprise, and the goal of this blog is to get us thinking about how to position an Enterprise Blockchain Platform as a Technology Standard in our SAP Enterprise Architecture.

Why do we need to do this ? Why does Blockchain need to be a Technology Standard within the Enterprise Architecture in our Companies ?

In our SAP Enterprise Architecture we use Technology Standards as a way of framing where we use what software applications and why, what is the purpose of that software application.

So for each Technology that we have in the house, we have a box which describes what that Technology and do, what it's strengths are, and therefore where we should use it.

This all sounds very formal, but in our personal lives we do this at home every day. We possibly have more than one pair of shoes, perhaps one pair for going to the office and one pair for going running. I don't really want to get in to a debate about how many pairs of shoes people have and which ones they use for what but I imagine that you get the point.

Some shoes are more suited to different activities than others. Some have a hard sole some have a soft sole. These are capabilities of the shoe, soft sole leans towards capability for sport, thanks to this soft sole capability the shoe is more appropriate to be used for, to be applied to sport, You get the point.

And it's the same with software, some software is more suited to different activities than others, these are capabilities. And by keeping a list of what software we have in the company and what the capabilities of the software are, and where the software is encouraged to be used, helps to ensure that in our SAP Enterprise Architecture decision making processes we more consistently use the different types of software that we have for the purposes in which they are intended based upon what they can do.

To be more formal, there is a very nice description of Technology Standards here, 'At the most basic level, technology standards establish boundaries for technology usage, specifying technology to be used (acceptable use) and restricting access to technology that is deemed "non-standard"'.

If we agree that to be able to consistently, repeatedly use Enterprise Blockchain Databases in our Companies we need to classify where we should use the Enterprise Blockchain Databases and why, then the first step is to write down all of the things that Enterprise Blockchain Databases is good for, what it can do, where it is strong, what the capabilities are.

Capabilities means what is it good for what is it good at ? What can it do ? Let's try to group the capabilities together where it makes sense. The most important capabilities and enablers of Enterprise Blockchain Databases and on a wider scale the Enterprise Blockchain Platforms, from the high level view, revolve around Data across the dimensions of:

Security / Privacy

Availability / Resilience

Collaboration / Sharing

Orchestration

Web3 / Tokenization / Wallet / SDK / Smart Contracts

Mobility / Edge

Integrations / Connectivity / Blockchain Bridges and Bridging

Types of Blockchain

Artificial Intelligence

Let's go through these capabilities one by one and think of all of the words we can around the dimension and picture what it actually means.

Enterprise Blockchain Database Capability - Security & Privacy

Capability/Enabler: Secure, Immutable, Trust, Cannot be modified, Tamperproof, Protect, Safe, Proof, Auditable, Confidentiality, Integrity, Originality, Transparency, Privacy

Why are Blockchain Databases so strong in this: As we discussed in the previous Blog in this series, Blockchain Databases have four special characteristics that make them a Blockchain Database, and those are, Immutable, Hash Mechanism, Distributed/Decentralised, Consensus Mechanism.

Regarding the Security & Privacy capability, it is the Immutable and Hash Mechanism and Consensus Mechanism which make the Blockchain Database so natively security hardened out of the box and in fact security hardened natively out of the box to a level which most conventional databases are not.

In terms of the NIST CIA Triad for Data Security, Criticality, Integrity, Availability, Enterprise Blockchain Databases comes in Very High across all three classifications.

Blockchain Security SAP NIST Triad atkrypto.io

Enterprise Blockchain Database Capability - Availability & Resilience

Capability/Enabler: Resilience, Distributed Multi Region, Distributed, Decentralised, Network Database, High Availability, Disaster Recovery, Business Continuity Planning

Why are Blockchain Databases so strong in this: Again, as we discussed in the previous Blog in this series, Blockchain Databases have four special characteristics that make them a Blockchain Database, and those are, Immutable, Hash Mechanism, Distributed/Decentralised, Consensus Mechanism.

Regarding the Availability & Resilience capability, it is the Distributed & Decentralised characteristics which make the Blockchain Database so natively resilient out of the box and in fact resilient natively out of the box to a level which most conventional databases are not.

An Enterprise Blockchain Database is a Network Database. When one of the Servers is down, the other Servers are up, A Server can go down and when it comes back up it will automatically synchronise with the rest of the Enterprise Blockchain Database Network. This is really suited to Business Continuity Planning.

Blockchain for BCP Business Continuity Planning atkrypto.io

Enterprise Blockchain Database Capability - Collaboration / Sharing

Capability/Enabler: Single Source of Truth, Shared Single Source of Truth, Multi-Party Collaboration, 3rd Party Collaboration, Common Store of Data, Sharing, Collaboration, Master Data Store, Distributed Data, Network Database, Track and Trace, Traceability, Audit, Auditability

Regarding the Collaboration / Sharing capability, it is the Distributed & Decentralised characteristics which make the Blockchain Database so natively supporting Collaboration / Sharing out of the box and in fact supporting Collaboration / Sharing natively out of the box to a level which most conventional databases do not and can not, without additonal Clustering and Networking software.

An Enterprise Blockchain Database is a Network Database. This means the Database is running active on multiple Servers in multiple locations. As was described in the previous blog, McKinsey & Company, in their December 2023 Featured Insights Publication, gave a beautiful description of what is unique and special about Blockchain, "Blockchain is a secure database shared across a network of participants, where up-to-date information is available to all participants at the same time".

And this is what is so important and so special. When we install the Blockchain Database Server in two different Company's DataCenters (or as Blockchain as a Service in the Cloud) and establish a Database Ledger on the Servers we enable the two Company's to share Master and Transactional Data while knowing that neither can modify the Data which has been shared. This is really suited to sharing Data across the Enterprise or across Enterprises.

Blockchain as a Shared Single Source of Truth atkrypto.io

Enterprise Blockchain Database Capability - Orchestration

Capability/Enabler: Data Orchestration, Data Integration, Network Database, Instructions Communication, Data Delivery, Sending Data, Data Transfer, Data Connection

Regarding the Data Orchestration, it is again the Distributed & Decentralised characteristics which make the Blockchain Database so natively supporting Data Orchestration out of the box and in fact supporting Data Orchestration natively out of the box to a level which most conventional databases do not and can not, without additonal Clustering and Networking software and all of the extra effort that that brings. An Enterprise Blockchain Database is a Network Database.

This means the Database is running active on multiple Servers in multiple locations. As was described in the previous blog, McKinsey & Company, in their December 2023 Featured Insights Publication, gave a beautiful description of what is unique and special about Blockchain, "Blockchain is a secure database shared across a network of participants, where up-to-date information is available to all participants at the same time". And this is what is so important and so special.

When we install the Blockchain Database Server in two different locations / DataCenters (or as Blockchain as a Service in the Cloud) and establish a Blockchain Database Ledger on the two or more locations' Servers we enable a situation where one Datacenter can put data onto the Blockchain, which is in fact an instruction for an action from an Application which is reading from the Blockchain in the other Datacenter. What this leads to is Data Integration at a level which is not possible with End to End Encryption and Encryption of Data at Rest alone.

Today Companies send Data to each other, with Blockchain Companies will write to and read from the same Blockchain Database Table. This is really suited to Orchestrating Data across the Enterprise or across Enterprises. In the following example we see how instructions to a Third Party Logistics company can be orchestrated across the Enterprise Blockchain running between the two companies.

SAP Master Data Integration and Orchestration with Blockchain atkrypto.io

Enterprise Blockchain Database Capability - Web3 / Tokenization / Wallet / SDK / Smart Contracts

Capability/Enabler: Web3 Foundation, Digital Asset Tokenization, Digital Wallet, Software Development Kit, Smart Contracts, Business Logic, Extension, Programming, Customisation

Tokenization is a combination of all of the Blockchain characteristics in one. Tokenization is the action of creating a Block on the Blockchain which is a Digital Token. The Digital Token is the digital representation of the information which has been stored on to the Blockchain.

With Tokenization comes a Wallet to store the Tokens in, it can be argued that the Wallet is not a classic capability of the Blockchain, but rather a capability of the Blockchain Platform.

A Software Development Kit is also not a classical characteristic or capability of the Blockchain, but rather a capability of the Enterprise Blockchain Platform. The SDK enables Developers to develop Decentralized Applications which run on top of the Blockchain.

And Web3 is the culmination or the whole of all of these capabilities and some more. The capabilities listed here go a long way to making up the core foundation of Web3. There is a nice overview of Web3 here in the SAP Community, including the following drawing:

Enterprise Blockchain Database Capability - Mobility / Edge

Capability/Enabler: Mobile, Mobility, Edge, IoT, Wireless, Move, Industry 4.0, Smart Everything, Connected Everything

The Distributed/Decentralised characteristic of the Blockchain Database Technology is what is so special here. As discussed above the Distributed characteristic of the Blockchain enables us to have a database which is networked between two locations.

It's this network database, and another fact which make Blockchain Databases so interesting for Edge/IoT/Mobile.

The other fact is the anologue to digital transformation of Things and the network getting closer to the Things at the Edge.

In the past Data was pretty much centralised to the DataCenter.

Things like Thermometers (in Pharmaceutical and Food Production), Maps & Compasses in Delivery Vehicles, Instructions on Paper, Locks on Doors, Photographs and Video, all of these Things were analogue. And now, all of these Things are going through a digital transformation, in two aspects, they are able to create digital representation of facts, and they are connected to the Network, and in some cases they even have larger computational power and can do business/processing logic and therefore are Smart Things. Thermometers are now connected to the Network, same for Maps and Compasses in Delivery Vehicles (GPS Location and navigation), Paper based Instructions are now electronic, Locks on Doors are now electronically monitored and controlled from the Network, Photographs and Video are now digital and connected to the network. And all of things Things are connected to the Network,the Edge of the Network, because they are the final point of the Network and together they make up the Internet of Things.

And so all of these Things are producing Data at the Edge of the Network. And this is where Blockchain comes in, Blockchain, for all of the reasons above is natively out of the box the most security hardened and resilient Database for protecting the integrity and confidentiality and originality of Data from the Edge.

The Capability and Enabler, Mobile / Edge / IoT comes in to play regarding having a Enterprise Blockchain Platform Server Node as close to the Edge as there is computational power, eg, on the Device, in the Connected Vehicle, or in the 5G Network IoT Gateway.

Do we take the Data from the Edge to the Blockchain or do we take the Blockchain to the Data at the Edge.

The most elegant is to take the Blockchain Mobile and to the Data at the Edge.

Surely the most secure way, is to protect the originality, integrity, confidentiality of the Data, at the Source, at the Edge, or as close to the Source as there is enough computational power to run a light Blockchain Database Server Node ? We will discuss this in detail in subsequent blogs.

Enterprise Blockchain SAP IoT Edge Mobile Vehicle to Insights Connected Everything atkrypto.io

Enterprise Blockchain Database Capability - Integrations / Connectivity / Blockchain Bridges and Bridging

Capability/Enabler: Integration, Integrator, Connection, Connectivity, Connector, Bridge, Blockchain Bridge, Bridging

This capability mainly revolves around the Distributed/Decentralised characteristic of the Blockchain.

This capability has a several different dimensions:

Getting Data in to the Blockchain

There are basically two clear leading options for getting Data in to the Enterprise Blockchain Platform, and those are:

API's

API's, there is nothing wrong with API's and there must always be API access to the Blockchain, for writing and for reading. For writing I see the API as more reactive than real time, and for reading data from the Blockchain API is the obvious choice.

There is a very nice blog in the SAP Community which favours Events over API's and personally I also lean that way for the majority of cases for writing data to the Blockchain. The blog is here: APIs: our flawed legacy from 1960’s thinking.[thanks to my friend Thomas Kaiser for finding that one]

Events

For me the biggest reason for using the Enterprise Blockchain Platform is the incredibly high level of security hardening and Data protection that it natively brings.

If we agree we will be more often positioning the Enterprise Blockchain Platform because of its security strengths, then next dimension is to write Data to the Enterprise Blockchain Platform as close to the source of that Data as possible no matter where the Data is, Edge or DataCenter.

The next dimension is that in the majority of cases, we will want to write the Data to the Enterprise Blockchain Platform as early as we can in the lifetime of the Data, ie, as soon as the Data was created.

If we want to write Data to an Enterprise Blockchain Platform as soon as the Data is created then the obvious technology for getting the Data to the Enterprise Blockchain Platform is Events, Event Driven Blockchain. I will be discussing this in detail in the later blogs which will deep dive in to individual use cases and reference architecture.

The Blockchain as a Data Integrator across the Organisation or Organisations

This capability crosses over with the Data Sharing capability. Basically the Enterprise Blockchain Platform becomes a Data Integrator within the Enterprise.

In a number of use cases the Enterprise Blockchain Platform could replace classical API based Integrations. In scenarios where there are Data Integrations between Applications, for example between Salesforce and SAP S/4HANA, instead of doing an API based Integration and only have security and protection to the level End to End Encryption, there could be an Enterprise Blockchain where Salesforce writes to the Enterprise Blockchain and SAP S/4HANA reads from the Enterprise Blockchain. This will be discussed in subsequent blogs which will deep dive in to use cases and reference architecture.

Bridging between Blockchains

This is a very important capability of Enterprise Blockchain Platforms and enables that Data can be bridged between Blockchains.

SAP S4HANA BTP Blockchain Web3 Reference Architecture Example atkrypto.io

Enterprise Blockchain Database Capability - Types of Blockchain

Capability/Enabler: Public, Private, Semi-Private, Consortium, Bridge

This capability mainly revolves around Layer 0 of the Blockchain Architecture, which is the Blockchain Network. An Enterprise Blockchain Platform which enables the Customer to create their own Blockchain Network will most likely have the best capability to enable the Customer create the Blockchain of their choice.

The main classifications of Blockchain Database are nicely described in this article from SAP, What is blockchain technology?.

SAP Article What is Blockchain Types of Blockchains atkrypto.io

Enterprise Blockchain Database Capability - Artificial Intelligence

Capability/Enabler: Integrity, Auditability, Traceability, Originality, Confidentiality, Protection, Safe, Treasure, Surety, Certainty, UnCompromised, Intelligent Technologies, Smart Technologies

This capability mainly revolves around Security characteristics of the Blockchain Platform and Database.

For Artificial Intelligence outcomes to be trustworthy, it must be certain that the Data used for the Artificial Intelligence can not have been altered.

That's it, it's as simple as that, if we want to trust what AI is telling us, then we need surety and certainty that the integrity and originality of the Data which the AI used cannot be or have been compromised.

Intelligent Technologies, for Intelligent Technologies to be intelligent, they cannot depend on stupid Data !

Smart Technologies, for Smart Technologies to be smart, they cannot depend on stupid Data !

That's where the Blockchain comes in.

SAP What is an Intelligent Sustainable Enterprise atkrypto.io

Now that we have elaborated on all of the capabilities and enablers of Enterprise Blockchain Databases and Enterprise Blockchain Platforms, let's get back to the goal of positioning Enterprise Blockchain Database and Platform as an Enterprise Technology Standard.

Before we do that, let's recap on the capabilities and enablers and summarise them:

Enterprise Blockchain Platform Capability Layers Map courtesy of Jan Tuma (TOGAF Certified SAP Enterprise Technical Architect) - atkrypto.io

In SAP Enterprise Architecture there is only one place to run the Enterprise Blockchain Platform, and that is, right next to the Digital Core S/4HANA in the "enabler", the SAP Business Technology Platform.

Why place the Enterprise Blockchain Platform in the SAP BTP ?

It's very very simple....

Proximity to the Data (of the Digital Core)

Ethnicity of the Data (in the Digital Core)

Proximity to the Process(es) (in the Digital Core)

Proximity to the Technology (of the Digital Core)

To wrap up, what we've done in this blog is identify all of the capabilities and enablers of Enterprise Blockchain Databases and the Enterprise Blockchain Platform, we've discussed why these capabilities are so important, and consequently how to position an Enterprise Blockchain Platform in the SAP Enterprise Architecture Technology Standards, where we use what and why.

We have also looked at where the Enterprise Blockchain Platform should reside, and the conclusion is in the "enabler", the SAP Business Technology Platform BTP, right next to the Digital Core S/4HANA, and enabling and leveraging all of the other Services in the SAP BTP and the native integration to the SAP Product Portfolio and other Enterprise Applications.

The good news is, as we discussed in the previous blog, this is no longer hype, we can do all of this today, and now, within the SAP Partner Edge Open EcoSystem there are enabling technology Blockchain Products designed and built by SAP Experts specifically for the needs of SAP Customers to make doing Blockchain and SAP easy, and so you can do SAP and Blockchain, today it's real and there's nothing stopping you.

So what are we waiting for ? Oh yeah, use cases, ok, that will be the next blog 😀 🚀

For now, over and out.

Andy Silvey.

Independent SAP Technical Architect and CEO of atkrypto.io

Author Bio:

Andy is also co-Founder of atkrypto inc, an startup whose ambition is to make Blockchain easy for Enterprise.

atkrypto.io's flagship product is the atkrypto Enterprise Blockchain Platform for SAP, and atkrypto.io is a SAP Partner Edge Open EcoSystem Partner.

Master Derived role concept

2024-03-21T14:51:34.939000+01:00

Master role-It is parent role which has full access and contains org level values as *.

Derived role-It is a single role which is derived from another single role.

What is the necessity of a derived role?

->when the client is MNC--Coke, BMW, NESTLE

->Multiple business company-TATA

For Example-

Coke:

India finance team-India finance team will process the invoices of India.

USA finance team-USA finance team will process the invoices of USA.

t-code used to process the invoices is same FBV0.

In India when they will execute the FBV0, they should be able to process the invoices of India only.

In USA when they will execute the FBV0, they should be able to process the invoices of USA only.

This access can be differentiated with the ORG FIELDS. i.e. plant, cost Centre, company code.

In this diagram, three roles are derived from master role.

When you derive the roles from master role the t-codes, authorization objects will get derived as it is.

The only difference between master and derived role is ORG FIELD values. i.e. company code values in this example.

Here, we have created master role with company code value as * and we have derived derive role for India, USA,UK with company code value as 100,200,300.Suppose if we add a new t-code to master role and if we create derive role from it, it will push the t-code to India, USA, UK role, but it will not touch the company code value of derive roles. The company code value will remain as it is. That is the concept of Master and derive role.

If you want to add a new t-code FB01 in these three derived roles, then you need to add this t-code to master role and derived roles will get modified accordingly.

Q&A:

What is the difference between master and derived roles?

->org values.

How many derived roles can be derived from one master role? Is there any limit?

->No limit. It depends on how many branches or businesses the company has.

Regards,

Snehal

Custom domains for BTP CloudFoundry applications

2024-03-26T08:43:26.536000+01:00

Introduction

I wanted to activate a custom domain on BTP for my own website https://wouter.lemaire.tech . To achieve this I followed this great step-by-step blog post of @andrew_lunde : https://community.sap.com/t5/technology-blogs-by-sap/step-by-step-guide-to-custom-domains-with-multitenant-multi-target/ba-p/13390754

Nevertheless, I did some steps different which still made it challenging to configure:

I bought the domain using google domains
Used certbot instead of my own certificate (in companies you’ll probably have a company certificate)
Added MTA configuration to automatically map the domain after deploying your app

Those differences changed some steps in the flow which I documented and want to share in this blog post.

Prerequisites

Check the official SAP help documentation, this might help you to understand the flow: https://help.sap.com/docs/custom-domain/custom-domain-service/create-custom-domains?locale=en-US

You need to buy a custom domain, this is not part of this service. This service just allows you to use your custom domain (which you pay separately) to your BTP applications and services. I’m using google domains which has been migrated to Squarespace.

Install certbot: https://certbot.eff.org/instructions?ws=other&os=windows

Download the latest version of the Certbot installer for Windows at https://github.com/certbot/certbot/releases/latest/download/certbot-beta-installer-win_amd64_signed.exe.

Make sure your BTP account has the entitlements:

Create an instance of this service in your CloudFoundry Space:

Install the CloudFoundry CLI with the Custom Domain Self-Service plugin. The plugin can be downloaded from here: https://tools.hana.ondemand.com/#cloud

Once downloaded, install it by going into the folder of the plugin and run the following command in your cli: “cf install-plugin custom-domain-cli”

Validate if it was successful by running “cf plugins”. This will show you a list of all installed plugins including the custom domain plugin:

Create your custom domain

1) Login to CloudFoundry using the cli:

2) Create your custom domain using the command “cf create-domain wlcf wouter.lemaire.tech”

You can validate if this was successful with the command “cf domains”, here you should see your domain listed:

3) Create a private key for your custom domain in Cloud Foundry using the command:

cf custom-domain-create-key custom-domain-wouter-lemtech-key "CN=*.wouter.lemaire.tech, EMAIL=wouter@lemaire.tech, O=lemtech, C=BE" "wouter.lemaire.tech"

custom-domain-create-key: command for the cf cli custom domain plugin to create the key
custom-domain-wouter-lemtech-key: this is the name for the key that will be created. We need this in a later phase
“CN=*.wouter.lemaire.tech, EMAIL=wouter@lemaire.tech, O=lemtech, C=BE” : details need to create the CSR
"wouter.lemaire.tech": the domain name I want to connect (more can be listed here)

4) Get the Certificate Signing Request (CSR) by using the created private key using the following command:

cf custom-domain-get-csr custom-domain-wouter-lemtech-key csr.pem

custom-domain-get-csr: cf cli custom domain command to retrieve the csr
custom-domain-wouter-lemtech-key: name of the private key which was created in the previous step
csr.pem: name of that will be used to store the csr in

5) Sign the CSR using certbot by running cmd as administrator from the folder where the csr.pem file is stored and run the following command:

certbot certonly --manual --csr ./csr.pem --preferred-challenges dns

This will give you a token which you need to use to create a TXT record in Google Domains:

Once you created the record, you can press enter. This might take a while but eventually provide you some certificates:

6) Upload the signed certificate to CloudFoundry

As I received three certificates from certbot and it was not clear which one to take so I tried merging all of them into one:

When uploading the combined certificate using the following command, it went in error:

cf custom-domain-upload-certificate-chain custom-domain-wouter-lemtech-key allchain.pem

So I tried all certificates separately and eventually the last one worked 😊

cf custom-domain-upload-certificate-chain custom-domain-wouter-lemtech-key 0001_chain.pem

custom-domain-upload-certificate-chain: command to upload the certificate to CloudFoundry
custom-domain-wouter-lemtech-key : key that I created earlier
0001_chain.pem: certificate that needs to be uploaded

It will ask for confirmation and upload BUT not yet activate:

We can check if the certificate was uploaded successfully with the following command + the private key:

cf custom-domain-show-certificates custom-domain-wouter-lemtech-key

7) Activate the custom domain using the following command:

cf custom-domain-activate custom-domain-wouter-lemtech-key wouter.lemaire.tech

custom-domain-activate: command for activating
custom-domain-wouter-lemtech-key: private key name
wouter.lemaire.tech: domain to be activated

You can check if the active custom domains in CloudFoundry with the command: cf custom-domain-list

In my case, I have two, one main custom domain which I’ll use to continue “Wouter.lemaire.tech” but also a generic domain that allows me to use subdomains “*.wouter.lemaire.tech”. I’ll use this one later.

8 ) Configure DNS for custom domain

Before we can do this, we need to get the API of CloudFoundry in your subaccount. This can be done by using the command “cf api”:

In Google Domains, I created the following record:

To test if it works I used the command “nslookup Wouter.lemaire.tech”:

9) Map application to custom domain

Before we do, we can check the list of apps to find the connected route for each application

With the following command, we will map an app with the custom domain we created (this needs to be done for the approuter app as this is the access point for an application in BTP):

cf map-route <Application Name> <Custom Domain> --hostname <Application Hostname>

In my example it looks like this, without the hostname as I want it to be connected with the main domain:

cf map-route lemtech-approuter wouter.lemaire.tech

If you now check the list of apps, you’ll see that the route for the approuter is connected to the custom domain:

You can also check the list of routes:

10) Configure the MTA of your app

After every deploy the mapping between the route and your app will be gone and you need to do this over again. This can be done in the BTP Cockpit:

You can avoid this by configuring the domain in the mta.yaml file of your application as followed:

With this configuration you’ll keep the domain connected to your application after each deploy

That’s how it’s done 😊

Result

Try navigating to https://wouter.lemaire.tech this will open my website which is running on SAP BTP Cloud Foundry!

Additional

Additionally I’m also want to create subdomains so I can use the custom domain for other applications. For this, I added a record in google domains as followed:

I have activated the custom domain “*.wouter.lemaire.tech”

Mapped the application BTP Service Overview with the custom domain Wouter.lemaire.tech using btp-services as hostname:

Result: https://btp-services.wouter.lemaire.tech/

Integrating IBM Security Verify with SAP Cloud Identity Services in SAP BTP

2024-04-02T10:29:43.856000+02:00

This blog delves into the technical aspects of integrating IBM Security Verify with SAP Cloud Identity Services (CIS) in SAP Business Technology Platform (BTP) as a proxy.

SAP CIS offers a suite of solutions for managing user identities, access controls, and application integrations across the IT landscape. Conversely, IBM Security Verify provides identity governance, workforce and Customer Identity Access Management (CIAM), and privileged account controls through automated, cloud-based, and on-premises capabilities. By integrating these platforms, organisations can leverage their combined strengths to establish a secure business environment. This integration enhances operational control, regulatory compliance, and user experience in the digital era.

IBM Security Verify supports various authentication methods, including passwordless, fingerprints, and one-time passcodes, ensuring flexibility and robustness against unauthorised access. Meanwhile, SAP Cloud Identity Services serves as a comprehensive Identity and Access Management solution which is available in SAP BTP.

The integration process involves configuration updates in SAP CIS and IBM Security Verify to enable authentication utilising standard protocols supported by both components, such as SAML 2.0. Organisations must ensure they have the necessary admin privileges or access rights for editing configurations before initiating the integration procedure. Collaboration between the organisation and SAP is required for the integration, with most of the effort undertaken by the organisation.

Reference Architecture

The diagram represents a SAP Cloud Identity Service that integrates with IBM Security Verify though which various SAP BTP application(s), SAP SaaS solution(s) and on-premises application(s) can be accessed. It demonstrates user sign-in via IBM Security Verify which allow possible passwordless, bio-metric or multi-factor authentication (MFA) using mobile devices for fast application access and pleasing user-experience.

Prerequisites

SAP Cloud Identity Services(for trial instance check this link)
IBM Security Verify (for trial instance check this link)
A smartphone with IBM Security Verify App

Configurations and Settings in IBM Security Verify

When a user logs in, home screen as shown below will be displayed.

Now on the left panel, click on "Applications" under "Applications". On the right side of the screen, there is an “Add application” button. Click on it.

Fill the necessary details under “General” section as below and save the details.

Before we go further, let’s log into SAP BTP account and you will be navigated on SAP BTP Cockpit. As suggested below, navigate to the “Instances and Subscriptions” tab, which is under “Services”.

Upload the metadata file which you have recently saved on your device to IBM Verify dashboard

Configurations and Settings in SAP Cloud Identity Services

Now, get back to SAP BTP and navigate to “Instances and Subscriptions.”

Now, enable the “Cloud Identity Services” if it’s not and once done it will be accessible as below:

Once you click on “Cloud Identity Services”, you will be redirected to the login screen of the SAP authentication screen as shown below

After successful login, you can see the home screen of Cloud identity service. Go to the “Identity Providers” as highlighted below

Click on the Corporate Identity providers and create new identity provider

Once the new identity provider is added successfully, click on the identity provider type and select SAML 2.0 compliant as shown below

Go to the SAML configuration section and fill in the information as shown below.

You can browse the “Metadata” file from your device once you download it from IBM Security Verify dashboard. Go to “Sign on” section of the application and on the right side of the screen, download the file from the given URL and upload the same in SAP Cloud Identity Service as highlighted below:

Click on the Trusting application section and add SAP BTP trial sub-account.

Now, navigate back to SAP BTP cockpit and establish the trust configuration which is under “Security” section for the cloud identity application as shown in the below screenshots.

Select “Establish Trust”

You will see the below steps once you click on establish trust. As a first step, choose tenant and click on next.

After selecting a tenant in the next step choose the domain for your SAP Cloud identity services application.

Click on the next button and configure parameters as shown in below screenshot.

Click on the next button and make a final review of the setup you have done while establishing the trust. Then click on the finish button and save the details.

Once done, you can see the new active trust configuration as shown below.

To provide access to the user, click on the Users section which is inside the “Security” section on the left menu.

Click on the user and assign role collection to the user as shown below.

You can select different roles and assign them to the user. Here we have added three roles to the user. After selecting all the roles, click on the “Assign role collection” button and save the details.

We have completed the configurations in IBM Security Verify and SAP Cloud Identity Services. Let’s test it now by opening the SAP business studio application as shown below.

How does it work? Let’s Check.

Log into SAP BTP Cockpit and Navigate to “Instances and Subscriptions” under “Services” as highlighted below:

It will redirect to the sign in options screen of the SAP. Here, select SAP cloud identity service as an identity provider.

Once you select, it will redirect to the verify sign in option screen for a authentication. Here you can select a different sign in option for Verify or can log in with IBM id/Cloud directory.

Enter your IBMid for log in and click the continue button.

It will redirect you for w3 authentication screen where you can enter your w3 id & password.

Once you click on sign in, you will see below screen of SAP business application studio.

Click on the “OK” button and you will be redirected to the SAP Business Application Studio home screen.

Conclusion

To summarise, combining IBM Security Verify with SAP Cloud Identity Services via SAML 2.0 provides a strong solution for organisations wishing to:

Enhance security: By implementing multi-factor authentication and centralised user management, businesses may greatly minimise the risk of unauthorised access to vital data and applications.

Improve the user experience: SAML 2.0 integration offers single sign-on, which allows users to access various applications with a single login, eliminating login fatigue and increasing overall user experience.

Simplify identity management: Consolidating identity management across several platforms allows organisations to streamline administration operations and reduce the complexity of managing user access.

Overall, this integration enables organisations to achieve a balance between strong security and a user-friendly interface, building trust and confidence in this digital era.

Single Sign On to SAP Cloud Integration (CPI runtime) from an external Identity Provider

2024-04-11T06:53:39.270000+02:00

Introduction:

Yes, you read it right (and you read it right here !). There is an out-of-the-box approach to achieving a single sign-on (SSO) experience for user flows between a corporate identity provider (that authenticates and authorizes the user) and a tenant of Cloud Integration runtime (loosely called CPI worker) fully within the BTP ecosystem.

Ok, let’s zoom out a bit and break this down.

If you are reading this blog post, you probably know already that SAP BTP Services can leverage the OpenID Connect federation-based mechanics of SAP Cloud Identity Service (read: SAP IAS) to connect users from corporate Identity Providers like Entra ID (formerly known as Azure AD), Okta, etc. to XSUAA BTP’s OAuth Authorization Server.
This is certainly not uncharted and I did a detailed blog post a few months ago demonstrating this setup.

However, this setup applied mostly to browser-based SaaS applications (read: Design Time applications with a web frontend), and that brings us to the objective of this blog -> Customers want to put together a similar setup for their client applications that interface with SAP Cloud Integration’s IFLows (in other words, the CPI runtime).
Certainly, this is not impossible to achieve and solution blueprints like these have existed in the past:

My colleague Francisco’s blog puts API Management in between a client and Cloud Integration and enforces API Management to perform an OAuthSAMLBearer handshake.
Microsoft champion Martin Raepple teaches how to set up SAML Trust between Entra ID Identity Provider and BTP to set up a user impersonation flow.

However, these approaches were often seen as cumbersome to set up / troubleshoot and certainly not for the faint-hearted!

Solution Summary:

An easier solution can be described in two phrases: 'OpenID Connect' and 'Authorization Code grant type'. If you are super-smart then you've figured it out already. You can stop reading this blog and hack this yourself.
I wish you a nice day ahead! If you are like me and need a bit more explanation, keep reading 🙂

Here is the solution blueprint that explains that handshake:

SCENARIO: Flows that require end-user authentication from external Identity Providers can natively do so with OIDC and Authorization Code grant type

Step 0: Generate Service Instance / Service Key SAP Cloud Integration Runtime. Refer to this link. Instead of Client Credentials make sure to select Authorization Code.

Step 1: Onboard the needed corporate identity providers in SAP IAS and set up the 'Application' that connects back to your SAP BTP Subaccount as a Trusted Identity Provider via OpenID Connect. Refer to my previous blog post for a detailed procedure.

Step 2: Client (end-user) initiates a connection to the required IFlow (or API artifact). This kicks off the 3-legged OAuth user login flow.

Step 3: As the user is not signed in, she is redirected to XSUAA's login endpoint, and upon login the IAS tenant's OAuth server authorization endpoint at https://<IAS tenant name>.accounts.ondemand.com/oauth2/authorize is invoked using the authorization code grant type. The details of the actual federation as part of the handshake have been omitted here for simplicity. But suffice it to say that the authorization code from the identity provider is made available to the IAS's callback endpoint and finally made available to XSUAA's authorize endpoint and exchanged for the actual access token. This access token will bear the user's scopes and role permissions needed to access the Cloud Integration's IFlow resource.

Step 4: Once successfully authorized, on the receiver side of the IFlow, we will establish connections to 3 different types of backends for illustration purposes. a) S/4HANA Onpremise system over Cloud Connector and Principal Propagation b) SuccessFactors and c) S/4HANA Cloud with OAuth2 SAMLBearer Assertion security material.

Putting it all together:

Let's get our hands dirty by putting together the sequence now. The prerequisites to follow along are listed below:

Administrator privileges in the BTP subaccount where the Integration Suite subscription exists.
An IAS Tenant (with Administrator privileges) that can be coupled (read: Trusted) with the said BTP Subaccount.
Privileges to create Applications (read: IDP configurations) in Entra ID (Azure AD) and/or Okta.
Postman Client.
Backend systems to which the frontend user principal can be propagated to. Either of S/4HANA OnPrem, S/4HANA Cloud, or SuccessFactors tenant.

Step 0: Create a Service Instance for the Authorization Code grant type

Create an instance of the 'Process Integration Runtime' Service (integration-flow service plan) specifically with the authorization code grant type. You can copy the JSON snippet pasted below. Do not worry about the location of the redirect_uri. (When we get down to testing the flow, the browser will invoke the redirect_uri, but this has no consequence as the 'code' will be available for us to copy as a query parameter from the URL itself. When we test this from Postman the client, Postman does not invoke the URL. If you are curious to know, you can read about it here.) Also, make a note that we have specified refresh_token as part of the requested grant type. This will let us demonstrate the ability for clients to refresh the access token post-expiry.

{
    "grant-types": [
        "refresh_token",
        "authorization_code"
    ],
    "redirect-uris": [
        "http://localhost"
    ],
    "roles": [
        "ESBMessaging.send"
    ]
}

With the service instance created, generate a service key (example block is pasted below). Grab the clientid, clientsecret, authorizationurl, tokenurl attributes. We will need these later.

Step 1: Configure OpenID Connect based Trusted Identity Provider of SAP IAS in your SAP BTP subaccount

This step is the heart-and-soul of our approach. We will couple an SAP IAS tenant with our BTP subaccount that has the subscription of our SAP Cloud Integration (SAP Integration Suite) tenant using OpenID Connect protocol and then onboard the desired external Identity Providers (I will demonstrate Entra ID and Okta) as corporate identity providers in the IAS administration console.
Since I've documented the steps in my previous blog, I will not repeat the exact steps here. Please refer to the following sections in the linked blog.

Objective	Steps to follow from the linked blog
Couple your BTP subaccount and your SAP IAS tenant.	Steps 1-6
Configure applications (relying party) in Azure AD and Okta IDP based on OpenID Connect and SAP IAS as the callback URI.	Steps 7 - 25
Configure application in Okta with SAML Trust to SAP IAS.	Steps 26 - 33
Onboard the above Corporate Identity Provider configurations into SAP IAS.	Steps 34 - 46
configure IAS as the proxy Identity Provider and SAP BTP as the Service Provider.	Steps 47 - 52

Nevertheless, here is a summary of the main steps involved in the setup.

1. The subaccount where the Integration Suite subscription exists has a 'Trusted connection' with the OpenID Connect protocol (not SAML) to the IAS tenant.

2. The IAS tenant has a 'Corporate Identity provider' connection to Azure AD (Entra ID) via a set of Application credentials and OpenID Connect protocol.

3. Notice the 'Application' settings on the Azure side. The redirect URI has been set to the IAS tenant's '../oath2/callback' segment

4. The IAS tenant has a 'Corporate Identity provider' connection to Okta IDP via a set of Application credentials and OpenID Connect protocol.

5. Notice the 'Application' settings on the Okta side. The redirect URI has been set to the IAS tenant's '../oath2/callback' segment.

6. We will not leverage this flow in our demonstration but note that it is very much possible to use SAML bindings between the Corporate Identity Provider and IAS. The federation works exactly as OIDC.

7. Next, we want to demonstrate a dynamic / Group assertion / Role Collection based user role/authorization determination. For that note that on the Azure side, we have a group called 'IntegrationDevelopers' that contains the users who must be authorized to call the IFlow / API on the Cloud Integration side.

8. Notice how the 'groups' claim on the IAS side resolves to the value of the group from Azure.

9. Similarly, see that the target user has been assigned to the 'IntegrationSuiteDevelopers' Group in Okta.

10. Okta presents the user's 'Groups' claim to IAS that XSUAA will resolve in a later step.

11. As a last configuration step, notice that there is a RoleCollection on the BTP side (with the 'MessagingSend' role assigned) mapped to the respective groups from the source identity providers.

Step 2 & 3: Initiate the client flow.

The easiest way to demonstrate a client flow is to do so in Postman which natively supports simulating an OAuth 2.0 3-legged Authorization Code grant flow. We can break down the segments of the 3-legged flow in a browser as well. I will demonstrate both of these user agents.

Summary of the steps about to be performed in this section

Objective	Steps
Use Postman to set up Authorization Code flow with Okta Identity Provider	1-8
Use Postman to set up Authorization Code flow with Entra ID Identity Provider	9
Usage of Refresh Tokens	13-14
Use Browser to set up Authorization code flow with Identity Providers	15-18

1. Within the 'Authorization' tab in Postman, set the 'Type' to 'OAuth 2.0' and the 'Grant type' to 'Authorization Code'.

2. Enter the values for the Callback URL, Auth URL, Access Token URL, Client ID, Client Secret from the values saved in the Step 0 block above.

3. Click on 'Get New Access Token'. Make sure to turn on the 'Console' tab at the bottom to keep track of requests and responses across the wire.

4. Postman will launch the Logon pop-up from BTP's Authorization Server. Notice that you are presented with a list of Identity Providers to log into as configured in BTP's Trust Management section. Select the one that corresponds to your IAS Tenant.
Pay attention to the GET requests in the Console tab. You will see that the request to the 'authorize' resource is being redirected to the login page.

5. The system will prompt you to present the user identifier, this will serve as an input to the 'Conditional Authentication' block set in the IAS tenant to resolve which corporate identity provider to redirect to, for the user logon challenge.

6. The system determines that the challenge should come from Okta IDP for my *.sap.com user name. Please refer to the 'Conditional Authentication' screenshot to get a summary of the determination process.
In the 'Console' section, make a note of how the callbacks are handled.

Conditional Authentication section in SAP IAS

7. Okta will authenticate the user and present back the 'authorization code' to IAS.

8. Finally the client will exchange the authorization code for the access token from the configured token endpoint.

9. Let us now perform steps nos. 3-8 again, but this time let us log in with our *.outlook.com user that gets authenticated and authorized from Entra ID (Azure AD).

10. Upon inspection, you will note that the access token issued by XSUAA has the 'ESBMessaging.send' scope as determined by the 'Groups' claim presented by the source IDP. You will remember that we created a mapping for this resolution in a previous step. Also, note that the system bears a refresh_token.

11. Further, if you inspect the respective JWTs issued by Okta and Entra ID, you will see that the tokens contain the claims that represent the Groups, RoleCollections, and User Identifier info.

12. Simply go ahead and 'Use Token' to load the token to make your request.

13. Using the refresh_token -> Notice that the token will expire after a set duration (based on the 'expiry' setting). As you can see in the screenshot below, Postman detects that the available token is expired. It gives an option to 'Refresh' the token. Click on this button.

14. Make a note in the Console tab that the client POSTs to the token endpoint with the available refresh_token and the refresh_token grant_type to get a fresh access token.

15. In the next screenshots, let us perform the same set of steps in a browser. We will need to frame the URL to the /oauth/authorize endpoint. The easiest way to do so would be to copy the URL from the Postman Console we referred to before. The URL is in the format :

https://<tenant-id>>/authentiation.<dc>.hana.ondemand.com/oauth/authorize?
response_type=code&client_id=<url-encoded-client-id>&redirect_uri=<url-encoded_redirect_uri>

16. Invoke the URL in a browser.

17. After the 'login' and 'authenticate' procedures, you will see that the browser is redirected to the redirect_uri location. You can copy the 'code' parameter from the URL.

18. Go back to Postman and POST the Access Token endpoint with the grant_type set to authorization_code and the copied code and the redirect_uri. The server will respond with the access_token with the same set of attributes populated as demonstrated in Step 11.

Step 4: Integration Flow Reciever side propagation

Now that we have an access_token that can be presented to the Cloud Integration runtime (to a 'Sender Adapter'), let us put together a simple IFlow that can demonstrate the fact that the user's identity from the external identity provider can be propagated to 3 backend systems - a) S/4HANA Onpremse, b) SuccessFactors and c) S/4HANA Cloud via Principal Propagation and OAuth2SAMLBearer mechanisms respectively.

Here is a summary of the steps we intend to achieve:

Objective	Steps
Create a sample IFlow that demonstrates the user propagation sequence to 3 different types of backend systems.	1-2
Invoke S4HANA Cloud backend	3 - 7
Invoke SAP SuccessFactors backend	8 - 13
Invoke SAP S/4HANA Onpremise backend	14 - 17

1. Let's start by putting together a simple IFlow to illustrate the user propagation flow. Since we are planning to invoke with 3 backends, the quickest way to demonstrate this would be to create a Router that has 3 branches. Each with a 'Request-Reply' step for the backend type, S/4HANA Cloud, SuccessFactors, and S/4HANA OnPremise respectively.

2. The logic we will follow is that the client passes a value in a custom header named 'target' that shall determine which of the routes is to be invoked.

3. In the property sheet of the HTTP Receiver for S/4HANA Cloud backend, notice that we've used a credential named 's4hanaCloudCredentials' with the OAuth2 SAML Bearer Assertion type.

4. I will not get into the details behind how the attributes of this Security Material have been formulated. Refer to parts of this blog post for details. The points worth mentioning here are that a) we are using the target system type SAP BTP (CF) and b) the 'userIdSource' attribute is annotated for 'email' & nameIdFormat is set to 'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress', thereby implying that the user identifier from our original JWT token negotiated with the corporate identity provider will serve as the user principal to be propagated.

5. Let us make a call to the IFlow URL with the access token set from step 8 described in the above section. Note that we've set the 'target' header attribute to 's4hanacloud' so that the call gets executed in the first route. We get an HTTP 200 OK and the service document as the response and there you have it! We were able to successfully propagate the user from an external identity provider and execute a call in an S/4HANA backend with the user's context.

6. How do I prove my point that the user was indeed propagated? The next two screenshots do so. Note that on the S/4HANA side, I have a 'Business User' that bears my (that is propagated from Okta) emailID. Also, note that the HTTP Call is executed with this user context and NOT with a Communication User (technical user) attached to the Communication Arrangement.

7. Further to prove my point, I execute step no. 5, this time by presenting my *@outlook.com user (that comes from Entra ID), you see that the call fails and the error description calls out that the backend was not able to resolve the presented *.outlook.com user.

8. Let us now look at the 2nd route, the one that invokes a SuccessFactors URL. We extend the same 'OAuthSAMLBearer Assertion' type with a credential named 'SFSFUserPrincipal'. On the processing tab, you will see that I'm invoking a GET Query on the JobProfile resource.

9. In the details of the Security Material, note that we've set the attributes per SuccessFactors documentation. The User ID is set for principal propagation. Like before, we've used the same nameIdFormat as set in step 4 above, and don't forget to include the apiKey attribute as well.

10. Let us now invoke the IFlow, this time around with the header 'target' set to 'sfsf'. I get back a response from SuccessFactors with the JobProfile details.

11. Again, how do we prove that the call indeed was made in the signed-in user's context? There are many ways to establish this. A simple way I followed was to put a 'proxy' layer like API Management before the call hits the SuccessFactors backend and print out the 'Bearer token' from the 'Authorization' header. Upon Base64 decoding the token, you will see that the token bears a 'sfPrinciple' attribute with the employee ID identifier.

12. Look up the employee profile of the user in question in your SuccessFactors tenant and you can verify the matching employee ID and the corresponding email address.

13. Negative testing -> If I perform the call again, this time by signing in with the email address from Entra ID you should see a 401 unauthorized exception stating that the propagated user wasn't resolved.

14. Finally, we are down to the last segment of our testing. A connection to S/4HANA On-premise. I've configured an SAP Cloud Connector and an X.509 certificate signing procedure (that is beyond the scope of this demonstration) and have dialed 'Principal Propagation' for the authentication type.

15. Invoking the client this time around with the 'target' header set to 's4hanaonpremise'. I get back a response from the server with my service document for the invoked GWSAMPLE_BASIC OData service.

16. As a quick verification step, let us go to the 'Monitor' section in the Cloud Connector and within the 'Most Recent Requests' tab, you can see a record for the 'User' that was propagated.

17. Open the LJSTrace log file and you can hunt down a log entry that corresponds to the user subject that was propagated via the short-lived x.509 certificate.

Phew!

Summary:

It is beyond doubt that 'client credentials' and 'x.509 certificate' are the two most prominent and widely popular ways to authenticate to an Integration Flow / API artifact in SAP Integration Suite, but should you have a requirement to authenticate and authorize with the client user's identity from a corporate Identity Provider, OpenID Connect support from SAP Cloud Identity Service along with the Authorization Code grant type in SAP Integration Suite provide an excellent and out-of-box approach to get your job done.

Cheers, and more power to the SAP Integration Suite Community!

SAP Secure Login Service for SAP GUI Now Supports Custom Certificate Authorities on AWS

2024-04-11T10:24:50.174000+02:00

The SAP Secure Login Service for SAP GUI solution provides your SAP GUI users with simple and secure access to their ABAP-based business applications. In March 2024, we released the long-awaited Custom Certificate Authority (CA) feature. You can now integrate your own Public Key Infrastructure (PKI) by connecting to a private CA hosted on Amazon Web Services (AWS).

With the SAP Secure Login Service for SAP GUI, you can provide end users of SAP GUI with X.509 certificates that enable single sign-on (SSO) to ABAP-based business applications. After successful authentication, the SAP Secure Login Service provisions a short-lived X.509 certificate to the Secure Login Client on the end-user desktop. This certificate is then used for SSO to the ABAP systems. In the initial scope of the solution, the SAP-managed Cloud CA was used to sign these end user certificates.

What’s new?

With the newly released feature you now have the option to integrate your own PKI by connecting your cloud-based private CA running on Amazon Web Services (AWS) to the SAP Secure Login Service. After successful authentication of the end user, your private CA issues an X.509 certificate. And the SAP Secure Login Service then returns this X.509 certificate to the Secure Login Client on the end user desktop.

How does it work?

By connecting your cloud-based private CA running on AWS, the X.509 certificates will be signed by your own customer-managed CA. The SAP Secure Login Service will just reuse your CA setup and provision the certificates to the Secure Login Client of the end users.

Configuration required for the token exchange, credentials for accessing AWS, and which AWS Private CA to be used can be configured in the administration console of SAP Secure Login Service (via the new tab “Custom CA”). This configuration is needed for secure token exchange and to ensure that only your SAP Secure Login Service subscription can be used to access your custom CA. And at the same time, that the certificates can only be used for SAP GUI SSO.

Of course, the certificates that are signed by your custom CA will look differently from the ones that are signed by the SAP Cloud Root CA. You can decide about the root, how many levels you want to have in there, and the names.

For configuration information, please refer to the documentation that is available on SAP Help Portal here:

https://help.sap.com/docs/SAP%20SECURE%20LOGIN%20SERVICE/c35917ca71e941c5a97a11d2c55dcacd/32875689a8654e0bb3c8697fb6947940.html

What are the benefits?

For compliance reasons you might not be allowed to use the SAP-managed Cloud CA to sign the end user certificates but have to use a CA that is fully under your control. With the new feature you can now integrate with your custom CA running on AWS thereby having full control how the CA is set up. For example, the root of the CA, whether it is in the AWS CA or offline, and how the signed certificates will look like.

More information

For more information about our SAP Secure Login Service for SAP GUI solution and to stay up to date on the latest developments, visit our topic page in SAP Community:

https://pages.community.sap.com/topics/single-sign-on

INFLUENCE THE DEVELOPMENT OF SAP ENTERPRISE THREAT DETECTION, CLOUD EDITION

2024-05-03T06:40:10.948000+02:00

Introducing influence page for SAP Enterprise Threat Detection, cloud edition.

The SAP Enterprise Threat Detection product team are inviting customers and partners to share their feedback and ideas to enhance our solution.

On SAP Enterprise Threat Detection, cloud edition Influence page you can see all submitted requests, submit your improvement requests, vote and comment on other ideas.

The rationale and advantages of a customer influence page include:

Augmenting customers engagement and influence on product features.
Improving product/services using meaningful customer insights.
Cultivating an engaged community.
Serving as a central platform for customer suggestions and fueling innovation.

The product team regularly evaluates the ideas and considers them for roadmap planning. Votes help to priorities ideas along with other important selection criteria such as:

DESIRABILITY: How many customers voted for this? How many customers will benefit from it?
VIABILITY: Is this Improvement Request globally relevant? Is this in alignment with SAP’s strategy for the product?
FEASIBILITY: Is the development effort realistic? Is this request achievable within the product’s architecture?

While this page is mainly for the public cloud edition, for private cloud and on-premise versions feel free to propose integration-related ideas.

Follow the steps below to get access and start sharing your enhancement ideas:

Go to SAP Enterprise Threat Detection, cloud edition Influence page.
- In case you are a new user, create a user account using S-User-ID and accept the Terms of Use. Once the user is created you activate SSO and can access without any interruption.

Follow the session to get notified of new Improvement Requests and blogs.
Vote and comment on Improvement Requests posted by other customers/ partners.
Submit new Improvement Requests.

You can also check out the videos\link below, if you wish to learn more about SAP Continuous Influence and how to submit and manage improvement requests:

Please reach us at SAP-ETD@sap.com in case of any issue.

We look forward to seeing your ideas and further improve our software as we move forward.

Streamlining User Provisioning from IBM Verify to SAP Cloud Identity Services

2024-05-08T12:57:02.652000+02:00

SAP Cloud Identity Services (CIS), part of SAP BTP, can be used to integrate Identity Access Management (IAM). In our last blog, we discussed the integration of SAP Cloud Identity Services (CIS) with IBM Security Verify, and now we're taking the next step in this integration. User provisioning is the process of setting up new user accounts in a system or application. In this blog, we will explore a common use case - - transitioning user provisioning from IBM Verify to SAP Cloud Identity Services, and how this transition can streamline operations and enhance security.

The Challenge of User Provisioning

User provisioning is the process of granting and controlling access to resources within an organisation’s information technology infrastructure. Historically, on-boarding or off-boarding users has been a laborious and time-consuming procedure that frequently required numerous processes across multiple systems. As businesses embrace cloud solutions, the complexity of user provisioning has grown, necessitating automated and integrated approaches.

Transitioning from IBM Verify to SAP Cloud Identity Services

IBM Verify is a comprehensive identity and access management system that includes multi-factor authentication (MFA) and adaptive access control, while SAP Cloud Identity Services offers identity lifecycle management, single sign-on (SSO), and access governance features. Integrating these two systems can help organisations automate and streamline user provisioning operations, while also improving security and user experience.

How does it work?

The diagram shows that IBM Security Verify acts as a central user management system. It creates user accounts and manages their attributes, and also provisions them (or creates them) in SAP Cloud Identity Services, potentially syncing relevant user attributes. Selected attributes from Verify are mapped to specific target attributes in SAP Cloud Identity Services, ensuring consistent user information across both systems. SCIM, a standardised protocol, enables communication between Verify and SAP Cloud Identity Services. On the left side of the diagram, IBM Security Verify acts as a SCIM server, receiving requests for user management and then modifying the target directory as needed. This streamlines user creation and ensures consistent user information across both systems.

Prerequisites

SAP Cloud Identity Services (for trial instance check this link)
IBM Security Verify (for trial instance check this link)
A smartphone with IBM Security Verify App

Configurations and Settings in IBM Security Verify and SAP Cloud Identity Services

Log into IBM Security Verify as an administrator

When a user logs in, the home screen as shown below will be displayed.

On the left panel, click on "Applications" under "Applications". On the right side of the screen, there is an “Add application” button. Click on it.

Fill in the necessary details under “General” section as below and save the details.

Before we go further, let’s log into SAP BTP account and you will be navigated on SAP BTP Cockpit. As suggested below, navigate to the “Instances and Subscriptions” tab which is under “Services.”

You have to enable the cloud identity services application.

Once enabled, it will look as below. Now, click on Cloud Identity Services application and you will be redirected to the login screen of the SAP authentication screen as shown below.

After a successful login, you can see the home screen of Cloud identity Services. Go to the “Identity Providers” as highlighted below :

Click on the Corporate Identity providers and create new identity provider.

Once the new identity provider is successfully added, click on the identity provider type and select SAML 2.0 compliant, as shown below:

Go to the SAML configuration section and fill in the information as shown below:

You can browse the “Metadata” file from your device once you download it from IBM Security Verify dashboard. Go to the “Sign on” section of the application and on the right side of the screen, download the file from the given URL and upload the same in SAP Cloud Identity Services as highlighted below:

Click on the Trusting application section and add SAP BTP trial subaccount.

Establish the trust configuration, which is under the “Security” section for the cloud identity application as shown in the below screenshots.

You will see the below steps once you click on establish trust. In the first step, choose tenant and click on the next.

After selecting a tenant, choose domain for your SAP Cloud Identity Services application.

Click on the next button and configure parameters as shown in the below screenshot.

Click on the next button and review the setup that you have done while establishing the trust. Finally, click on the finish button and save the details.

Once done, you can see the trust new active trust configuration as shown below:

Now go back to IBM Security Verify and click on “Sign-on” section, then select “Use metadata” checkbox. It will allow us to upload the metadata file which we have downloaded from SAP BTP as shown below:

Upload the metadata file which you have recently saved on your device to IBM Verify dashboard.

Now go to the “Account lifecycle” tab and add SCIM URL, Username and password detail as shown in below image. You can get all the details from SAP Cloud Identity Services application page.

To get SCIM URL, go to SAP CIS and get the URL details from the browser and add “SCIM” at the end of URL.

After adding the above details, scroll down and you can see “Attribute mapping” section. Click on the checkbox for which attribute you want to map from IBM Verify to SAP CIS and want to keep updated. Here we have checked email. Save this detail once changes are completed.

We have completed the configurations in IBM Security Verify and SAP Cloud Identity Services. Let’s add user with attribute into Verify and check if it is mapped to Cloud Identity Users dashboard.

Go to the Users tab under the “Directory” section on the left side of the verify dashboard and click on the “Add User” button as shown in below screenshot.

Fill out the necessary information for the user as mentioned in the below image and click on the “Save” user tab.

Scroll down and you can add more detail about the user. Here we have added an email ID, mobile number and user company details.

Once done, click on the Save button and the user detail will be saved.

Open the Cloud Identity Services application and go to the user section to check whether the newly-created user from Verify is mapped.

Click on the “Instance and subscription” section from the “Services” section on the left menu, and once the application list is shown, click on the Cloud Identity Services application as shown below.

When the new application is loaded, click on the “User Management” tile and all the user list will be displayed.

As you can see in the below screenshot, a new user is created, which is added from Verify and mapped into SAP Cloud Identity Services. Also, the user detail is mapped into Cloud Identity Services.

Conclusion

Effective user provisioning is critical to maintaining security, compliance, and operational efficiency. Centralising identity management, improving security, and streamlining administration activities enables organisations to successfully manage user identities and access controls across their entire IT infrastructure. Embracing integrated identity management solutions is more than just convenient - - it is a strategic need for businesses looking to flourish in an increasingly linked and security-conscious environment.

More information:

Refer to our another blog on SAP Cloud Identity Service integration with IBM Security Verify.

If you have any question or query about SAP BTP please refer to SAP Community and for any question or query about IBM Security Verify refer to IBM Security Verify Community