SAP Identity Authentication & Authorization (IAS/IPS)

Centralized identity federation and authorization management for BTP applications using Identity Authentication Service and Identity Provisioning Service.

Identity and access management questions come up in BTP interviews specifically because getting authentication wrong on a cloud platform serving potentially many customer subaccounts and external users has serious security consequences, and interviewers use this topic to check whether a candidate understands federation and centralized identity as a deliberate architectural pattern rather than building custom login logic per application.

IAS is like a hotel's central front desk that verifies your identity once using your existing ID (your corporate credentials) rather than each room requiring you to create a brand-new hotel-specific password; IPS is housekeeping automatically updating the room-access list the moment a guest checks in or out, so no room ever stays accessible to someone who's already left; XSUAA and role collections are the specific room-key permissions determining which rooms and amenities that verified guest is actually allowed to use.

Key Concepts

SAP Identity Authentication Service (IAS) acts as a central identity provider (or more precisely, a proxy/broker that can federate to a customer's own corporate identity provider via SAML2 or OpenID Connect) for BTP applications, meaning a BTP application doesn't implement its own username/password login logic at all - it delegates authentication to IAS, which in turn can trust and forward to the customer's actual corporate directory (Azure AD, an on-premise LDAP-backed IdP, or others), giving users single sign-on across BTP applications and their existing corporate systems without a separate BTP-specific password to manage. This federation model is standard practice precisely because it avoids every individual application needing to implement and secure its own credential storage and login flow.

SAP Identity Provisioning Service (IPS) handles the complementary problem of keeping user and group data synchronized across multiple systems - provisioning (and deprovisioning) user accounts automatically from a source system (like a corporate HR system or Active Directory) into target systems (IAS, SuccessFactors, other BTP-connected systems) on a scheduled or event-triggered basis, so a new employee's access is automatically created (and, critically, a departing employee's access is automatically removed) across all connected systems without manual per-system user administration - a meaningful security and compliance benefit, since forgotten deprovisioning across scattered systems is a very common real-world audit finding.

A senior-level answer distinguishes authentication (confirming who a user is, IAS's core role) from authorization (what that authenticated user is allowed to do, typically handled via BTP's XSUAA - the OAuth2-based authorization server issuing scoped tokens - working together with role collections that map to specific application-defined scopes), and can explain the practical flow: a user authenticates via IAS (federated to their corporate IdP), receives a token, and XSUAA issues application-specific scoped access tokens based on the role collections assigned to that user, which the application then checks before allowing specific actions - a clean separation between "who are you" (IAS) and "what can you do here" (XSUAA plus role collections).