zhongwei/gh-secondsky-sap-skills-skills-sap-btp-best-practices
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
bd301d195d5385b585e6ce01e075ee82c5a9d894
gh-secondsky-sap-skills-ski…/references/security-and-authentication.md
Zhongwei Li bd301d195d Initial commit
2025-11-30 08:54:47 +08:00

14 KiB
Raw Blame History

SAP BTP Security and Authentication - Detailed Reference

Source: https://github.com/SAP-docs/btp-best-practices-guide/tree/main/docs/set-up-and-plan

Security Fundamentals

Applications on SAP BTP are exposed to the Internet and must fulfill the highest security requirements to prevent unauthorized access.

Network Security

The SAP BTP landscape runs in an isolated network protected by:

  • Firewalls
  • DMZ (Demilitarized Zone)
  • Communication proxies for all inbound/outbound traffic
  • Transport Layer Security (TLS) encryption for all user connections

User Types

Platform Users

Developers, administrators, and operators who:

  • Deploy applications
  • Administer accounts and environments
  • Troubleshoot platform issues

Permissions managed through: Membership assignments at global account, directory, subaccount, and environment levels.

Business Users

End users of deployed applications and SaaS services who require:

  • Authentication configuration
  • Authorization controls
  • Role assignments

Identity Provider Architecture

Recommended Setup

Always use SAP Cloud Identity Services - Identity Authentication for SAP BTP.

┌─────────────────┐      ┌──────────────────────┐      ┌─────────────┐
│ Corporate IdP   │ ──── │ Identity             │ ──── │ SAP BTP     │
│ (ADFS, Okta,   │      │ Authentication       │      │             │
│  Azure AD)      │      │ (Proxy Mode)         │      │             │
└─────────────────┘      └──────────────────────┘      └─────────────┘

Benefits of Proxy Mode:

  • Single integration point for multiple corporate IdPs
  • Centralized security policies
  • Required for certain user types and applications
  • Consistent authentication experience

Default Identity Providers

Provider Purpose
SAP ID Service Preconfigured for starter scenarios and testing
SAP Universal ID Manages official SAP community users

Trust Configuration Levels

User Type Configuration Level
Platform Users Global account level (applies across directories, subaccounts, environments)
Business Users Individual subaccount level

Critical: Maintain backup administrators in default provider OR alternative custom provider for recovery scenarios.

SAP Cloud Identity Services Onboarding

Why Onboard?

The default identity provider doesn't support:

  • Custom security policies
  • Multifactor authentication
  • SCIM APIs for user provisioning

Tenant Options

Organizations receive both productive and test tenants:

Option 1: Test tenant for dev/test, productive for all Option 2: Test tenant for dev/test only, productive for production

Onboarding Procedure

Step 1: Administrator Setup

  • Add multiple administrators (coverage across time zones)
  • Ensure backup during absences

Step 2: Security Hardening

  • Implement MFA for administrator accounts
  • "Administrators have critical access to the system. Set a higher security standard."

Step 3: Monitoring Configuration

  • Establish system notifications
  • Configure security alerts

Step 4: Corporate Integration

  • Configure Identity Authentication as proxy
  • Connect to corporate identity provider(s)

Authorization Methods

Comparison Table

Aspect Provisioning Federation
Mechanism Synchronizes users/groups between systems Maps authorizations to user attributes in tokens
Tools Identity Provisioning, Cloud Identity Access Governance btp CLI, SAP BTP cockpit
Advantages Centrally defined roles, approval workflows, automated offboarding Simpler implementation, real-time authorization
Disadvantages Users wait for provisioning jobs Doesn't scale, manual role grouping, orphaned data
Restrictions Partial for platform users (subaccount level only) ABAP environment doesn't support

Recommendations

  • Production with many users: Use provisioning or federation
  • Feasible scenarios: Prefer provisioning
  • Simple setups: Federation acceptable
  • Testing only: Manual assignment okay

Identity Lifecycle Management

Central Identity Management

The persistency layer of SAP Cloud Identity Services is the Identity Directory.

Process:

  1. Corporate identity system → Identity Provisioning → SAP Cloud Identity Services
  2. Identity Directory stores user data
  3. Identity Provisioning synchronizes to SAP BTP applications

Global User ID

Use universally unique identifiers rather than changeable attributes:

Avoid: Email addresses (can change) Use: Generated UUID or corporate employee ID

Authentication Requirements

Environment Requirements
ABAP Unique email address required
Kyma Unique email address required
Cloud Foundry Email + IdP information

Implementation Options

  1. Manual: Create users via BTP cockpit, CLI, or APIs
  2. Automatic: Create after successful IdP authentication
  3. Centralized: Manage through SAP Cloud Identity Services

Platform User Access Rights

Team-Based Access Distribution

Team Development Test Production
Cloud Development Team Full access No access No access
Platform Engineering Team No access Full access Full access

Environment-Specific Roles

Cloud Foundry

Role Capability Recommended For
Space Developer Deploy apps, access service credentials, sensitive data Dev team (dev only), Platform Engineering (test/prod)
Org Manager Manage org settings Platform Engineering
Space Manager Manage space settings Platform Engineering

Security Note: Space Developer provides broad access; restrict in production.

ABAP Environment

Requires both:

  • CF roles: Org Manager, Space Manager, Space Developer
  • ABAP business roles: SAP_BR_ADMINISTRATOR, SAP_BR_DEVELOPER

Kyma

Uses Kubernetes RBAC:

  • Start with simple role concept separating developers and operators
  • Refine as needed
  • See Kyma RBAC reference for details

Neo

  • Administrators assign predefined platform roles
  • Custom roles can be configured

Sensitive Production Access

For scenarios where even Platform Engineering cannot access data:

  1. Automate tasks requiring developer access
  2. Integrate into CI/CD pipelines using technical users
  3. Temporary role assignment for firefighter situations
  4. Special user accounts with controlled credential distribution
  5. Maintain audit trails of all access usage

Destination Authentication Methods

Complete Method Reference

Method Description CF Neo Internet On-Premise
NoAuthentication No authentication required Yes Yes Yes Yes
BasicAuthentication Username/password (testing only) Yes Yes Yes Yes
ClientCertificateAuthentication Mutual TLS with technical user Yes Yes Yes No
PrincipalPropagation Forward user identity via Cloud Connector Yes Yes No Yes
OAuth2SAMLBearerAssertion SAML to OAuth for third-party Yes Yes Yes Yes
OAuth2ClientCredentials Client credentials grant (cached) Yes Yes Yes Yes
OAuth2UserTokenExchange Token exchange in same tenant Yes No Yes Yes
OAuth2Password Password grant (testing only) Yes No Yes Yes
OAuth2JWTBearer JWT bearer for user context Yes No Yes Yes
SAMLAssertion Generated SAML assertion Yes No Yes Yes
AppToAppSSO Application-to-application SSO No Yes Yes No

Recommendations

For SAP Systems: PrincipalPropagation For Third-Party: OAuth2SAMLBearerAssertion For Token Exchange: OAuth2JWTBearer (preferred over OAuth2UserTokenExchange)

Avoid in Production: BasicAuthentication, OAuth2Password

Identity Propagation

Cloud Foundry Environment

Decision Tree:

  1. SAP system on-premise? → Use PrincipalPropagation
  2. Third-party system? → Use OAuth2SAMLBearerAssertion
  3. Same tenant token exchange? → Use OAuth2JWTBearer

Neo Environment

Follow similar principles:

  • PrincipalPropagation for SAP systems
  • OAuth2SAMLBearerAssertion for third-party

Kyma RBAC Details

Recommended Setup Goals

  1. Separate operators from development teams
  2. Isolate day-to-day accounts from administrative accounts
  3. Use dedicated namespaces per service, project, or team
  4. Leverage common-resource-viewer ClusterRole for read access

Kubernetes Impersonation Strategy

Rather than granting powerful roles directly, use Kubernetes User Impersonation:

  • Subjects (users, groups, service accounts) assume temporary identities
  • "Virtual users" (vUsers) needn't exist in the system
  • Provides just-in-time privilege escalation

Role Configurations

Operators (All Environments):

  • Default: View-only access
  • Administrative tasks: Impersonate cluster-admin virtual user

Developers (Dev/Test Clusters):

  • Full namespace access via admin ClusterRole binding

Developers (Production Clusters):

  • Read-only namespace access via cluster-viewer ClusterRole
  • Administrative tasks: Impersonate application-specific virtual users

Sample Manifest: Operator Impersonation

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-admin-impersonator
rules:
- apiGroups: [""]
  resources: ["users"]
  verbs: ["impersonate"]
  resourceNames: ["cluster-admin"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: operators-can-impersonate-admin
subjects:
- kind: Group
  name: operators
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin-impersonator
  apiGroup: rbac.authorization.k8s.io

Connectivity and Remote Systems

Destination Benefits

Using destinations provides:

  • Separation of application code from configuration
  • Easier updates without code changes
  • Secure credential and certificate storage
  • Runtime resolution of connection details

Destination Creation Levels

Level Use Case
Subaccount Organization-wide availability
Service Instance Specific scenario use

Security: Limit access authorizations to minimum necessary.

Cloud Connector

Lightweight on-premise agent establishing secure tunnel:

Capabilities:

  • No inbound firewall ports required
  • Fine-grained access control per exposed system
  • RFC and HTTP protocol support
  • Principal propagation for user identity forwarding
  • Configuration via SAP BTP cockpit

Note: Each subaccount requires separate Cloud Connector integration setup.

mTLS Certificate Extraction

Steps to Extract X.509 Certificates

  1. Locate Service Key: Navigate to service instance in BTP cockpit
  2. Find Attributes: Look for certificate and key attributes (verify credential-type: x509)
  3. Extract Values: Copy to separate text files (avoid \n characters)
  4. Save as PEM:
    • my-private-key.pem
    • my-certificate.pem
  5. Combine: Create my-keypair.pem with private key first, then certificate

PEM File Structure

-----BEGIN RSA PRIVATE KEY-----
[Base64 encoded private key]
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
[Base64 encoded certificate]
-----END CERTIFICATE-----

Note: Converting to .cer, .jks, .p12 requires third-party tools.

Data Protection and Privacy

Key Principles

  • Compliance should be integrated early in development, not as an afterthought
  • Simply using SAP BTP doesn't make applications compliant
  • SAP provides security features; you must implement them properly
  • Consult legal experts for specific requirements

Important Disclaimer: "SAP does not provide legal advice in any form." Compliance requires case-by-case decisions based on your specific system landscape and applicable laws.

Important Considerations

  • Compliance involves multiple systems and products
  • User deletion requests may require coordinated removal across platforms
  • Tailor decisions to your system environment and legal framework
  • SAP Discovery Center provides EU Access service information

SAP's Role vs Your Responsibility

SAP Provides You Must
Security features Implement them properly
Data protection-relevant functions Configure for your requirements
Identity lifecycle management Coordinate across all integrated systems
Documentation and guidance Consult legal experts for your jurisdiction

Source Documentation:

Reference in New Issue View Git Blame Copy Permalink