Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
SekhuteTK
Participant
1,528
Trust and believe, nobody’s going to be where they are not supposed to be. Warrants the SAP Authorization and Trust management service. Which its sole mandate is to provide support to your security policies of your organization, permit user authorization and trust to identity providers.

Developers may configure and deploy application-based security artifacts containing authorizations and administrators assign these authorizations using technical roles at the application level, which can be embedded into business-level role collections for large-scale cloud scenarios.

SAP recommends the use of:

  • An Internet Authentication service identity authentication tenant

  • An SAP on-premises system

  • A custom corporate identity provider


 


Figure 1:


Authorization and Trust management service components


Source:  SAP Authorization and Trust Management Service,


https://help.sap.com/docs/BTP/65de2977205c403bbc107264b8eccf4b/649961f8d4ad463daca33b3a20deba4c.html...


 

The Cloud foundry environment, HANA XS Advanced and the Neo environment are runtime platforms for business web applications. The mentioned runtime environments and their associated components follow the loosely coupled architectural style. Allowing the components to be deployed as Microservices independently from one another. This eliminates the need to deploy the complete application if only a subset of its microservices have received new features or bug fix.

SAP Microservices consist of the following and more:

  • Audit Log Service for viewing the audit logs stored for your subaccount.

  • KeyStore Service which provides a repository for passwords and keys for applications deployed on the platform.

  • Malware Scanning Service to scan business documents for malware.



Figure 2:


SAP BTP Neo Microservices


Source: SAP BTP Cockpit, https://account.hana.ondemand.com/#/home/welcome


 

The runtime environments consist of a gateway app with at least one or more resource apps. The gateway poses as a reverse-proxy and provides functionality for security and session management. The App router is a standard implementation of the gateway and is used as the single point of entry into the application.

Additional functionality of the Router:

  • Serves static content

  • Initiates the authentication process

  • Checks on Cross site request forgery (XSRF) attacks



Figure 3:


Application Descriptor file


 

A security descriptor file is a central component for the configuration and maintenance of application security.  The content depicts users’ authorization using:

Scopes which enable you to restrict access to resources based on user permissions specified in role templates. We distinguish between the below mentioned Scopes:

  • View

  • Create

  • Edit

  • Delete


Attributes are used to differentiate between the SAP clients or country codes and Role temple used to build different roles such as:

  • Administrators

  • Developers



Figure 4:


Security Descriptor file


 

The security paradigm followed by the SAP Business technology platform is of the OAuth 2.0 specification. Which defines how:

  • The OAuth 2.0 Resource Owner can delegate all or a subset of the authorizations to a third-party application also known as the OAuth 2.0 Client.

  • The OAuth 2.0 Client contains the entire authorization definition. A set or sub-set of these authorizations is assigned to the user after authentication in the system.

  • The OAuth 2.0 Resource server contains the resource apps usually operating under the same OAuth 2.0 Client


 

Furthermore, the OAuth 2.0 specification protects the below mentioned platform resources from Harm’s way:

  • Organizations

  • Spaces

  • Platform operations on the various entities.



Figure 5:


SAP BTP resource overview


 

The SAP User Account and Authentication (XSUAA) microservice provides functionality for administrating and assigning application authorizations. It acts as the OAuth 2.0 authorization server and represents a typical reuse service.

 

The XSUAA service broker creates a service instance for each application. Each app that wants to enforce authorizations with the Security Client Library is then bound to this XSUAA service instance of the corresponding application.

 

SAP also provides support for the below token grant types based on the utilized platform:

  • Authorization code grant

  • Client credentials grant

  • SAML 2.0 bearer grant



Figure 6:


SAP User Account and Authentication overview


 

The Microservice has service broker functionality embedded within and must implement the open service broker API specification. The service broker is responsible for:

  • Exposing its service offerings and service plans to the respective SAP recommended platform.

  • Acting on requests from the platform for provisioning, binding, unbinding, and de-provisioning


A service instance represents a reserved resource and is an instantiation of a service offering for a service plan. The service offering is the advertisement of a service that the service broker supports. The service plan is a variant of the service offering and usually represents the costs and benefits of that plan. The service broker binds the service instance to the consuming apps. The service binding contains information about the service (for example, URL, credentials), which the app uses to consume the service.


Figure 7:


SAP XSUAA service instances


 

A JSON web token (JWT) (according to RFC 7519) is an open standard that defines a compact token format for transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWT tokens can be signed using a secret key pair (with HMAC algorithm) or a public/private key pair using RSA.


Figure 8:


Postman Generated JSON web token


Source: Postman API, https://www.postman.com/api-platform/api-testing/


 

Ladies and Gents, now that you have received the usual lecture from your local administrator, I believe we can all agree that if we can apply the three theological virtues to the below mentioned order, in harmony we shall forever live:

  1. Respecting the privacy of others

  2. Thinking before we type

  3. Acknowledging that with great power comes great responsibility


 

Yours Truly,

 

 

Abbreviations:

 

 BTP: Business Technology Platform

HMAC: Hashed or Hash-based Message Authentication Code

IdP: Identity Provider

JWT: JSON web token

RFC: request for comment

RSA:  Ron Rivest, Adi Shamir and Leonard Adleman

XSRF: Cross-site request forgery

XSUAA: User Account and Authentication

 

 

 

Reference:

 

  1. Postman API:


          https://www.postman.com/api-platform/api-testing/

  1. SAP BTP – Security: https://help.sap.com/docs/BTP/65de2977205c403bbc107264b8eccf4b/e129aa20c78c4a9fb379b9803b02e5f6.html...

  2. SAML version 2.0 Specification:


          http://saml.xml.org/saml-specifications




  1. RFC Specification:


https://www.rfc-editor.org/rfc/rfc5246

  1. SAP API Management: https://help.sap.com/docs/SAP_CLOUD_PLATFORM_API_MANAGEMENT?locale=en-US

Labels in this area