SailPoint Requirements List - razmipatel/Random GitHub Wiki

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.