BTP Identity Authentication Part 3: Conditional Authentication and MFA
Apply risk-appropriate login: conditional authentication rules (route users to different IdPs by email domain, group or type), multi-factor authentication policies, risk-based rules (IP ranges, groups), emergency access, and monitoring login failures.
Explanation
📌 KEY POINTS
✅ Conditional authentication routes users to different IdPs based on rules (e.g. email domain, user type).
✅ Risk-based authentication enforces MFA or denies login by IP range, group or authentication method.
✅ MFA can be enforced per application for sensitive apps.
✅ Keep an emergency/admin access path documented and tested.
⚠️ A misconfigured rule can lock out all users of an application — test rules on test tenants/apps first.
━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 2 set up federation. Now login policies.
━━━━━━━━━━━━━━━━━━━━
▶ 1. CONDITIONAL AUTHENTICATION
- Rules by domain, group, type; default IdP.
━━━━━━━━━━━━━━━━━━━━
▶ 2. RISK-BASED RULES
- IP ranges, groups; allow/deny/MFA.\n\n━━━━━━━━━━━━━━━━━━━━\n▶ 3. MFA\n• Per application; TOTP or corporate MFA.
━━━━━━━━━━━━━━━━━━━━
▶ 4. EMERGENCY ACCESS
- Admin users, documented procedure.
━━━━━━━━━━━━━━━━━━━━
▶ 5. MONITORING
- Login failures, audit logs.
━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP
- Add a rule: domain partner.com → IAS.
- Enforce MFA for an admin app.
- Test with employee and partner users.
✅ CHECKPOINT: each user type follows its intended login path.
Code example
===== CONDITIONAL AUTHENTICATION =====Rule 1: email domain @acme.com → Corporate IdP (Entra ID)Rule 2: email domain @partner.com → Identity Authentication (local + MFA)Default: Corporate IdP ===== RISK-BASED =====App "Finance Admin": group FIN_ADMINS from corporate IP → allow with MFA | other IPs → denyReal project scenario
A retail company rolling out BTP apps to franchise partners needed separate login. Conditional authentication routed partner domains to IAS with MFA while employees used SSO via Entra ID.
Common mistakes
- Untested rules in prod.
- No emergency access.
- MFA without communication.
- One rule for all apps.
- No monitoring.
Best practices
- Test tenants.
- Documented emergency path.
- Communicate MFA.
- App-specific rules.
- Monitor failures.
Interview angle
Questions: "What is conditional authentication?", "How do you enforce MFA?", "How do you handle partner users?"
Strong answer: routing rules, risk-based rules, MFA, emergency access, monitoring.
Practice this lesson
Quick check
1. Franchise partners need access to BTP apps but aren't in the corporate directory. What is a good design?
2. What does conditional authentication in IAS allow?
3. A team proposes testing new IAS login rules directly in production. What is the risk?
Interview questions
1. A production issue is reported in Identity Authentication. What would you check first, and how would you troubleshoot it systematically?
Answer it in your own words first, then compare.
2. Suppose you inherit an existing Identity Authentication solution. How would you review it before making a change?
Answer it in your own words first, then compare.
Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.