SAP Identity Authentication & Authorization (IAS/IPS)

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

Two different questions, answered by two different components. Blurring them is the mistake this topic exists to catch.

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

    authentication   who is this?          IAS
    authorization    what may they do?     XSUAA + role collections

IAS is an identity provider, usually acting as a broker. A BTP application does not implement login at all. It delegates to IAS, and IAS typically federates onward to the customer's own corporate identity provider over SAML2 or OpenID Connect.

    user -> BTP app -> IAS -> corporate IdP (Azure AD, LDAP-backed, ...)
                              the user's existing credentials

So there is no BTP-specific password. Users sign in with their corporate account, single sign-on works across BTP applications, and no application stores a credential.

That last point is the architectural argument: every application implementing its own login is every application storing passwords, and one of them will do it badly.

XSUAA issues the tokens that carry permissions. The application declares scopes; role collections group them; users are assigned role collections.

    app declares scope    "Orders.Approve"
    role collection       "Order Approver" contains that scope
    user assigned         that collection
    -> the token carries the scope; the app checks it

So the application checks a scope in a token, not a username against a list. Permissions change by assigning a role collection, with no code involved.

The full flow, which is worth being able to recite.

  1. User opens the application
  2. Redirected to IAS, which federates to the corporate identity provider
  3. User authenticates there and returns with an assertion
  4. XSUAA exchanges it for an OAuth2 token carrying the user's scopes
  5. The application checks the scope before performing the action

IPS keeps user data synchronised, which is the other half. It provisions accounts from a source — an HR system, a corporate directory — into targets such as IAS, SuccessFactors and other connected systems, on a schedule or triggered by events.

Deprovisioning is the part that matters most. Creating accounts by hand is tedious; removing them by hand is a security failure, because it is the step people forget.

An employee leaves, HR records it, and IPS removes their access everywhere connected. Without it, access lingers in whichever systems nobody remembered — which is one of the most common findings in any access audit.

What the interviewer is probing.1. "What do IAS and IPS each do?" Probing: the distinction. Stalls: "Both are login." *Moves up:* IAS authenticates and federates identities; IPS provisions users and groups into target systems.

2. "How does an application get authorisations from it?" Probing: the chain. Stalls: "Directly." Moves up: groups from the identity provider map to role collections in the subaccount, which bundle scopes the application checks.

3. "Why federate to a corporate IdP rather than using IAS as the source?" Probing: the practical reason. Stalls: "Either is fine." Moves up: so joiners and leavers are handled once in the corporate directory — a second user store is a security liability.

4. "What breaks most often in this setup?" Probing: experience. Stalls: "Passwords." *Moves up:* attribute and group mapping, and trust certificate expiry — which is why certificate renewal belongs on a calendar.