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.