In this blog, I am going to share the list of common questions and answers on SAP BTP. To make it easy, I have categorized it in multiple volumes.
Part 1 — SAP BTP — General Topics
Part 2— SAP BTP — Application Development, Programming Models and Multitenancy
Part 3 — SAP BTP — Security [Current Blog]
Part 5 — SAP BTP — Side by side Extensibility
This is part 3, where we will explore questions on security topics in SAP BTP.
Q: What is the difference between platform users and business users in SAP BTP.
Answer:
In SAP BTP, for user-management, all the users are categorized in 2 ways - platform users and business users.
Platform users are usually developers, administrators or operators who deploy, administer, and troubleshoot applications and services on SAP BTP.
Business users use the applications that are deployed to SAP BTP. For example, the end users of SaaS apps or services, such as SAP Workflow service or SAP Cloud Integration, or end users of your custom applications are business users.
Note: You may draw and explain this further as shown in below image.
Q: On a high-level, explain how global account and subaccounts are controlled and managed by administrators.
Answer:
When a customer signs a contract with SAP, one user is created at the global account level. On this level, entitlements are defined, assigning entities and services, including billing information. The global account administrator can initially log on to SAP BTP to manage these entitlements and create directories and subaccounts. To ensure that more than one employee can administer the global account, the administrator needs to create other users at the global account level and assign them administrator permissions.
Typically, a global account consists of various subaccounts. When a global account administrator creates a subaccount, they automatically become the administrator of the subaccount. The subaccount administrator can manage entitlements, service subscription, create other users on the subaccount level and assign roles to the users. Subaccount administrators get administration authorizations for the subaccount only, not for the global account.
Subaccount administrators also create business users, who are consumers of applications and services that are provided on SAP BTP (for example: SAP Business Application Studio) or business applications (SaaS) that were created with the help of the tools and services provided by SAP BTP and deployed in a subaccount. These users can have access to SAP BTP, but they are not able to do any administrative tasks. If a business user only uses a single application on SAP BTP, he or she does not necessarily require access to the SAP BTP cockpit (meaning the subaccount) but to the application only. In this case, the subaccount administrator creates the user on a subaccount level and only assigns application authorizations to the user.
Q: What is the significance/use of SAP XSUAA service in SAP BTP?
Answer:
The SAP Authorization and Trust Management Service (XSUAA) is one of the most important BTP service involved in application security.
Let me first explain what XSUAA is.
SAP XSUAA is an internal development of SAP. In Cloud Foundry, there is an open-source component called UAA. UAA is an OAuth provider which takes care of authentication and authorization. SAP took the base of UAA and extended it with SAP specific features to be used in SAP BTP. Technically XSUAA is an OAuth server and uses JWT tokens.
XSUAA takes care of authentication and authorization in SAP BTP, Cloud Foundry.
XSUAA does NOT store user data. This is why the XSUAA needs to trust an external Identity Provider (IdP). It can establish trust either with SAP ID Service or a Corporate Identity Provider via SAP Identity Authentication Service (IAS).
Q: What is an Identity Provider and why it is required?
Answer:
An Identity Provider (IdP) is a system or service responsible for authenticating users and providing them with access to resources or services within a network or application. It serves as a trusted source for verifying the identity of users and issuing security tokens that can be used for access control.
IdPs are required for several reasons:
Centralized Authentication
Instead of each service or application managing its own authentication system, which can be cumbersome and less secure, an IdP centralizes authentication processes. This not only makes authentication more efficient but also enhances security by enforcing consistent policies and controls.
Single Sign-On (SSO)
IdPs enable SSO, allowing users to access multiple services or applications with just one set of credentials. This enhances user experience by reducing the need to remember multiple usernames and passwords.
User Management
IdPs often include user management capabilities, such as user provisioning, de-provisioning, and user profile management. This allows administrators to efficiently manage user accounts and permissions across various services and applications.
Q: Can you briefly explain the concept of Principal Propagation and an example of its use in SAP BTP?
Answer:
Principle Propagation allows a user to be the user when the request flows through multiple systems. So that we don’t have any technical user in between.
Principal Propagation is
- the ability of a system to securely forward or propagate the authenticated user (principal) from a sender to a receiver in a way that the forwarded user information is kept confidential and – even more important – cannot be changed during transit.
- Based on a pre-established trust relationship to the sender, the receiver uses this information to logon the user without asking her again for the credential.
Q: What are the Identity Providers available in SAP BTP?
Answer:
In SAP BTP, there are 2 options for Identity Provider – SAP ID Service and SAP Cloud Identity Authentication service (IAS).
SAP ID Service
SAP ID Service is the default identity provider in SAP BTP. It is a pre-configured, standard SAP public IdP (account.sap.com) that is shared by all customers.
SAP Cloud Identity Authentication service (IAS)
For many customers, business users might be stored in corporate identity providers. SAP recommends using SAP Cloud Identity Services - Identity Authentication Service (IAS) as a hub.
We can connect IAS as a single custom identity provider to SAP BTP. Further use IAS to integrate with corporate identity providers.
Q: Can you explain what is SAP ID Service and it’s importance in terms of security in SAP BTP?
Answer:
SAP ID Service is the default identity provider in SAP BTP. It is a pre-configured, standard SAP public IdP (account.sap.com) that is shared by all customers.
SAP ID Service is managed by SAP. Trust to SAP ID service is pre-configured in all BTP subaccounts.
SAP ID service manages the users of official SAP sites, including the SAP developer and partner community. It is the place where the S-Users, P-Users, and D-Users are managed.
Q: In which scenarios, you will suggest the use of SAP Identity Authentication Service (IAS) in SAP BTP?
Answer:
Most customers already have huge on-premises or cloud ecosystem. Their business user data is already available in their corporate identity provider.
When these customers build applications on BTP, an important question comes up - "How can employees authenticate to the applications with known credentials?"
In simple words, customer needs to provide single sign-on for their custom solution on BTP, SAP S/4HANA Cloud, SAP SuccessFactors and other SAP solutions. The answer to this is SAP Identity Authentication Service.
As shown in the above image, IAS can either act as an IdP itself or delegate the authentication to a corporate identity provider. IAS acts a central hub to provide single-sign-on to all SAP cloud applications as well as BTP applications.
Q: Explain the concepts of Role Collections, Roles, and Scopes in SAP BTP.
Answer:
Scopes
Scopes are arbitrary values that express authorizations / access rights in an application or service. Scopes need to be prefixed with an xsappname to make them uniquely identifiable.
Roles
Roles are entities that hold several scopes. Scopes can be put in multiple roles, so you are not limited to have scopes sitting in just one role.
Role Collections
Role collections contain one or more roles. A role can be used in multiples. But it is totally fine to have, for example, a called Admin that only has an admin role.
Role collections are stored as an assignment in the XSUAA and are THE entity that can be assigned to a certain business user.
Q: Can you briefly explain how role collections are assigned to users?
Answer:
Role collections are managed on each SAP BTP level separately. Role collections that exist in the global account do not exist in the subaccounts. Likewise, role collections in subaccounts are not available in the global account.
All users of SAP BTP are stored in identity providers. How you assign users to their authorizations depends on the type of trust configuration with the identity provider. If you're using the default trust configuration with SAP ID service, you assign users directly to role collections. However, if you are using a custom identity provider, you can assign role collections to individual users directly, or you map role collections to user groups or other user attributes defined in the identity provider. This is called federation.
The custom identity provider hosts the business users who can belong to user groups. It is efficient to use federation by assigning role collections to one or more user groups. The role collection contains all the authorizations that are necessary for this user group. This method saves time when you add a new business user. Simply add the users to the respective user groups and the new business users automatically get all the authorizations that are included in the role collection.
Q: What is xs-security.json file and what is the use of it?
Answer:
xs-security.json file, also called Application Security Descriptor is a file that defines the details of the authentication methods and authorization types to use for access to your application.
The xs-security.json file uses JSON notation to define the security options for an application
The xs-security.json file is further used to create XSUAA service instance. For example, we can use below command to create instance of XSUAA service using an xs-security.json file.
cf create-service xsuaa application myxsuaa -c xs-security.json
An example of xs-security.json file.
{
"xsappname" : "app-name",
"tenant-mode": "shared",
"scopes" : [ {
"name" : "$XSAPPNAME.Display",
"description" : "display" },
],
"role-templates": [ {
"name" : "Viewer",
"description" : "View all books",
"scope-references" : [
"$XSAPPNAME.Display" ]
}
]
}
Q: Explain what OAuth is and how it’s different from SAML.
Answer:
OAuth is an open standard for applications and websites to handle authorization.
OAuth doesn’t share password data but instead uses authorization tokens to prove an identity between consumers and service providers. It is an authentication protocol that allows you to approve one application interacting with another on your behalf without giving away your password.
OAuth:
- Avoids storing credentials at the third-party location
- Limits the access permissions granted to third parties
- Enables easy access right revocation without the need to change credentials
In this way, OAuth mitigates some of the common concerns with authorization scenarios.
SAML vs. OAuth
The Security Assertion Markup Language (SAML) is an open standard based on XML, which many enterprises use for Single-Sign On (SSO).
There are many differences between SAML and OAuth.
- SAML uses XML to pass messages, and OAuth uses JSON.
- OAuth is much more lightweight and an ideal fit for system-to-system communication. While SAML is geared towards enterprise security.
- OAuth uses API calls extensively, which is why mobile applications, modern web applications, game consoles, and Internet of Things (IoT) devices find OAuth a better experience for the user. SAML, on the other hand, uses a session cookie in a browser that allows a user to access certain web pages – great for short-lived work days, but not so great when have to log into your smart watch every day.
Q: What is JWT and how it’s better than SAML tokens?
Answer:
JSON Web Token (JWT) is an open standard that defines a compact and self-contained way for securely transmitting information between parties.
For example, XSUAA creates a JWT token to combine user information from IdP, role collection assignments, etc. and pass it to application.
A JWT consists of three main components that are declared as plain JSON:
- header: Declaration of the used hashing and signing algorithms
- body/payload: Might be anything, but in our case it is the information about the user, the issuer and all the scopes.
- signature: The signature allows the integrity of the JWT. The XSUAA will put the header of the ticket together with the content.
JSON Web Tokens (JWT) are better than SAML tokens in many ways.
First of all, since JSON is less verbose than XML, JWT Tokens are smaller in size, making JWT more compact than SAML. This makes JWT a good choice to be passed over network.
JSON parsers are extremely common in most programming languages because they map directly to objects. Conversely, XML doesn't have a natural document-to-object mapping. This makes it easier to work with JWT than SAML assertions.
Q: Can you explain what SAML is?
Answer:
The Security Assertion Markup Language (SAML) is an open standard based on XML for exchanging authentication and authorization data of a user between an identity provider (IdP) and a service provider (SP).
SAML is a platform for requesting authentication. Its most common use is to enable SSO.
In SAML, the data is exchanged using messages called bearer assertions. A bearer is any party in possession of the assertion. The integrity of the assertion is protected by XML encryption and an XML signature.
SAML addresses the requirement of web browser single sign-on across the Internet.
Q: What is OpenID Connect (OIDC) and how it’s different from SAML?
Answer:
OpenID Connect (OIDC) is a relatively new protocol and is continuously evolving. It was designed with web and mobile applications in mind.
OIDC is an extension of OAuth2, with data structures in JSON format (JWT), and simple HTTPS flows for transport. It is designed to be easy to adopt and use.
SAML has a long track record of providing a secure means of identity data exchange, so it is trusted by many organizations. It is also very feature-rich, covering a wide range of identity requirements.
While, OIDC, being newer and evolving (especially in the European banking sector, with Open Banking), is still lagging behind SAML in terms of features.
If I have missed any important question, please let me know in comment.
Happy Learning!
Next Blog
Part 4 - SAP BTP DevOps [To be published]
- SAP Managed Tags:
1 Comment
| User | Count |
|---|---|
| 14 | |
| 13 | |
| 11 | |
| 11 | |
| 11 | |
| 11 | |
| 10 | |
| 9 | |
| 9 | |
| 7 |
