This blog is part of a five-part series. I recommend starting here: Enterprise Security Services – Security for the Cloud Age.
Secure Development Services are important for developers and administrators. Some of the topics I will cover here are quite specific, such as CAP (SAP Cloud Application Programming Model), but don’t let that deter you – secure development is at the very core of secure business operations, and this blog will give you an idea of the overall concept.
Let us be honest – most of us who develop applications don’t design them with security in mind. First, we want to prove the feasibility of our idea and only if we succeed, we start thinking about enterprise-grade capabilities. Security is one of these. That’s also the point in time when a local web server is no longer sufficient. Developers need a platform which is ready for enterprise-grade business applications. Let me explain howSAP Business Technology Platform can help you with this challenge.
Let us start with SAP’s Cloud Application Programming Model (CAP). SAP Business Technology Platform is, as the name implies, a platform, so for a developer, many paths lead to Rome. It depends on their mindset:
CAP is designed for business developers. It provides much more than security, but I will focus only on the security content. CAP is an opinionated programming model, which means that SAP provides a recommendation for developing on SAP Business Technology Platform. It is mainly about topics like security, localization, domain modelling, languages, libraries, and tools. CAP supports you in developing enterprise-grade services and applications.
Business developers often start to design the data model and then they continue with the fancy parts such as the user interface. It’s also possible to model authorizations during design time and enforce them during runtime (via authorization service).
So which capabilities does it offer for security?
What are the advantages?
If you are familiar with development on SAP Business Technology Platform you’ll know the service.cds file. Core Data Services (CDS) is a language that is close to the conceptual thinking of domain experts. Every active thing in CAP is a service. If you want to make a service available, you define this in the services.cds file. Right at this point, you can now also define the authorizations.
Below an example out of the official documentation
The CustomerService is defined as a (backend) service. With the help of the “requires“ key word, you can enforce that only authenticated users are allowed to access the service. The keyword “restrict” allows fine-grained control through an array of privileges given as grant statement. In this example only an admin can READ and WRITE all orders. All authenticated users can READ data, but only if their user is maintained in the related column buyer.
What about the permissions in the user interface (UI)? Take the example of an SAP UI5 application and the backend service above. The rendering of the user interface happens on the end user device. SAP UI5 is a set of client libraries which can be used to develop a dynamic user interface in JavaScript. If the user interface requires data from the backend, it calls an OData Http request against the service with the user token of Identity Authentication. So, the authorizations defined above are only related to the backend, the user interface does not know the service definition. Any special restriction on the UI level (enable a button) must be implemented on the UI. So a user could see an empty table because the UI allows it from a permission point, but the backend does not allow the user to access the data.
Links
CAP: https://cap.cloud.sap/docs/guides/authorization
SAP Cloud Connector serves as a link between SAP Business Technology Platform applications and on-premise systems. Existing on-premise data can be reused without exposing the entire internal landscape. SAP Cloud Connector provides a fine-grained control over the resources. The SAP Cloud Connector itself will be installed on-premise, so you have full control over what happens in your on-premise SAP systems. Furthermore, the connection will be established from on-premise to SAP Business Technology Platform. This offers the advantage that you do not have to open an additional incoming port. The counter part on the SAP Business Technology Platform side is the Connectivity Service. The next chapter will focus more on the Connectivity Service.
SAP Cloud Connector technically acts as a reverse invoke proxy and automatically recovers broken connections. It provides a tunnel connection to an existing SAP Business Technology Platform subaccount and can be used with multiple SAP Cloud environments. It is also possible to set up the SAP Cloud Connector in high-availability modus.
Changes of the configuration and inbound traffic metrics are logged (audit logging), and you can use the auditor tool to view and manage audit log information. You can also monitor the activities and state.
SAP Cloud Connector also offers principal propagation. It manages the authentication process of an identity between systems. The identity authenticates itself via Identity Authentication as part of the SAP Identity Services.
Links
Cloud Connector Help Landing Page https://help.sap.com/viewer/cca91383641e40ffbe03bdc78f00f681/Cloud/en-US/e6c7616abb5710148cfcf3e75d9...
Cloud Connector Operations https://help.sap.com/viewer/cca91383641e40ffbe03bdc78f00f681/Cloud/en-US/dfec06d670ff4e2e938d9fdd985...
Cloud Connector Security https://help.sap.com/viewer/cca91383641e40ffbe03bdc78f00f681/Cloud/en-US/cb50b6191615478aa11d2050dad...
SAP Business Technology Platform Connectivity provides two services, the Connectivity Service and the Destination Service. The Connectivity Service contains a connectivity proxy, which is used to access on-premise resources. The Destination Service can be used to retrieve and store the technical information about the target resource.
You can maintain destination information for connecting your application to any other web application. The most prominent is of course the integration with other SAP Cloud solutions. See the picture below:
You can also use the Connectivity Service to connect to an on-premise system. The picture should be familiar to you from the SAP Cloud Connector section.
Another feature is the retrieval of technical information about the destination via the Destination Service, which is required to use the Connectivity Service. In addition, you can also manage certificates for the destinations.
Key features
Links
Help.sap.com https://help.sap.com/viewer/cca91383641e40ffbe03bdc78f00f681/Cloud/en-US/34010ace6ac84574a4ad02f5055...
Custom Domain allows you to make your SAP Business Technology Platform applications accessible via an individual domain, which is different from the default one (hana.ondemand.com). It also provides a self-service for managing the related certificates and trust. You can also integrate your own PKI solutions, so it is not limited to a specific trust center. Furthermore, you have full control over the private key and certificate lifecycle.
Note: Using custom domains and dedicated TLS server certificates can be a compliance requirement for regulated markets or business areas.
Below are the key features of the service:
Links
Support guided answers https://gad5158842f.us2.hana.ondemand.com/dtp/viewer/#/tree/2437/actions/32393/?version=current
SAP Business Technology Platform Credential Store provides a secure repository for passwords and keys for applications that are running on SAP Business Technology Platform. It enables applications to retrieve credentials and use them for authentication to external services, or to perform cryptographic operations and TLS communication.
Key capabilities
Use case: Use secure credentials within SAP Business Technology Platform – no passwords in your code
Maintain the credentials in Credential Store
You can also use Credential Store via Rest API, if you want to call any external services with basic authentication. But you should always choose Security Tokens like OAuth for system-to-system authentication/authorization. Only if there is no option to do so, the REST API is a solution to use basic authentication with no password in cleartext in your code.
Links
Help.sap.com https://help.sap.com/viewer/product/CREDENTIAL_STORE/Cloud/en-US
SAP currently provides SAP Audit Log version 2.0 as part of SAP Business Technology Platform. SAP Audit Log is about the collection of the audit logs. It is not about the management of the audit process itself (SAP Audit Management). In the current version only SAP Cloud applications can write in the audit log and the platform itself.
There is currently the following functionality available as a developer/administrator
The Audit Log Viewer displays the audit logs for your account, produced by SAP applications and services you’ve subscribed to. The Audit Log Retrieval API allows you to retrieve the audit logs and provides the results as a collection of JSON entities. The standard retention time is 30 days.
Well, this doesn’t really help you with your own application, but we’re just getting started. Stay tuned for an update in Q3 2020!
Authorization Service is the central service in SAP Business Technology Platform for authorization. It allows to confine access to eligible persons or system users. Primary use case are the authorization of business users and system-to-system authorization/authentication. This Authorization Service is also known as XSUAA (eXtended Service UAA).
Many things are happening under the hood when you use SAP Business Technology Platform. I would like to mention the two main uses cases of the Authorization service:
Authentication of a business user with subsequent system-to-system communication
Let us start with the picture below. You are a developer deploying an application on SAP Business Technology Platform.
Notes
Now let us look at the example from a developer view. To enable the application router, there’s a file called package.json in your project. This defines how to start your application.
package.json
{
"name": " employeeData-approuter", "dependencies": { "@sap/approuter": "X.X.X" }, "scripts": { "start": "node node_modules/@sap/approuter/approuter.js" }
}
Then you tell the application router in the xs-app.json file of your project to enforce authentication/authorization based on the Authorization Server (XSUAA).
In your xs-app.json file you also define scopes and role templates. Scopes cover business users’ authorizations in your application, but on a very detailed level (examples: edit table, see table…). Then the developer groups them into role templates – these role templates should be consumable for an administrator (access application with manager privileges). Now the administrator creates role collections in SAP Cloud Cockpit and assigns the available role templates to these role collections. The last step is the assignment of a role collection to a user.
There are two options to assign role collections to a user
Instance-based authorization is also possible. This authorization is based on user attributes (for example country: a user from Germany should only see the data of the German subsidiary). The concept is similar, but I wanted to keep the picture below as simple as possible.
All this might seem a bit complex to you Yes, it is. But SAP Business Technology Platform provides tools for it. I wanted to explain the overall concept, leaving out details and exceptions. But in case something is not working, it is good to know the files you should look at. And there are of course the developers who like to do everything from scratch.
Which tools? There is the SAP Web IDE and its successor, the SAP Business Application Studio. Both solutions help you maintain the security files without knowing the exact syntax. There is also CAP – you can find more about it in this blog. In CAP, you design your authorizations and it automatically generates the file xs-security.json for you.
Ok, let me recap all the learnings in this long blog:
A business user wants to access your application. The single point of entry is the application router. The application router enforces an authentication by the business user and sends it to the Authorization Service. The Authorization Service is not designed to authenticate business users, so it forwards the request to SAP Cloud Identity Services. SAP Cloud Identity Services creates an SAML ticket which also contains the list of assigned user roles. The web browser sends this new SAML ticket to the Authorization Service for authentication. The Authorization Service generates an OAuth token, adding the authorization information and then sends it to your application.
Now you might ask why can’t we just use SAML and skip OAuth? The open standard SAML is designed for authentication with a web browser as a client. So, if we would like to use SAML end-to-end, all your backend applications would have to act like a browser. Believe me, you do not want this. Furthermore, OAuth is much more lightweight and an ideal fit for system-to-system communication. SAML requires more steps for an authentication, but it is an establish standard for end user authentication in enterprises. This also makes sense since security measures, requirements and the architecture of web browsers are different compared to a system-to-system communication.
The next picture is just a more complex scenario:
Links
Tutorials https://github.com/SAP-samples/teched2019-cloud-cf-product-list
Help.sap.com https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/ea0281368f11472b8d2b145a2a2...
Blog https://blogs.sap.com/2017/11/16/guide-for-user-authentication-and-authorization-in-sap-cloud-platfo...
NAVIGATE BACK TO ENTERPRISE SECURTIY SERVICES
Secure Development Services are important for developers and administrators. Some of the topics I will cover here are quite specific, such as CAP (SAP Cloud Application Programming Model), but don’t let that deter you – secure development is at the very core of secure business operations, and this blog will give you an idea of the overall concept.
Let us be honest – most of us who develop applications don’t design them with security in mind. First, we want to prove the feasibility of our idea and only if we succeed, we start thinking about enterprise-grade capabilities. Security is one of these. That’s also the point in time when a local web server is no longer sufficient. Developers need a platform which is ready for enterprise-grade business applications. Let me explain howSAP Business Technology Platform can help you with this challenge.
SAP Cloud Application Programming Model (CAP)
Let us start with SAP’s Cloud Application Programming Model (CAP). SAP Business Technology Platform is, as the name implies, a platform, so for a developer, many paths lead to Rome. It depends on their mindset:
- Freestyle developers love to do everything from scratch, no restrictions please…
- Business developers integrate into the existing SAP user experience, focus on operational costs and enterprise qualities
CAP is designed for business developers. It provides much more than security, but I will focus only on the security content. CAP is an opinionated programming model, which means that SAP provides a recommendation for developing on SAP Business Technology Platform. It is mainly about topics like security, localization, domain modelling, languages, libraries, and tools. CAP supports you in developing enterprise-grade services and applications.
Business developers often start to design the data model and then they continue with the fancy parts such as the user interface. It’s also possible to model authorizations during design time and enforce them during runtime (via authorization service).
So which capabilities does it offer for security?
- Automatic authorization enforcement in the CAP-supported runtimes Node.js and Java
- No manual coding of permissions checks required because it is automatically enforced during runtime
- Developers can still implement individual permission checks
What are the advantages?
- Easy review of the permission
- Understand old code and related permissions quicker
- Reduce mistakes on code level by modelling authorizations during the design phase
If you are familiar with development on SAP Business Technology Platform you’ll know the service.cds file. Core Data Services (CDS) is a language that is close to the conceptual thinking of domain experts. Every active thing in CAP is a service. If you want to make a service available, you define this in the services.cds file. Right at this point, you can now also define the authorizations.
Below an example out of the official documentation
service CustomerService @(requires: 'authenticated-user'){
entity Orders @(restrict: [
{ grant: ['READ','WRITE'], to: 'admin' },
{ grant: 'READ', where: 'buyer = $user' },
]){/*...*/}
The CustomerService is defined as a (backend) service. With the help of the “requires“ key word, you can enforce that only authenticated users are allowed to access the service. The keyword “restrict” allows fine-grained control through an array of privileges given as grant statement. In this example only an admin can READ and WRITE all orders. All authenticated users can READ data, but only if their user is maintained in the related column buyer.
What about the permissions in the user interface (UI)? Take the example of an SAP UI5 application and the backend service above. The rendering of the user interface happens on the end user device. SAP UI5 is a set of client libraries which can be used to develop a dynamic user interface in JavaScript. If the user interface requires data from the backend, it calls an OData Http request against the service with the user token of Identity Authentication. So, the authorizations defined above are only related to the backend, the user interface does not know the service definition. Any special restriction on the UI level (enable a button) must be implemented on the UI. So a user could see an empty table because the UI allows it from a permission point, but the backend does not allow the user to access the data.
Links
CAP: https://cap.cloud.sap/docs/guides/authorization
SAP Cloud Connector
SAP Cloud Connector serves as a link between SAP Business Technology Platform applications and on-premise systems. Existing on-premise data can be reused without exposing the entire internal landscape. SAP Cloud Connector provides a fine-grained control over the resources. The SAP Cloud Connector itself will be installed on-premise, so you have full control over what happens in your on-premise SAP systems. Furthermore, the connection will be established from on-premise to SAP Business Technology Platform. This offers the advantage that you do not have to open an additional incoming port. The counter part on the SAP Business Technology Platform side is the Connectivity Service. The next chapter will focus more on the Connectivity Service.
SAP Cloud Connector technically acts as a reverse invoke proxy and automatically recovers broken connections. It provides a tunnel connection to an existing SAP Business Technology Platform subaccount and can be used with multiple SAP Cloud environments. It is also possible to set up the SAP Cloud Connector in high-availability modus.
Changes of the configuration and inbound traffic metrics are logged (audit logging), and you can use the auditor tool to view and manage audit log information. You can also monitor the activities and state.
SAP Cloud Connector also offers principal propagation. It manages the authentication process of an identity between systems. The identity authenticates itself via Identity Authentication as part of the SAP Identity Services.
Links
Cloud Connector Help Landing Page https://help.sap.com/viewer/cca91383641e40ffbe03bdc78f00f681/Cloud/en-US/e6c7616abb5710148cfcf3e75d9...
Cloud Connector Operations https://help.sap.com/viewer/cca91383641e40ffbe03bdc78f00f681/Cloud/en-US/dfec06d670ff4e2e938d9fdd985...
Cloud Connector Security https://help.sap.com/viewer/cca91383641e40ffbe03bdc78f00f681/Cloud/en-US/cb50b6191615478aa11d2050dad...
SAP Business Technology Platform– Connectivity and Destination Service
SAP Business Technology Platform Connectivity provides two services, the Connectivity Service and the Destination Service. The Connectivity Service contains a connectivity proxy, which is used to access on-premise resources. The Destination Service can be used to retrieve and store the technical information about the target resource.
You can maintain destination information for connecting your application to any other web application. The most prominent is of course the integration with other SAP Cloud solutions. See the picture below:
You can also use the Connectivity Service to connect to an on-premise system. The picture should be familiar to you from the SAP Cloud Connector section.
Another feature is the retrieval of technical information about the destination via the Destination Service, which is required to use the Connectivity Service. In addition, you can also manage certificates for the destinations.
Key features
- Manage HTTP destinations for Cloud Foundry applications in the SAP Business Technology Platform cockpit
- RFC destinations to communicate with an on-premise ABAP system (with Cloud Connector)
- Principal propagation to securely forward cloud users to a back-end system (with Cloud Connector and SAP Cloud Identity Services)
- Manage destinations for multitenancy-enabled applications that require a connection to a remote service or on-premise application
Links
Help.sap.com https://help.sap.com/viewer/cca91383641e40ffbe03bdc78f00f681/Cloud/en-US/34010ace6ac84574a4ad02f5055...
SAP Business Technology Platform - Custom Domain
Custom Domain allows you to make your SAP Business Technology Platform applications accessible via an individual domain, which is different from the default one (hana.ondemand.com). It also provides a self-service for managing the related certificates and trust. You can also integrate your own PKI solutions, so it is not limited to a specific trust center. Furthermore, you have full control over the private key and certificate lifecycle.
Note: Using custom domains and dedicated TLS server certificates can be a compliance requirement for regulated markets or business areas.
Below are the key features of the service:
- Self-service to manage TLS server certificates and the client trust for custom domains
- A CF command line interface (CLI) plugin that provides commands for all required administrative operations
- The service inside the landscape for resilient buffering and commands processing
- The secure generation and storage of cryptographic keys inside the landscape
- PaaS and SaaS custom domain support
Links
Support guided answers https://gad5158842f.us2.hana.ondemand.com/dtp/viewer/#/tree/2437/actions/32393/?version=current
SAP Business Technology Platform - Credential Store
SAP Business Technology Platform Credential Store provides a secure repository for passwords and keys for applications that are running on SAP Business Technology Platform. It enables applications to retrieve credentials and use them for authentication to external services, or to perform cryptographic operations and TLS communication.
Key capabilities
- Use the repository to store cryptographic keys and passwords for business applications in the Cloud Foundry environment
- Retrieve passwords and keys to use them for authentication to external services
- Create and bind service instances by using SAP Business Technology Platformm cockpit or Cloud Foundry command line interface (CF CLI)
- Create a service key if you need to use a service instance from an external application or an application deployed in another space
Use case: Use secure credentials within SAP Business Technology Platform – no passwords in your code
- First you must create an instance of Credential Store, you can have one per space
- Bind a service instance to your application
- Example for bind: cf bind-service myapp my-credstore
- Several properties are available for the application via the VCAP_SERVICES environment variable
- Username
- Private_key
- OAuth_token_url
Maintain the credentials in Credential Store
- Go to SAP Business Technology Platformcockpitand open your account
- Choose the Credential Store tile
- Navigate to the corresponding service instance
- Select Service Keysand choose Create Service Key
You can also use Credential Store via Rest API, if you want to call any external services with basic authentication. But you should always choose Security Tokens like OAuth for system-to-system authentication/authorization. Only if there is no option to do so, the REST API is a solution to use basic authentication with no password in cleartext in your code.
Links
Help.sap.com https://help.sap.com/viewer/product/CREDENTIAL_STORE/Cloud/en-US
SAP Audit Log
SAP currently provides SAP Audit Log version 2.0 as part of SAP Business Technology Platform. SAP Audit Log is about the collection of the audit logs. It is not about the management of the audit process itself (SAP Audit Management). In the current version only SAP Cloud applications can write in the audit log and the platform itself.
There is currently the following functionality available as a developer/administrator
- Audit Log Retrieval API
- Audit Log Viewer
The Audit Log Viewer displays the audit logs for your account, produced by SAP applications and services you’ve subscribed to. The Audit Log Retrieval API allows you to retrieve the audit logs and provides the results as a collection of JSON entities. The standard retention time is 30 days.
Well, this doesn’t really help you with your own application, but we’re just getting started. Stay tuned for an update in Q3 2020!
SAP Business Technology Platform - Authorization Service (XSUAA)
Authorization Service is the central service in SAP Business Technology Platform for authorization. It allows to confine access to eligible persons or system users. Primary use case are the authorization of business users and system-to-system authorization/authentication. This Authorization Service is also known as XSUAA (eXtended Service UAA).
Many things are happening under the hood when you use SAP Business Technology Platform. I would like to mention the two main uses cases of the Authorization service:
- Authorization of business users
- Authentication/authorization of system-to-system communication
Authentication of a business user with subsequent system-to-system communication
Let us start with the picture below. You are a developer deploying an application on SAP Business Technology Platform.
- A business user wants to access your application
- The application router is always the single point of entry to any SAP Business Technology Platform application.
- The application router forwards the request to the Authorization Service (XSUAA)
- Authorization Service forwards the request to SAP Cloud Identity Services, to enforce the business user to authenticate
- If the authentication was successful, the user (web browser of the user) gets a SAML token. This SAML token is used to authentication against Authorization Service. Why this step? Because a business user can use this SAML token to access all configured applications - he is often working on a process which requires to access many systems.
- The Authorization Service generates than an OAuth Token which is technically a JWT token. This JWT token will be used from the application router for your application. It cannot be reused by other applications and is only valid for a very short timeframe.
Notes
- The Authorization Service (XSUAA) is an OAuth server. OAuth is a framework and it does not specify a concrete security token implementation. Authorization Service is an OAuth Server using JWT tokens.
- OAuth is not designed to authenticate business users – it is primary used for system to system authentication/authorization but with a user context
- SAML is used for the authentication via a web browser (SAP Cloud Identity Services). It is an established standard in enterprises and allows a wide range of integration scenarios
- You could replace in this scenario also SAP Cloud Identity Services with an 3rd party SAML Identity Provider. But it makes only sense in a standalone scenario since SAP Cloud Identity Services is the default authentication authority for SAP Cloud applications (SaaS). There is also the option run SAP Cloud Identity Services in a proxy mode. You can check the blog on Cloud Identity Services
- The picture above is simplified. It is not a network diagram with all technical steps behind the scene
Now let us look at the example from a developer view. To enable the application router, there’s a file called package.json in your project. This defines how to start your application.
package.json
{
"name": " employeeData-approuter", "dependencies": { "@sap/approuter": "X.X.X" }, "scripts": { "start": "node node_modules/@sap/approuter/approuter.js" }
}
Then you tell the application router in the xs-app.json file of your project to enforce authentication/authorization based on the Authorization Server (XSUAA).
xs-app.json (extract)
"source": "/employeeData/(.*)",
"target": "/services/employeeService/$1",
"destination": "employeeServices", "authenticationType": "xsuaa",In your xs-app.json file you also define scopes and role templates. Scopes cover business users’ authorizations in your application, but on a very detailed level (examples: edit table, see table…). Then the developer groups them into role templates – these role templates should be consumable for an administrator (access application with manager privileges). Now the administrator creates role collections in SAP Cloud Cockpit and assigns the available role templates to these role collections. The last step is the assignment of a role collection to a user.
There are two options to assign role collections to a user
- Dynamic (federated) with SAP Cloud Identity Services (or another 3rd party SAML IDP). SAP Cloud Cockpit does not know your employee data. This information is available within SAP Cloud Identity Services. There you can also group users. These are the user groups that will be mapped to a role collection
- Static in SAP Cloud Cockpit (for test purposes)
Instance-based authorization is also possible. This authorization is based on user attributes (for example country: a user from Germany should only see the data of the German subsidiary). The concept is similar, but I wanted to keep the picture below as simple as possible.
All this might seem a bit complex to you Yes, it is. But SAP Business Technology Platform provides tools for it. I wanted to explain the overall concept, leaving out details and exceptions. But in case something is not working, it is good to know the files you should look at. And there are of course the developers who like to do everything from scratch.
Which tools? There is the SAP Web IDE and its successor, the SAP Business Application Studio. Both solutions help you maintain the security files without knowing the exact syntax. There is also CAP – you can find more about it in this blog. In CAP, you design your authorizations and it automatically generates the file xs-security.json for you.
Ok, let me recap all the learnings in this long blog:
A business user wants to access your application. The single point of entry is the application router. The application router enforces an authentication by the business user and sends it to the Authorization Service. The Authorization Service is not designed to authenticate business users, so it forwards the request to SAP Cloud Identity Services. SAP Cloud Identity Services creates an SAML ticket which also contains the list of assigned user roles. The web browser sends this new SAML ticket to the Authorization Service for authentication. The Authorization Service generates an OAuth token, adding the authorization information and then sends it to your application.
Now you might ask why can’t we just use SAML and skip OAuth? The open standard SAML is designed for authentication with a web browser as a client. So, if we would like to use SAML end-to-end, all your backend applications would have to act like a browser. Believe me, you do not want this. Furthermore, OAuth is much more lightweight and an ideal fit for system-to-system communication. SAML requires more steps for an authentication, but it is an establish standard for end user authentication in enterprises. This also makes sense since security measures, requirements and the architecture of web browsers are different compared to a system-to-system communication.
The next picture is just a more complex scenario:
- The App Router uses a JWT1 token for authentication/authorization to your application. The user was already authenticated via SAP Cloud Identity Services (same scenario as before).
- Now your application wants to get data from an SAP ABAP on-premise system (Connectivity Service) and an SAP Cloud application (Destination service). You want to reuse the context of the user and not work with a technical user
- Your application requests JWT2 to connect to the SAP Cloud application (Destination service)
- Your application requests JWT3 to connect to the SAP ABAP on-premise system (Connectivity Service)
- The assumption is that the SAP Cloud application accepts the JWT2 token for authentication, so you are fine
- SAP ABAP on-premise does not know OAuth. So, you connect via Connectivity Service to SAP Cloud Connector. The SAP Cloud connector converts the OAuth token in an X.509 certificate which is accepted by the SAP ABAP system.
Links
Tutorials https://github.com/SAP-samples/teched2019-cloud-cf-product-list
Help.sap.com https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/ea0281368f11472b8d2b145a2a2...
Blog https://blogs.sap.com/2017/11/16/guide-for-user-authentication-and-authorization-in-sap-cloud-platfo...
NAVIGATE BACK TO ENTERPRISE SECURTIY SERVICES
- SAP Managed Tags:
1 Comment
