4

Security and Connectivity

After reading the previous chapters, SAP BTP should no longer be a stranger to you. Now, it is time to delve into the design aspects, and we will start with the one that is crucial to every organization: security.

After discussing security, we will touch upon the subject of connectivity, which is inherently related to security. Connectivity is all about paving the connection routes among several systems. And keeping these routes safe is of paramount importance.

In this chapter, we’re going to cover the following main topics:

• Security in general
• Identity and access management (IAM) in SAP BTP
• Connectivity

After completing this chapter, you will be able to incorporate security aspects into your architecture design and include connectivity across several systems.

Technical requirements

You might have already registered for an SAP BTP trial account, as suggested in the Technical requirements section of Chapter 3, Establishing the Foundation for SAP Business Technology Platform. If not, check it out and register for a trial account.

In this chapter, we will talk about an on-premise component called SAP Cloud Connector. If you want to get your hands dirty with it, you can download it from https://tools.hana.ondemand.com/#cloud. Also, for trial purposes, you can install on-premise SAP systems using SAP CAL at https://cal.sap.com/. Just be careful as these systems could incur very high costs.

Security in general

The need for security is a reality in the IT world. If you haven’t been to this side of it before, ask your company’s security team, at what frequency does a cyberattack hit the company? Don’t be surprised if the quantity is on a per-second scale.

Security implies there is something of high value that needs protection. At its core, it is the protected, confidential, or sensitive data that your company needs to keep safe. For example, data protection is related to regulatory compliance in the case of personally identifiable information (PII) such as in the EU’s General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA), and China’s Personal Information Protection Law (PIPL). In the case of a data breach, a company could face severe penalties. More importantly, its prestige will be significantly damaged, which could have commercial consequences.

A cyberattack can paralyze a company’s mission-critical systems and adversely impact its operational ability. Depending on its industry, the company could be impacted in different ways. For example, due to a cyberattack, a company might stop providing proper customer service, or its production line might come to a halt. If it’s a government organization, this might cause political friction. And going a bit further, it could even become a matter of national security if the cyberattack is toward, for example, a state’s defense system.

In the context of IT security, you might have already heard about the onion model or the Swiss cheese model. One uses the scales of an onion bulb, and the other has stacked slices of cheese. Both models suggest a layered approach to security; we will follow this approach. To begin, we will correlate the traditional onion model layers with the cloud service model components, as illustrated in Figure 4.1:

Figure 4.1: The cloud service model and onion model layers

The cloud service model is often used to explain the shared responsibility between the service provider and the customer. Because we are discussing security for SAP BTP, in Figure 4.1, according to the PaaS model, the customer is responsible for the application and data layers. In contrast, the rest of the components are under the provider’s responsibility. As you would expect, the liability for each layer includes security as a crucial element. The more layers a cyberattack penetrates, the worse the implications are. Now, let’s discuss these layers in more detail.

Infrastructure security and the provider’s security compliance

For SAP BTP, you have a contract with SAP; therefore, the responsibility of all cloud service model layers apart from application and data falls under SAP. Thus, regardless of which hyperscaler your SAP BTP subaccounts run on, your point of contact is SAP. That’s why, from this point on, we will not always make an explicit distinction between SAP and the relevant hyperscaler.

You entrust your company’s data to SAP as the cloud service provider. Surely, before doing that, you need to do due diligence and evaluate whether SAP meets the necessary security requirements. So, what kind of requirements can you think of?

To begin with, as you might remember from Chapter 3, SAP BTP runs on an infrastructure located in a data center that includes all the physical elements such as servers, disks, network devices, cables, and more. So, the first step should be to secure those elements. The cloud service provider ensures this by taking physical security measures such as using security cameras, employing staff after necessary background checks, only allowing authorized staff to administer the physical components, and preventing unauthorized access to the data center building.

The hosts in the provider’s data center are not in a closed circuit and, surely, need to communicate with external elements. So, there are networking components that link your content to the outside world. This means there is a virtual attack surface susceptible to security intrusion; therefore, it needs protection. The data center provider should take necessary measures to prevent cyberattacks through this surface. These measures include firewalls, gateways, proxies, mechanisms to cope with distributed denial-of-service (DDoS) attacks, and advanced intrusion detection and prevention controls. To ensure these measures are properly in place, frequent penetration tests are performed.

So far, it was all about core security; however, to establish a good level of trust with the provider, you need to extend these controls further into other relevant areas such as privacy, confidentiality, availability, and processing integrity. All these aspects work hand in hand to determine the reliability of the cloud provider. Also, security is established not only against intrusion agents but also against different types of hazards, for example, equipment failures, disasters, power outages, fires, and more.

That said, as a customer, should you inspect the data centers on which SAP BTP is running? Of course, you have to ensure the provider meets all the trust standards, but continuously monitoring them would be an overburden for a typical company. Now, consider a large cloud provider with millions of customers. Each customer requesting an inspection for their own assurance purposes and the cloud provider dealing with such requests would be a huge inconvenience. So, there must be a better way.

We already gave away how the industry solved this challenge when we mentioned standards. Luckily, independent organizations create and maintain standards for the aforementioned aspects, such as the International Organization for Standardization (ISO) or a global network of national standards organizations in different countries, for example, the British Standards Institution (BSI). Other examples include the American Institute of Certified Public Accountants (AICPA) and the German Federal Office for Information Security (BSI in German). Cloud providers ensure they implement the necessary controls outlined by these organizations and get audited by independent parties, after which they can claim they comply with those standards.

For example, Figure 4.2 illustrates the trust service categories defined by AICPA’s System and Organization Controls 2 (SOC 2) audit reports:

Figure 4.2: AICPA’s SOC 2 trust service categories

We haven’t explained all of this merely for general knowledge. If you are in the process of evaluating SAP BTP as a new platform to adopt or if your architecture design is ready for implementation, it is likely you would seek approval from your company’s information security team. Firstly, let them know that SAP BTP complies with the following:

• ISO 27001 and ISO 22301
• AICPA’s SOC 1, SOC 2, and SOC 3
• German BSI’s C5
• FedRAMP (via SAP NS2)
• PCI DSS attestation (for SAP MultiCloud)

Important Note

If you need evidence of SAP BTP’s compliance with the aforementioned standards, you can visit the Compliance section of the SAP Trust Center at https://www.sap.com/uk/about/trust-center/certification-compliance.html. Here, you can search for “SAP Business Technology Platform” to see a list of available audit reports and certificates. However, some reports such as SOC 2 are for a restricted audience, for example, customers with non-disclosure agreements, so you need to request them formally.

You might need to demonstrate that your design takes care of additional security requirements, including other infrastructure security elements such as data encryption. SAP BTP supports communication protocols with Transport Layer Security (TLS) for encrypting data in transit. In addition, there are options to establish additional communication security layers, which we will discuss later in this chapter. For the services that persist data, for example, SAP HANA Cloud, SAP supports data volume encryption and physical access control at the infrastructure level, which you can consider as a measure to secure data at rest.

So, we have discussed enough in terms of infrastructure-level security. Now, let’s move on to the security topics at the application layer.

Security at the application layer

In the previous section, we discussed how SAP ensures the security of cloud service layers below applications. There wasn’t much you needed to handle as a customer. However, as you start using these services and building your applications on SAP BTP, they will process your data, and securing your data will be primarily your responsibility. SAP BTP doesn’t leave you alone here; it provides capabilities that you can incorporate into your applications and service usage. In the following sections, you will see examples of this:

Figure 4.3: The core SAP BTP security elements

In Figure 4.3, you can see the core security elements illustrated together. Since we discussed the infrastructure aspects earlier, let’s continue by taking our discussion to the application layer.

Building secure applications

First, let’s discuss what you need to do to build secure applications. This subject is quite broad and including all of its aspects here might not be the best idea as they need some prerequisite information, which you will learn later in this book when we discuss extensibility, integration, and data. So, this section will be a brief overview at this stage.

First of all, the responsibility of building secure applications is, as you might have guessed, with the application developers. They need to follow security practices to prevent attacks against the application, such as cross-site scripting (XSS), SQL injection, and more. To minimize the risk, it’s best to implement automated security scans in the change delivery mechanism to detect the vulnerabilities before it’s too late.

Next, the application needs to implement access controls by using SAP BTP’s Authentication and Trust Management service, which enables the application to leverage the IAM entities, for example, trusted identity providers (IdPs), roles, and more. When used in relation to an application, this service is also referred to as User Account and Authentication (UAA or XSUAA). We will discuss IAM later in this chapter.

Let’s suppose your application is accessing external services, including other applications or services in the same subaccount. In that case, it might be wiser to isolate the configuration that defines the parameters to access these external services. For this, you can use SAP BTP’s Destination service to create and manage the destinations your applications can use. This service makes sure the connection details are safely kept and separated from your application code. Additionally, with the Connectivity service, you can access on-premise systems securely. We will discuss the destination and connectivity services later in this chapter:

Figure 4.4: The SAP BTP helper services for building secure applications

Another SAP BTP service worth mentioning here is the Credential Store service. With this service, you can centrally store cryptographic entities such as passwords, keys, and keyrings. Then, applications can safely retrieve them at runtime through their service bindings and using the JavaScript Object Signing and Encryption (JOSE) framework.

Last but not least, we have the Malware Scanning service that you can use to scan the business documents processed in your applications. After binding this service, your application can make API calls to it and provide the business document in binary format. This call will then return the scanning result upon which your application can take further action, for example, deleting the file and creating a log record. Just to note, at the time of writing, this service is in beta version. So, check the SAP roadmap to find out more about it and whether it is available for production use.

Does this sound a bit overwhelming? In that case, programming frameworks and libraries such as SAPUI5, the application router, and CAP can give you peace of mind because they take care of the security concerns while streamlining certain aspects of programming such as database connections, authentication, role-based access control (RBAC), API calls, and more. We will see some examples of these later in this book.

Security features in SAP BTP services

The SAP BTP services are just applications similar to the ones you build, and as you might expect, the developers of these applications need to secure the applications properly. Therefore, these services might impose certain restrictions to make sure you use them securely. Besides, some come with security features specific to the service so that you, as a consumer, can use them. Let’s list a subset of these features:

The SAP BTP service	Security features
SAP HANA Cloud, SAP HANA Database	Support for secure connections, for example, TLS for ODBC and JDBC External IdP for database platform users that can be used for SSO RBAC IP allowlists Data masking and anonymization Audit policies Secure internal credential store and SAP HANA secure user store
SAP HANA Cloud, SAP ASE Database	Support for secure connections, for example, TLS for ODBC and JDBC Column-level encryption RBAC Audit logging
SAP Integration Suite	Support for secure protocols, for example, HTTPS and SFTP Message-level encryption, for example, PKCS#7, PGP, XML Signature, and WS-Security Design-time RBAC Authentication and authorization for inbound calls Malware scanner Audit logging API management policies

Table 4.1: Examples of SAP BTP service-specific security features

Bear in mind that you are at the application layer, and the responsibility of using these features lies with you. So, you can choose whether to configure and control these features or not while considering the security implications.

Data protection and privacy

When we talk about Data Protection and Privacy (DPP), we are mainly referring to several legislations across the globe that regulate how organizations use certain types of data. Being one of the main motivations for establishing IT security, we already mentioned examples of such legislation at the beginning of this chapter.

All of the security measures we discussed in the previous sections can help organizations to be compliant with these legislations. However, DPP is not only about securing data against intruders or malicious users; it also requires the relevant data to be managed in a way that does not impact an individual’s privacy. For example, a customer might wish to exercise their right to be forgotten. In that case, your organization needs to make sure that your systems do not store any PII of the customer. Another example of a compliance requirement is seeking your customers’ consent to leverage their data for a given purpose.

Assuming all technical and organizational measures that protect the data are in place, SAP’s specific concern for SAP BTP is then limited to only the personal data it stores for the platform operations. For this, SAP BTP persists limited user information and provides the necessary means for deleting this information if required.

After that, as the platform consumer, the responsibility of complying with DPP legislation mainly lies with you. You manage the data that is processed by the platform for your operations; hence, you need to take necessary precautions and establish compulsory mechanisms. Here, you can make use of some SAP BTP features for compliance. For example, you can use the RBAC feature to ensure only authorized users view the regulation-relevant data.

Important Note

For more information regarding SAP’s data protection and privacy considerations, you can visit SAP Trust Center’s Privacy section at https://www.sap.com/about/trust-center/data-privacy.html.

SAP BTP offers some business services that you can use to fulfill DPP requirements: Data Retention Management, Personal Data Manager, and Data Privacy Integration. With these services, you can manage the compliance aspects of personal data processed by your applications in SAP BTP.

Finally, here’s a good piece of advice: if you have DPP-related concerns about using SAP BTP, do not hesitate to discuss them with SAP as this is a delicate matter.

So, we have now explained the core security concepts in detail. Next, let’s go into more specific areas; next in line is IAM.

IAM in SAP BTP

Securing applications does not mean you deploy them and let them run on their own in a box that no one can access. Someone will have access to the applications, but can it be just anyone? Maybe, but you might need to control this by only letting certain people have access to your application. But then, among those who are allowed to access the application, should everyone be able to use every capability and see every piece of data? Alternatively, should there be a further control level that only lets a subset of these people use a specific feature?

It looks like we are establishing a control mechanism that revolves around the people, that is, the users, and their access levels to the application. Defining this mechanism through a framework of policies and implementing technologies for operating this mechanism is called IAM.

In order to let some people have access or not have access to an application, the first step is to distinguish one from another. For this, we need to establish the person’s identity based on their claim of who they are. They can do this by simply saying their name or maybe something that uniquely refers to them, such as an ID number or a username where uniqueness is guaranteed.

Before progressing further, let’s spice things up. Earlier, for the sake of simplicity, we told the story using people as actors. However, in reality, the identity attempting to access an application can also be another application or something else, such as an IoT device.

Authentication and authorization

Now that we have an answer to the question of “Who are you?”, let’s continue with the remaining procedures of IAM.

Let’s suppose that you are a guard. Just because someone has claimed an identity, would you let them enter? Of course, you would not. Instead, you would try to establish the authenticity of their claim and verify they are who they claim to be. This is what authentication is all about. This can be done by simply challenging the identity claimant for a piece of information that is good enough to verify their claim. Yes, we know what you are thinking–maybe a password. Today, this is the simplest form of authentication. However, in response to evolving security challenges, the IT industry has come up with many sophisticated and more secure authentication methods using biometrics, such as fingerprints and retinal scans, and mobile devices, such as one-time SMS verification codes. Besides, additional factors are considered when authenticating users, such as their location, the devices they use, and more.

Let’s continue with the metaphor we used earlier. The visitor is now authenticated and has just passed the gate. Can they do whatever they want? If not, there should be an additional level of questioning when they attempt to do an action. This is similar to the process of authorization, where a system checks whether the user has the privilege to perform a specific action and allows or denies the attempt accordingly.

For complex applications, assigning every user with all the actions they are authorized to perform and managing them will quickly become a hassle. To alleviate this inconvenience, multiple authorization items can be grouped together under a role, and users can be assigned to these roles. In general, these roles correlate with the job roles of the personas. Furthermore, SAP BTP introduces an additional aggregation level. The roles in SAP BTP are mostly attached to applications, and in order to group roles from multiple applications, role collections are used. Here, a role collection is not just a grouping container; instead, you can design it to correspond to the tasks a persona needs to perform. For example, a role collection for an integration developer can include all of the roles necessary for different capabilities of the Integration Suite service. Alternatively, a data protection officer can be assigned a role collection that contains the roles of the Personal Data Manager and Data Retention Management services. By using roles to determine whether a user is authorized to perform an action, you can implement RBAC.

What we have discussed so far should be enough to set the stage. However, before getting into the specifics of SAP BTP, let’s discuss a crucial IAM component.

What does an IdP do?

Let’s suppose you only want to allow certain users to have access to your application. In that case, when developing your application, you can build a module to handle that side of things such as user registration and password setup. Additionally, when a user attempts to log in, your application can challenge them for their username and password. You can then check the username and password against the user records that your application stores and log the user in if successfully verified. This all sounds good. Now you need to develop several new applications and implement the same mechanism repeatedly for each application.

The user login stage is very significant for security. That’s when you let the user through the gate to use your application and see the data. However, now, the security team says that you should only let users log in if they are accessing the application from certain locations. Here, location can be a geographical locality or an abstract location that is your company’s IT security perimeter protected by firewalls. They also suggest that your applications should challenge their users with multi-factor authentication (MFA), where they need to provide multiple isolated pieces of information to be verified. If the number of required methods is set to two, this is called two-factor authentication (2FA).

It looks like you should add these extra capabilities to your applications. Or is there a better way? Especially those of you with development experience should have already seen the opportunity here for reusability. You can create a separate application that uses these authentication features to serve as a central component. We call this type of application an IdP.

An IdP can handle most authentication aspects, and your other applications can integrate with it to delegate authentication tasks. This integration is based on a trust relationship that corresponds to the configuration at both ends of it. You can still choose to keep the essential authentication elements in your application in order to reduce dependency. However, you can delegate most of the complex authentication functionality to the IdP:

Figure 4.5: An application delegating authentication to the IdP

Having an IdP unlocks additional features. We can position it as a central component where many applications delegate authentication to the same IdP. Therefore, all integrated applications can uniformly benefit from the extra functionalities of the IdP. Let’s suppose the IdP remembers it has already authenticated a user, for example, by using a session cookie it delivered to the user’s browser when the user logged in to an application that trusts the IdP. In that case, it can choose not to challenge the user for a password again for subsequent authentication requests even though they are for different applications that also trust the same IdP. This convenience mechanism is called single sign-on (SSO). Many companies also use SSO as a user experience enhancement as the users would not need to set and remember passwords for different systems.

There are standards that formalize the integration between an application and the IdP. This includes the security aspect since the trust relationship requires cryptographic functionality to be involved. The most prominent standards are Security Assertion Markup Language (SAML) and OpenID Connect (OIDC). We will see a concrete example later when we discuss how SAP BTP uses SAML.

Following these standards, you can implement your own IdP. However, companies tend to go for commercial IdP solutions, such as Microsoft Azure Active Directory (AAD). This is mainly due to the availability and scalability requirements. Also, these commercial products provide a good variety of additional features.

On top of authentication, you can delegate other IAM capabilities to the IdP at different levels. For example, you can base your RBAC implementation on the information managed by the IdP. For this, the IdP can send the information needed, for example, the groups the user belongs to, within the authentication response "and the application can use this information to check user’s authorization".

Now that we have discussed all the essential elements, let’s see how SAP BTP handles IAM.

How does SAP BTP authenticate users?

Firstly, let’s make a distinction between the two main types of users that access SAP BTP:

• Platform users: These users access the platform for technical and administrative purposes, such as using cloud management tools and services.
• Business users: These users access the business applications or services as end users.

SAP BTP does not manage identities directly; instead, it uses identity federation to delegate the management of identities to IdPs. However, for RBAC, the platform still needs to know minimal information about users so that roles can be assigned to users. The user records created for this purpose are called shadow users, and they are tightly coupled with the users managed by the IdP. You can create shadow users at both a global account level and a subaccount level and assign roles to them. Also, if users need to access Cloud Foundry organizations and spaces, they need to be added as organization or space members.

SAP BTP comes with a default IdP, SAP ID Service (except SAP BTP subaccounts in the China region). If you have been in the SAP world long enough, you probably have a p-user that you use to log in to SAP sites, including the SAP Community site. Also, you might have an s-user that is managed by your company and lets you log in to SAP sites, such as SAP Support, with your company identity. SAP ID Service provides and manages all these p-users and s-users. In addition, if you have multiple SAP ID Service users, you can link them to an SAP Universal ID, which conveniently groups multiple SAP IDs and provides one common user interface for logging in where you can select which specific user you want to log in with.

Besides the default IdP, SAP BTP also lets customers configure trust with multiple custom IdPs in a subaccount, given that they support the SAML 2.0 standard. So, for example, you can add your on-premise or cloud corporate IdP, such as Microsoft AAD, SAP Cloud Identity Services, Microsoft ADFS, Ping Identity, Okta, Forgerock, or OneLogin. If multiple IdPs are configured in a subaccount, it’s possible to instruct an application on which IdP(s) to use.

With the trust configuration, you define which attributes the IdP includes in its authentication responses, and more importantly, which attribute it assigns as the name identifier that should match shadow user IDs in SAP BTP. You probably need to discuss these with your company’s EUC team as they might suggest best practices.

Important Note

At the time of writing, you can only configure custom IdPs for business users, which means for platform users, SAP ID Service is the only option.

When a business user launches an application or a service, the SAP BTP Authentication and Trust Management service puts the IdP integration into action, and a SAML flow runs, as shown in Figure 4.6:

Figure 4.6: A SAML authentication flow for a user accessing an application or service in SAP BTP

As you can see in the preceding diagram, the SAML flow runs through the user’s browser by using HTTP redirections where SAML artifacts are attached to the requests and responses. In SAML terms, SAP BTP acts as a service provider here. To be more precise, it is the UAA service instance that interacts with the SAML flow. If you are asking what UAA is, you should scroll back and read the Building secure applications section and maybe check out Figure 4.4.

With this setup, you can also achieve SSO, and the user can access an SAP BTP application with no authentication challenge if they were previously authenticated with the same IdP.

As an alternative to directly linking your corporate IdP to an SAP BTP subaccount, you can also configure SAP Cloud Identity Services – Identity Authentication as an IdP. If it fits your requirements, you can use it as the main IdP. Moreover, based on configured conditions, it can also act as a proxy between SAP BTP and another IdP, that is, your corporate IdP. Therefore, this alternative might give you an extra level of flexibility with identity federation. In Figure 4.7, you can see how a SAML flow happens with this setup:

Figure 4.7: SAML authentication with SAP Cloud Identity Services – Identity Authentication

It might look complicated; however, all of these redirections and passings of SAML artifacts happen transparently once the trust relationships are set up.

Besides the capabilities mentioned previously, SAP Cloud Identity Services – Identity Authentication also supports advanced features. Some of them are listed here:

• Social login through popular providers such as LinkedIn, Twitter, Facebook, and Google
• 2FA, for example, FIDO2, the SAP Authenticator app, and SMS
• Risk-based authentication to allow, deny, or enforce 2FA for requests coming from a specific IP range
• Self-service processes for registration and password reset
• REST APIs for user management
• Custom privacy policies and terms of use

So, now you have learned how SAP BTP authenticates users. We will discuss integration-related authentication topics later. Next, let’s look at how RBAC happens in SAP BTP.

RBAC in SAP BTP

Previously, we defined the basic elements of RBAC from a general aspect. In this section, let’s see how SAP BTP implements RBAC end to end.

Based on the requirements, developers can identify the basic authorization elements of an application to include them in the application’s security descriptor:

• Scopes: These are the application functions that the user can only perform if they have the required authorization. For a simple application that maintains a data object, such as a sales order, typical examples would be Display, Edit, and Delete.
• Attributes: These are variables in the application’s authorization context that are meant to be linked to the attributes of a user at a later stage.

After identifying the scopes and attributes, developers define role templates that bundle these elements together. Roles are instances of role templates. When an application is deployed, its role templates that don’t contain an attribute are automatically instantiated to create roles. On the other hand, if the role template contains an attribute, then it requires human intervention to configure the attribute value that will be attached to the role.

Let’s explain this with an example. A small university’s registrar’s office needs two new applications:

1. Officers are divided into several teams that correspond to university departments.
2. Officers will use the registry application to manage essential student information:
   • Although all officers can display and edit students’ information, only the senior officers can delete records.
3. Officers will use the course subscriptions application to manage students’ course subscriptions:
   • Officers can only see the student records that belong to the department they look after.
   • Although all relevant officers, as per the preceding sub-point, can display course subscriptions, only the senior officers can edit and delete records.
4. The university uses a central IdP and requires both applications to use identity federation and SSO. The trust relationship with the IdP is set so that the authentication response includes the authenticated user’s team information:

Figure 4.8: RBAC entities for the example scenario

In Figure 4.8, you can find an example solution that illustrates what entities you need to create and configure from development until role assignment. The developers created application security descriptors based on the requirements to include scopes such as Display, Edit, and Delete. Here, they followed a typical approach, although they could have also created two scopes for each application. For the second application, they also defined an attribute to fulfill the requirement (Refer to the first sub-point for step 3 in the preceding example). When these applications are deployed, for the first application, the roles are automatically generated. However, the roles for the second application need human intervention so that the team attribute can be configured. Here, administrators have the option of assigning static values and creating several roles for each value option. This would be fine if the variations were limited. However, in our example, they decided to make this flexible and link the attribute to the team information coming from the IdP. This way, they do not need to create a separate role for each team. Next, the administrators created two role collections for each persona: Officer and Senior Officer. Finally, they assigned the role collections to users as per their job titles.

For the services you onboard, the first part of the story is not in your control. After you subscribe to the service or create the service instance, the roles and role collections will appear in your subaccount. For example, in Figure 4.9, you can see the overview screen for the Launchpad_Admin role collection that SAP BTP delivers as part of the Launchpad service:

Figure 4.9: The Launchpad_Admin role collection for the Launchpad Service

Let’s list what we can see in the preceding screenshot:

• The Launchpad service delivers four roles attached to the two applications that run the service.
• Under the Users section, you can see that there are two users to whom this role collection is assigned. You can also see that the users are controlled by different identity providers, one by Azure AD, and the other by the default identity provider, that is, the SAP ID service.
• When a user authenticates via an identity provider, it can send group information to which the user belongs. These groups and assignments are managed in the IdP. With the configuration under the User Groups section in the screenshot, it’s made sure that if, for a user, the IdP response includes the information that the user belongs to the aadgrp-sapbtp-launchpad01-admin group, that user will be automatically assigned this role collection in SAP BTP.
• Similar to the user groups, other attributes sent by the IdP can also be used for automatic matching. However, in this example, this feature is not used.

Finally, let’s touch upon the administration roles. These are the roles that are delivered with the platform and can be assigned to administrators who manage global accounts, directories, subaccounts, and other platform elements such as destinations and connectivity configuration. As you would expect, when SAP provisions your SAP BTP global account, they add at least one user you designated as a global administrator.

Identity lifecycle management

In order to run the IAM processes, you need to persist identity information in a user store and manage the lifecycle of identities. The identity lifecycle is handled differently depending on the type of end users accessing an application:

• Applications used by the internal users of a company, such as employees and contractors
• Applications used by external users, for example, customers

Traditionally, IAM would cover the capabilities for the first application type. However, as the applications created for customers became more and more sophisticated, now IAM also covers the second application type. And in this latter case, the framework is also referred to as Customer Identity and Access Management (CIAM). In Figure 4.10, you can see the differences in identity lifecycle management for the two types of applications:

Figure 4.10: The identity life cycles for different types of users

As you can see in the preceding diagram, the main difference between the two lifecycle management approaches is who controls the identity events. In customer applications, customers themselves register to applications, whereas for internal users, the control is within an identity and access governance framework.

SAP has a SaaS offering, SAP Customer Data Cloud, that handles all CIAM aspects, including customer identity lifecycle management. As it’s a different solution, we will not discuss it in this book.

To manage the identity lifecycle for a company’s internal users, you can use the SAP Cloud Identity Services – Identity Provisioning service. This service reads identity data from a user store; generally, this is an HR system that acts as a single source of truth for employee data, such as SAP SuccessFactors. Identity Provisioning can then, optionally, send the identity data to a target system after transforming, filtering, and enriching it:

Figure 4.11: SAP Cloud Identity Services – Identity Provisioning

As you can see in Figure 4.11, you can use this service to provision user and role information to and from several types of on-premise and cloud systems. In addition, systems that are not explicitly supported with a specific connector can be integrated, given that the system implements the System for Cross-Domain Identity Management (SCIM) standard.

Suppose you have multiple source systems, for example, SAP SuccessFactors for employees and SAP Fieldglass for contingent workers. In that case, you can use the Master Data Integration (MDI) service to orchestrate the flow of identity data. Here, the identity data from source systems is replicated to MDI, and it acts as the source system for the Identity Provisioning service. For sophisticated orchestration requirements, you can also use SAP Integration Suite.

Identity provisioning is an area where you can easily harness the benefits of automation. For example, using the Identity Provisioning service, you can schedule jobs to synchronize identity data among systems with delta or full loads. This will ensure timely operations for joiners, movers, and leavers.

Let’s discuss a specific risk scenario where we can make use of identity services to remove the risk. Suppose John has access to several SaaS applications within your company. One day, he finds a new job at a competitor company and leaves your company. After some time, he realizes he can still log in to the marketing cloud system where he can see your company’s marketing plans. Surely, this is a big problem. So, what precautions would you take to remove this risk? Consider the following:

• You should establish a process, preferably automated, so that all the user accounts of a leaver are immediately deactivated after they leave.
• Identity federation and SSO function as a stopgap if the user account deactivation process is delayed. This is because processes for IdPs are deemed a priority and happen much faster. By deactivating John’s user in the IdP, you ensure he cannot access any systems that rely on the IdP for authentication. In addition, with SSO, he would never need to have a password to access the systems. So, after leaving, he will not have the option to log in with a password.

We now know how to manage the identity lifecycle safely; however, there is more to this if you want to add extra governance features, and that is the next topic we will discuss.

Governing identity access

With thousands of users and so many roles, enterprises have additional IAM requirements for introducing streamlined governance, efficiency, and additional guardrails. You can see some of these features in Figure 4.12.

SAP’s solution for these requirements is SAP Identity Access Governance (IAG). This solution is not part of SAP Cloud Identity Services, and SAP offers it as a separate product. However, it works well when integrated with SAP Cloud Identity Services.

If you had similar access governance requirements for your on-premise SAP systems, you might already have SAP Access Control (AC), which is part of the SAP Governance, Risk, and Compliance (GRC) suite, in your landscape. Additionally, if you have well-established SAP AC processes, such as access request workflows, you might want to keep these and adopt SAP IAG for your cloud solutions. In that case, you can use SAP IAG Bridge, which allows you to run access request workflows for cloud applications in SAP AC, whereas SAP IAG handles mitigation controlling and provisioning:

Figure 4.12: SAP IAG features

While facilitating the capabilities in the preceding diagram, SAP IAG lets you apply changes to a user’s roles. In such cases, SAP IAG uses SAP Cloud Identity Services – Identity Provisioning to synchronize identity data.

Audit logging

We can consider audit logging as a surveillance mechanism. It doesn’t directly improve a system’s security. However, it helps with the retrospective analysis of security events when they happen, and it might have a dissuasive effect on potential perpetrators. As a user of your company’s IT applications, you agree with your company’s terms of use, and you are accountable for how you use these applications.

For traceability of changes to important data entities, applications also record information regarding who created and changed database records and when. However, you cannot establish full accountability without storing data on other significant events generally linked to security or identity operations, such as logins, user information updates, role assignments, security setting changes, and more. Because audit logs can be used as evidence, for example, for legal purposes, they have to be persisted as immutable records. SAP Audit Log service stores all such information resulting from the consumption of SAP BTP services. At the time of writing, this service doesn’t support logging functions for custom applications.

The SAP Audit Log service retains the logs for 90 days, after which they are deleted. To retrieve the audit logs, there are multiple options to choose from:

• You can view the audit logs using the Audit Log Viewer service that presents the log entries with a user interface.
• You can retrieve the audit logs using the Audit Log Retrieval API.
• You can request audit logs by creating a support ticket.

To better use audit logs, you can also replicate them in SAP Enterprise Threat Detection or a Security Information and Event Management (SIEM) system such as Azure Sentinel, IBM QRadar, Exabeam Fusion, and Splunk:

Figure 4.13: Integrating SAP BTP audit logs with Azure Sentinel

IAM in hybrid environments

Although moving to the cloud has been the trend in the last decade, many companies still have on-premise SAP systems in their IT estate. This brings extra challenges when designing solutions. With this in mind, SAP’s cloud identity solutions cater to hybrid environment requirements:

• SAP Cloud Identity Services – Identity Authentication supports identity federation with on-premise IdPs such as Microsoft ADFS. In addition, since it implements the SAML 2.0 standard, it can also provide authentication and SSO functionality to SAP NetWeaver systems where users access applications using the WebGUI (SAP GUI for HTML).
• SAP Cloud Identity Services – Identity Provisioning supports on-premise systems as source and target systems, such as SAP S/4HANA On-Premise, SAP NetWeaver ABAP (including SAP AC and SAP Identity Management), and Microsoft Active Directory.
• SAP IAG can coexist with the on-premise SAP AC and extend its use to the cloud using the SAP IAG Bridge.

We have covered a lot in terms of IAM, how it helps secure your SAP BTP applications, and how you can implement its processes using SAP solutions. Next, we will talk about connectivity, which inherently requires strict security.

Connectivity

Infrastructure connectivity is a significant element in IT as operations can only continue with several technical components communicating with each other. Furthermore, with recent IT trends, the IT estates of companies have become far more modular in terms of the variety of solutions used. Also, almost all large companies have hybrid environments due to the hosting options that came with the cloud movement, that is, on-premise versus the cloud.

The connectivity aspect adds a new dimension to security considerations as you need to make sure the communication is kept secure. When architecting solutions with SAP BTP, the essential technical elements that underpin the connectivity are generally already in place, for instance, your networking infrastructure, network security standards, and more. You need to build on top of this foundation. Let’s start with the challenge of establishing secure connectivity between SAP BTP and on-premise.

Connecting SAP BTP and on-premise systems

Moving entirely to SaaS is not an easy target for large enterprises, and there will be a long transitional period until that becomes a reality. For some of them, having on-premise software might stay inevitable for an indefinite period. Before causing any confusion, let’s make one thing clear. Earlier, we intentionally called it on-premise software to consider the case of running on-premise software on IaaS together with running the software in your own data center. In both cases, you need to set up the connectivity below the application layer. It would be a fair assumption that, in both cases, your systems are behind a network security layer, for example, firewalls, IaaS security elements, and more. So, from now on, when we say an on-premise, it can be either an on-premise software deployed in a hyperscaler IaaS or in any other data center, including a corporate’s own data centers.

If these were just two on-premise systems to connect, you would make arrangements in the network components to allow communication between them. SAP BTP service endpoints are mostly open to the public internet. Some services, such as SAP HANA Cloud, provide you with security features such as IP allowlists. With them, you can define the IP ranges you allow to send traffic to the service endpoints of SAP HANA Cloud. You still have the option to allow all IPs, which makes the service publicly connectable. You do not have access to the layers below the application layer to make any network arrangements. And, for outbound traffic from SAP BTP, there is virtually no limitation.

Connectivity service

On the SAP BTP side, the cloud applications can use the Connectivity Service to establish and manage the connectivity with the backend systems. The Connectivity service provides an HTTP proxy that receives requests from cloud applications and forwards them to the SAP Cloud Connector. As a reusable service, applications are required to be bound to a Connectivity service instance to obtain the necessary information to interact with the proxy, such as a hostname, a port number, or any internal authentication details.

SAP Cloud Connector

When it comes to on-premise, things get a bit complicated. That is because you have complete control over how to expose your systems, and your approach will be selectively allowing access to ensure security. For example, you could open your firewalls to allow traffic from relevant SAP BTP IPs. However, your security team could raise concerns as this might be an extensive range of IPs, and it will be coming from a platform that is open to the internet.

SAP provides a solution that minimizes security risks when connecting SAP BTP and on-premise systems. SAP Cloud Connector functions as a link between SAP BTP and on-premise by creating a secure tunnel with the reverse proxy technique. In this approach, on-premise systems initiate the connection; hence, there is no need to add firewall rules for inbound connectivity from the internet to the on-premise systems. Here, the Cloud Connector must be able to access SAP BTP, which is allowed to make outbound connections through the proxy if you have one. Also, the Cloud Connector must have direct access to the on-premise systems.

The connectivity is not immediately in action just after you install the Cloud Connector. As you would expect, it gives you the control to configure which on-premise systems and which resources in those systems are accessible from SAP BTP. On the on-premise side, you can connect SAP BTP to any SAP or non-SAP backend system. However, for the cloud side, only SAP BTP and S/4HANA Cloud are supported. The connectivity is supported for the HTTP, LDAP, RFC, and TCP protocols, including their secure variants:

Figure 4.14: Connectivity between SAP BTP and on-premise systems with SAP Cloud Connector

As you can see in Figure 4.14, there are different constraints for the directions of the flows. The connectivity options are pretty flexible for communication from the cloud to the on-premise systems; this is primarily because TCP is supported. However, with great flexibility comes great responsibility. So, make sure the use case is justified and discuss it with your security and network teams if you are in doubt.

Only a limited number of connectivity options exist for communication from the on-premise systems to the cloud, and the arrangements for this direction are called service channels. Assuming you are using the newest SAP HANA Cloud and multi-environment, the only relevant option is to connect via RFC to ABAP systems in the cloud, including SAP S/4HANA Cloud:

Figure 4.15: The SAP Cloud Connector overview page

In Figure 4.15, you can see the overview page of our example Cloud Connector setup. Here, we have configured one of the subaccounts in our trial account. You can add several subaccounts as required. On the other hand, you can also connect multiple Cloud Connector instances to a subaccount. In that case, you would need a stable handle to identify the specific Cloud Connector instance, and you can use the Location ID property of the instance for this.

In Figure 4.16, you can see our configuration defining a connection from the SAP BTP subaccount to an on-premise S/4HANA system. There are two important things to note here:

• You need to explicitly indicate which resources are accessible from SAP BTP by providing their URL paths for HTTP(S)-based connections and providing the function module names for RFC-based connections. It might be a good idea to be restrictive here, depending on your security needs. In our example, as shown in Figure 4.16, we configured SAP BTP to only have access to the resources served at the /sap/opu/odata/ URL and all its sub-paths.
• You can assign a virtual hostname and port number that are different from the actual hostname and port number. This way, you can conceal this information for increased security. In our example, we defined the virtual hostname as dev.s4h.acme and the virtual port number as 1234:

Figure 4.16: A SAP Cloud Connector cloud to on-premise connection example

Other administration-related features are listed as follows:

• You can establish high availability by installing a shadow instance to which the master instance automatically synchronizes the configuration.
• You can establish the monitoring of Cloud Connector with SAP Solution Manager.
• You can set the logging level, which also records audit logs.
• You can monitor the Cloud Connector instance using its UI or via its monitoring APIs. In addition, SAP BTP Cockpit has a Connectivity page that shows all Cloud Connector connections and their statuses.

Other connectivity options

Typically, SAP Cloud Connector is the most reasonable way to establish backend connectivity for SAP BTP. However, you can also consider other options for specific cases, knowing that they might require extra administration and possibly have more security concerns to remediate. For example, the usual reverse proxy setup can be used where the connection from SAP BTP, hence, the internet, is received by the proxy and forwarded to your on-premise systems.

Connectivity options other than SAP Cloud Connector can be preferred in some other cases where broader connectivity is required. For instance, for the customers who onboarded SAP Data Intelligence at an early stage, the primary option was to set up a secure VPN connection between SAP Data Intelligence and the customer’s on-premise boundary. This connectivity is still the option to connect SAP Data Intelligence to the private endpoints within your corporate’s security perimeter.

For Kubernetes environments, you can use the Connectivity Proxy that works together with the Cloud Foundry Connectivity service and the UAA service to enable access to on-premise systems via the Cloud Connector.

Destination service

To make an application communicate with another application, you need to provide information that specifies the connection destination. This information can be separated into three groups: the URL of the destination, the authentication details, and the other connection properties.

You can use the Destination service to store destination configurations safely, which also brings extra benefits:

1. The Destination service formalizes how destinations are specified. By this, it encourages consistency in using destination configurations.
2. By externalizing the destination configuration, you can use it in multiple places while managing it centrally. For instance, if you need to change a destination configuration, you will not need to change and deploy the applications using it.
3. It introduces development efficiency by undertaking some authorization flow tasks where applicable. For example, it handles automatic OAuth2 token retrieval, building SAML assertion, caching tokens, and refreshing them. It also stores the artifacts, for example, certificates, for trust setups.
4. It increases security so that sensitive information, such as passwords, is stored securely.

You can configure destinations at the subaccount level or the service instance level. For subscribed applications, you can also define destinations pointing to service instances so that the provider application can access service instances in your subaccount.

SAP BTP Cockpit provides a page where you can maintain destination configurations and other relevant elements. Alternatively, you can use the Destination service APIs, arrange your application’s MTA descriptor that will deploy destinations via the Generic Application Content Deployment protocol, or provide the configuration in JSON format while creating a Destination service instance:

Figure 4.17: An example on-premise destination configuration

You can use the Destination service after binding an instance of it to your application. Using this instance, you can call the Destination service functions to retrieve static information about a destination’s configuration along with information that the service generates, such as authentication tokens.

With the Destination service, it is also possible to configure on-premise destinations, as shown in Figure 4.17. For this, the configuration should include the proxy type as On-Premise and contain the URL with the virtual host and port details specified for the backend system in the Cloud Connector. Here, the protocol in the URL will be HTTP or RFC with no secure variants as the communication will be through the already established secure TLS tunnel.

For the cloud destinations, you need to set the destination proxy type to Internet. If your application is connecting to a cloud destination, you do not need to use the Connectivity service. With the information you obtain from the Destination service, you can call external cloud services, provided that you take care of other aspects, such as CORS for UI applications, by using the application router.

Principal (user) propagation

In most cases, when setting connectivity between two applications, the called application will require you to authenticate the request before providing a successful response. In that case, you can configure the connectivity to include an arbitrary user, generally a technical user, and use basic authentication. Then, the called application will happily authenticate the user and respond accordingly. However, what happens if the called application requires the context of the same user?

For instance, Acme developers are building a new Customer Information Management application in SAP BTP. The application lets users maintain customer information by calling OData services from a backend SAP system. Irfan, as a senior customer service representative, can maintain any customer data. Ali, as an apprentice, can maintain all data apart from bank details.

The developers created an on-premise destination, as shown in Figure 4.17. It works fine; however, eventually, they realized that the authorization checks in the backend system were meaningless because the logged-in user was always the technical user, BPINST. Also, the change tracking was not really working because whenever a data record changes, the application had recorded the same technical user as the last changer.

What if they get the user context in the frontend application and hide the bank details fields in the UI? Well, this wouldn’t work because a user can unhide the fields in the browser. So, checks at the frontend layer would never be sufficient.

You can solve this challenge using the principal propagation mechanism supported by the Connectivity service and the Cloud Connector. With principal propagation, the logged-in user of the cloud application is passed on to the Cloud Connector and then to the backend system. Principal propagation requires changes to be applied in the Cloud Connector and the target backend systems. After this setup, if you are using standard tools and libraries for developing cloud applications in BTP, enabling principal propagation is as easy as using a destination with the On-Premise proxy type. Other services such as the SAP Integration Suite service also make use of such destinations to access on-premise backend systems.

Our previous scenario deals with principal propagation for cloud-to-on-premise, which is a typical requirement in hybrid environments. However, principal propagation can also be achieved in cloud-to-cloud scenarios, and we will see the inner mechanics of both in the next section.

The big connectivity picture

We are best situated to view the complete picture of how connectivity happens between an SAP BTP application and an on-premise system with the addition of principal propagation. Surely, we made some assumptions and simplifications when illustrating the following flows. Now, check out Figure 4.18 and fasten your seat belts because this will be a roller-coaster journey:

Figure 4.18: The connection flow from SAP BTP to on-premise with principal propagation

Let’s decipher the diagram in Figure 4.18:

1. The user launches the cloud application.
2. Because there is no secure session, the cloud application forwards the user to the UAA service.
3. Since there is no user context, UAA redirects the call to the IdP and initiates a SAML authentication flow.
4. The IdP challenges the user for the username and password and, upon correct entry, generates a SAML token (authorization response) and responds to the browser with a redirection.
5. The browser sends a request to the UAA service instance and attaches the SAML token.
6. The UAA service extracts the identity information in the SAML token and creates a JWT token (JWT-1), which it returns to the application.
7. Through the Destination service instance binding, the application retrieves the required parameters and calls the UAA service for authorization to access the Destination service instance.
8. The UAA service creates a new JWT token (JWT-2) and returns it to the application.
9. The application calls the Destination service instance after attaching JWT-2 to the request and retrieves the destination information for the on-premise system.
10. Through the Connectivity service instance binding, the application retrieves the required parameters and calls the UAA service for authorization to access the Connectivity service instance.
11. The UAA service creates a new JWT token (JWT-3) and returns it to the application.
12. The application retrieves the HTTP proxy details through the Connectivity service instance binding and creates an HTTP client. Then, it makes a request for the on-premise resource while attaching both JWT-1 and JWT-3 tokens.
13. The Connectivity service (HTTP proxy) forwards the request to the Cloud Connector through the secure TLS tunnel and attaches the JWT-1 token.
14. The Cloud Connector checks the request, that is, whether it’s for a valid backend system and allowed resource, extracts identity information, and asks its security token service for a new token.
15. The Cloud Connector can, optionally, use SAP SSO Secure Login Service to retrieve the token.
16. The Cloud Connector can, optionally, use a Kerberos Key Distribution Center to retrieve the token.
17. The security token service creates a new token, such as a short-lived X.509 certificate, which includes identity information according to the Cloud Connector’s principal propagation settings.
18. The Cloud Connector forwards the request to the backend system, attaching the X.509 certificate.
19. The backend system verifies the certificate, extracts identity information, and allows access to the resource with the propagated identity. Then, it responds to the Cloud Connector’s request.
20. The Cloud Connector responds to the Connectivity service’s (HTTP proxy) request through the secure TLS tunnel.
21. The application receives the response from the on-premise backend system resource.
22. Optionally, monitoring information flows to SAP Solution Manager.
23. During the flow, the Cloud Connector creates logs for troubleshooting and auditing purposes based on the logging level setting.

Now, let’s do the same for a cloud-to-cloud principal propagation scenario where an SAP BTP application consumes another cloud resource, which can also be another SAP BTP application. For this type of flow, typically, you can use a destination whose authentication type is set to OAuth2SAMLBearerAssertion. Let’s explain the flow depicted in Figure 4.18:

1. – 8. The same as the cloud-to-on-premise scenario above.

9. The application makes a call to the Destination service after attaching both JWT-1 and JWT-2 tokens.

10. The destination service extracts the identity information and generates a SAML assertion, which it signs with the subaccount’s private key. Then, it sends a request to the OAuth2 token service as configured in the destination specification and attaches the SAML assertion to the request.

11. The OAuth2 token service verifies the SAML assertion and, upon successful verification, responds with an access token.

12. The Destination service returns to the application the destination specification and the access token.

13. The application makes a call to the resource URL and attaches the access token.

14. The external resource verifies the access token and responds to the request.

Figure 4.19: The connection flow from SAP BTP to another cloud application with principal propagation

For both flows, if you remove the principal propagation, the application won’t need to pass on the JWT token identifying the user to the respective service. Instead, an authorization header as per the destination’s authorization type will be sent with the request.

Important Note

Again, let’s remind you that you can develop your application by focusing on what differentiates it and delegating most of the preceding tasks to standard frameworks and libraries that hide the complexity.

Well, by learning the two preceding scenarios, you are now familiar with how connectivity works in SAP BTP. Now, let’s discuss the last topic of this chapter.

Private Link service

Many enterprises work with at least one of the IaaS providers that lead the market, for example, Amazon, Microsoft, and Google. Therefore, providing secure and efficient connectivity within their platforms alongside customers’ on-premise systems is important for these hyperscalers. Because SAP BTP runs on the infrastructure from these providers, under the hood, it can make use of the services hyperscalers offer.

Some IaaS providers offer a capability that enables access to the resources of certain services through a designated private endpoint created in your own virtual network; for example, Azure Private Link and AWS PrivateLink. Accessing the service via this private endpoint ensures the traffic from your virtual network to the target resource travels through the provider’s backbone network. The connectivity can be established with two types of targets:

1. To one of the provider’s PaaS services
2. To your own services, for instance, an SAP or non-SAP system running in VMs on the provider’s infrastructure

Let’s take Azure Private Link as an example. For the first use case, you simply need to create a private endpoint that targets the required PaaS service instance. For the second use case, you can expose your service through an Azure Private Link service instance, provided that the system is behind a standard load balancer.

SAP BTP’s Private Link service leverages the second use case that is mentioned. For example, if you have such a system running in your own Azure virtual network, you can create an Azure Private Link service instance that is attached to the load balancer of that system. Then, you can create a Private Link service instance in SAP BTP, which, under the hood, creates a private endpoint within your subaccount that points to the Azure Private Link service instance. After this setup, you can bind your applications and use the private endpoint. This way, you ensure the traffic is isolated from the internet. Take a look at Figure 4.19, which illustrates this setup:

Figure 4.20: Accessing resources on Microsoft Azure via the Private Link service

Just to note, at the time of authoring this book, this service only supported a limited set of hyperscalers and regions. So, please check the SAP roadmap to find out more about it and whether it is available for production use.

Summary

Well, this concludes our discussion on security and connectivity. Later in this book, we will continue touching upon security topics from different angles. However, what we have discussed so far should enable you to incorporate security in your SAP BTP architecture designs as a crucial ingredient.

In this chapter, you learned how SAP, as its provider, ensures the security of SAP BTP and how you can find out more about their compliance with the standards underpinning the security measures they apply. Because, as the consumer, you share the responsibility for securing the application and data layers, we discussed how you could achieve this when building your custom applications and when using SAP BTP services. As a closely related topic, we talked about data protection and privacy. Additionally, a large part of this chapter was about IAM. We briefly discussed IAM concepts at the generic level and then how SAP BTP implements its processes. Finally, we covered how SAP BTP securely connects to external systems and propagates user information.

In the next chapter, we will look at several design aspects that are grouped as non-functional design elements and constitute an integral part of your solution/technical designs.