Azure AD集成应用用户删除事件同步教程-php教程-PHP中文网

Azure AD集成应用用户删除事件同步教程

本教程详细探讨了如何为azure ad集成应用配置用户删除通知，以确保外部系统（如php应用）能及时同步用户状态。文章重点介绍了利用microsoft graph api的变更通知（webhooks）实现实时同步的策略，并阐明了azure ad应用预配服务在用户删除场景下的具体行为，帮助开发者选择最适合其业务需求的同步方案。

在将外部应用程序与Azure Active Directory (AD) 集成时，确保用户生命周期管理的同步性至关重要。当用户从Azure AD中删除时，集成应用程序也需要相应地移除该用户，这是一个常见的挑战。本教程将深入探讨实现这种同步的有效方法，特别是侧重于实时通知机制。

Microsoft Graph API 变更通知 (Webhooks) 实现实时同步

Microsoft Graph API 提供了一种强大的机制，用于订阅Azure AD中各种资源（包括用户）的变更通知（即Webhooks）。这种方法非常适合在用户数据发生变化（包括删除）时接收即时警报。

工作原理

您的外部应用程序（例如PHP系统）向Microsoft Graph API订阅特定资源的变更通知（例如，/users）。
当订阅的资源发生指定类型的事件（例如，用户被删除）时，Graph API会向您配置的通知URL发送一个HTTP POST请求。
您的服务器接收并处理此请求，执行相应的用户删除操作。

配置步骤概览

注册订阅： 通过Graph API创建一个订阅。您需要指定以下关键参数：
- resource: 指定要监控的资源，例如 /users（或更具体的，如 /users/{id}）。
- changeType: 指定要接收的变更类型，例如 deleted（也可以是 created、updated 的组合）。
- notificationUrl: 您的PHP系统上用于接收通知的HTTPS端点。
- expirationDateTime: 订阅的有效期，到期后需要续订。
- clientState: 一个由您生成的秘密字符串，用于验证通知的来源，确保其来自Graph API。
验证通知URL： Graph API在创建订阅时会向您提供的notificationUrl发送一个验证请求。您的服务器必须正确响应此请求（通常是返回请求头中的validationToken），以确认URL的有效性。
处理接收到的通知：
- 验证来源： 接收到通知后，首先验证clientState是否与您订阅时提供的值匹配，以防止伪造通知。
- 解析负载： 解析通知的JSON负载，提取被删除用户的信息（通常是用户ID）。
- 执行操作： 在您的PHP系统中执行相应的用户删除操作。

示例 (创建订阅的cURL命令概念)

以下是一个使用cURL命令创建Graph API订阅的简化示例。在实际应用中，您需要通过OAuth 2.0流程获取有效的访问令牌。

arcgis-js

提供 ArcGIS Maps SDK for JavaScript 开发辅助，涵盖 2D/3D 地图视图、图层管理、数据可视化、空间分析等功能模块的参考和示例指导。

下载

curl -X POST "https://graph.microsoft.com/v1.0/subscriptions" \
     -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
           "changeType": "deleted",
           "notificationUrl": "https://your-php-app.com/api/azure-ad-webhook",
           "resource": "/users",
           "expirationDateTime": "2024-01-01T18:23:45.9356913Z",
           "clientState": "secretClientStateValue"
         }'

注意事项

notificationUrl必须是一个HTTPS端点，以确保数据传输的安全性。
Graph API订阅有有效期限制，您需要定期（在到期前）续订订阅以保持通知的连续性。
务必验证clientState，这是防止伪造通知的关键安全措施。
您的通知处理逻辑应具备幂等性，即能够处理重复的通知。Graph API可能会在某些情况下发送重复通知，您的系统应确保重复处理不会导致错误或不一致。

Azure AD 应用预配服务在用户删除场景下的行为

Azure AD的应用预配服务旨在自动化用户身份在Azure AD与SaaS应用之间的创建、维护和删除。虽然它确实处理用户删除，但其行为模式可能与实时通知的需求略有不同。

去预配机制

软删除 (Soft Delete): 当用户在Azure AD中被删除时，他们首先会被“软删除”，即移至回收站，并将其AccountEnabled属性设置为false。在此阶段，预配服务通常不会立即向目标应用发送删除请求。
永久删除 (Hard Delete):
- 用户在Azure AD中软删除30天后，会被永久删除。此时，预配服务会向目标应用发送一个DELETE请求，以永久删除该用户。
- 管理员也可以在30天窗口期内手动永久删除用户。一旦手动永久删除，预配服务也会立即发送DELETE请求到目标应用。

局限性

对于需要用户在Azure AD被软删除时就立即在外部系统同步删除的场景，单纯依赖预配服务可能无法满足实时性要求。因为它通常只在用户被永久删除时才触发DELETE请求，这可能存在长达30天的延迟。

选择合适的同步策略

根据您的业务需求和对实时性的要求，选择合适的同步策略至关重要：

实时性要求高： 如果您的应用程序需要用户在Azure AD被软删除时立即同步删除，Microsoft Graph API的变更通知（Webhooks）是首选方案。它提供了几乎实时的事件驱动机制，能够确保外部系统迅速响应用户状态变化。
最终一致性，且不需立即同步软删除： 如果您的系统可以接受用户在Azure AD被永久删除时才同步删除，或者您的应用预配配置已经能够处理AccountEnabled状态的变化，那么可以继续依赖Azure AD应用预配服务。请确保您的预配映射和作用域规则正确配置，以处理AccountEnabled为false时的去预配逻辑。

最佳实践与考量

安全性： 确保您的通知URL是安全的HTTPS端点，并实施严格的认证和授权机制（例如，验证clientState或使用其他签名验证方法）。
幂等性： 您的通知处理逻辑应能处理重复的通知。例如，如果收到两次相同的用户删除通知，第二次不应导致错误或不一致状态。
错误处理与重试： 您的通知处理服务应具备健壮的错误处理机制。如果处理失败，考虑将事件记录下来并实现重试机制，以确保最终一致性。
订阅管理： Graph API订阅有有效期，需要定期（例如，通过计划任务）续订以保持通知的连续性。
日志记录： 详细记录接收到的通知和执行的操作，以便于审计、故障排查和监控。

总结

为了在Azure AD用户被删除时及时通知集成应用并同步状态，Microsoft Graph API的变更通知（Webhooks）提供了最直接和实时的解决方案。而Azure AD的应用预配服务虽然也处理去预配，但其删除触发机制通常发生在用户被永久删除之后，可能存在时间延迟。根据您的业务对实时性的具体要求，选择最适合的同步策略并结合最佳实践，是构建健壮集成系统的关键。