本文旨在指导您如何在azure ad中用户被删除时，向您的外部系统（如php应用）发送实时通知。我们将重点探讨两种主要方法：利用microsoft graph api的变更通知（webhooks）实现即时同步，以及理解azure ad标准用户去预配（de-provisioning）的工作机制及其对删除操作的响应时机。通过这两种策略，您可以确保外部系统中的用户状态与azure ad保持一致，从而实现更完善的用户生命周期管理。
在现代应用集成中，尤其当外部系统（如基于SAML协议集成的PHP应用）依赖Azure Active Directory (AD) 进行用户身份管理时，确保用户生命周期事件（如用户删除）在两个系统间同步至关重要。本文将详细介绍如何配置Azure AD，以便在用户从应用中被删除时，能够及时通知您的服务器进行相应的处理。
1. 利用Microsoft Graph API变更通知实现实时同步
Microsoft Graph API 提供了强大的Webhooks机制，允许您的应用订阅Azure AD中特定资源（如用户）的变更通知。当用户数据发生添加、修改或删除时，Graph API会向您配置的回调URL发送通知。这是实现用户删除实时同步的首选方法。
1.1 工作原理
- 订阅资源变更： 您的应用通过Graph API创建一个订阅（Subscription），指定要监听的资源（例如 /users）、变更类型（例如 deleted）以及接收通知的回调URL。
- 接收通知： 当Azure AD中发生与订阅匹配的变更时，Graph API会向您的回调URL发送一个HTTP POST请求，其中包含变更的详细信息。
- 处理通知： 您的服务器接收到通知后，解析其内容，识别出被删除的用户，并执行相应的业务逻辑（例如从本地数据库中删除用户记录）。
1.2 实施步骤概述
-
注册应用并获取权限：
- 在Azure AD中注册您的应用，并授予其必要的Microsoft Graph API权限，例如 User.Read.All 和 Directory.Read.All（对于读取用户信息）以及 Directory.AccessAsUser.All 或 Application.ReadWrite.All（对于创建订阅，具体取决于您的应用类型和需求）。
- 确保您的应用具有访问Graph API的凭据（客户端ID、客户端密钥或证书）。
-
创建订阅请求： 您的应用需要向Microsoft Graph API发送一个POST请求以创建订阅。
POST https://graph.microsoft.com/v1.0/subscriptions Content-Type: application/json { "changeType": "deleted", "notificationUrl": "https://your-server.com/api/graph-webhook-receiver", "resource": "/users", "expirationDateTime": "2024-03-01T18:23:45.9356913Z", "clientState": "secretClientValue" }- changeType: 指定您关注的变更类型，这里是 deleted。
- notificationUrl: 这是您的服务器上接收通知的端点URL。
- resource: 指定要订阅的资源路径，/users 表示所有用户。
- expirationDateTime: 订阅的过期时间，最长为3天。您需要定期刷新订阅。
- clientState: 一个可选的秘密字符串，用于验证通知的真实性。
-
实现通知接收端点： 在您的服务器上实现 https://your-server.com/api/graph-webhook-receiver 端点。
- 验证订阅： 当Graph API首次创建订阅时，会发送一个验证请求到 notificationUrl，其中包含 validationToken 查询参数。您的端点必须返回 validationToken 的值作为纯文本响应，以确认URL有效。
- 处理变更通知： 接收到实际的变更通知时，请求体将包含一个JSON数组，描述了发生的变更。您需要解析此JSON，提取出被删除用户的ID或其他相关信息，然后执行您的删除逻辑。
1.3 注意事项
- 安全性： 务必验证 clientState 和请求的来源，确保通知确实来自Microsoft Graph。考虑使用TLS/SSL证书来保护您的回调URL。
- 可靠性： 您的通知接收端点应具有幂等性，并能快速响应（HTTP 202 Accepted），避免Graph API重试发送通知。对于复杂的处理逻辑，可以考虑将任务放入消息队列异步处理。
- 订阅生命周期： Graph API订阅有最长3天的有效期。您的应用需要定期刷新订阅，以保持通知的持续性。
- 权限管理： 确保您的Azure AD应用仅拥有完成任务所需的最小权限。
2. 理解Azure AD去预配（De-provisioning）行为
Azure AD的去预配服务旨在将用户生命周期事件同步到已连接的SaaS应用。然而，对于用户删除事件，其行为模式需要特别理解。
2.1 去预配的两种状态
根据Microsoft文档，Azure AD中的用户删除分为两个阶段：
- 软删除（Soft Delete）： 当管理员在Azure AD中删除用户时，用户首先会被软删除（发送到回收站），其 AccountEnabled 属性通常会设置为 false。在这个阶段，用户不会立即从租户中永久移除，而是保留30天。
-
永久删除（Permanent Delete）：
- 在软删除后的30天窗口期结束时，用户将被永久从租户中删除。此时，预配服务会向目标应用程序发送一个 DELETE 请求，以永久删除该用户。
- 在30天窗口期内的任何时候，管理员也可以选择手动永久删除用户。这种操作也会立即触发预配服务向应用程序发送 DELETE 请求。
2.2 为什么标准去预配可能不满足即时需求
用户最初的问题在于，他们希望在管理员“删除用户”时（通常指软删除）立即收到通知。然而，标准的Azure AD去预配服务通常只在用户被 永久删除 时才发送DELETE请求到目标应用。这意味着如果仅依赖标准去预配，您的系统可能不会在用户被软删除时立即收到通知，而是在30天后或管理员手动永久删除后才收到。
因此，如果您的需求是在用户被管理员软删除时立即触发同步操作（例如，立即将用户从您的PHP系统中注销并删除），那么Microsoft Graph API的变更通知是更合适的解决方案，因为它能捕获到 deleted 状态的即时变更，而不仅仅是永久删除。
总结
为了在Azure AD用户被删除时，向您的外部系统发送请求并同步用户状态，强烈推荐使用Microsoft Graph API的变更通知（Webhooks）。这种方法提供了实时的、细粒度的控制，允许您在用户被软删除时即时响应。虽然Azure AD的去预配服务也能处理用户删除，但其DELETE请求通常在用户被永久删除时才触发，可能无法满足对即时同步的需求。结合使用Graph API Webhooks和对去预配机制的理解，可以构建一个健壮且响应迅速的用户生命周期管理系统。
