SailPoint to Azure AD Integration – High-Level Design Requirements

This document outlines the Business, Functional, and Technical Requirements for integrating SailPoint with Azure Active Directory (Entra ID) to automate B2B identity management, RBAC group assignments, and attestation workflows.

---

📌 1. Business Requirements (BR)

ID	Requirement
BR1	Automate the onboarding and offboarding of B2B users to reduce manual effort and improve security posture.
BR2	Ensure all access assignments (e.g., Azure AD RBAC Groups) follow enterprise governance and compliance policies.
BR3	Improve auditability and traceability of access changes across Entra ID and SailPoint.
BR4	Enhance user experience by reducing onboarding time through integration with SailPoint workflows.
BR5	Enable secure delegation of access management to business owners without direct Azure access.
BR6	Ensure B2B users are correctly represented in the Identity Warehouse to support attestation.
BR7	Establish clear identity ownership and traceability for new B2B identity types within AIB.

---

⚙️ 2. Functional Requirements (FR)

ID	Requirement
FR1	The form shall collect input fields such as UPN, justification, target RBAC group(s), and B2B metadata.
FR2	Input fields must be validated and routed to SailPoint for approval workflow.
FR3	Upon approval, SailPoint shall trigger an API call to Azure AD to assign the user to a target RBAC group.
FR4	The system shall support creation and invitation of B2B users if they don’t exist in Azure AD.
FR5	The system shall log all actions (timestamp, approver identity, status) for audit purposes.
FR6	The system shall provide error messages and retry logic in the event of API or network failure.
FR7	The system shall support offboarding by removing RBAC assignments and disabling B2B accounts.
FR8	Manager data must be captured for all B2B users to support attestation routing.
FR9	Staff ID mappings must be supported — B2B accounts must link to AIB staff records.
FR10	Support for Entra ID “eligible” group members (PIM) via custom Graph API scripts due to SailPoint limitations.
FR11	The solution must integrate with attestation and tagging flows used in Azure.
FR12	API calls from SailPoint must use OAuth tokens to enforce secure communication.

---

🧩 3. Technical Requirements (TR)

ID	Requirement
TR1	Use Microsoft Graph APIs with delegated or application permissions for group management and B2B provisioning.
TR2	Authenticate API calls using a registered app with least privilege (client secret or certificate).
TR3	All API traffic must be encrypted via HTTPS using TLS 1.2+.
TR4	SailPoint must be configured to use OAuth-based tokenized service accounts, not hardcoded credentials.
TR5	API endpoints must enforce RBAC and conditional access to restrict usage to approved systems.
TR6	All SailPoint development must occur in Pre-Prod and follow change control procedures.
TR7	Form must be protected via Azure AD SSO and log usage for compliance.
TR8	Logging must be integrated with Azure Monitor or Log Analytics and retained for 1 year.
TR9	Object and workflow creation in SailPoint must be performed by SPAdmin service identity — not human users.
TR10	Manager and Staff ID attributes must be passed to the identity warehouse for all B2B users.
TR11	Graph API scripts must include error handling, retry logic, and detailed logging.
TR12	Azure attestation tagging and flows must be preserved and reused, where applicable.

---

📐 4. Design Considerations & Controls

• Azure Attestation
  Reuse existing tagging and attestation design from Azure, as shared by the Identity team.

• Change Control
  All SailPoint changes must go through Pre-Prod with formal change control before affecting production tenants.

• Security

  • OAuth2 token-based authentication for APIs.
  • Use non-human service identities (e.g., SPAdmin).
  • Enforce least privilege and deny direct owner roles for humans.

• Audit & Monitoring
  All actions (e.g., user invites, group assignments) must be logged centrally.

• Scalability & Future Use
  Design must be extensible for other identity types such as contractors or partner-managed identities.

---

✅ Next Steps (Optional Section)

• Convert this Markdown into a downloadable .md file for internal version control.
• Develop sequence and flow diagrams for the onboarding, group assignment, and attestation lifecycle.
• Review OAuth scopes and Graph API usage for least privilege compliance.
• Finalise identity schema extensions for B2B user representation.