AzureAD用户删除同步方法详解

一分耕耘，一分收获！既然都打开这篇《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）。这种方法非常适合在用户数据发生变化（包括删除）时接收即时警报。

工作原理

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

配置步骤概览

1. 注册订阅： 通过Graph API创建一个订阅。您需要指定以下关键参数：

   • resource: 指定要监控的资源，例如 /users（或更具体的，如 /users/{id}）。
   • changeType: 指定要接收的变更类型，例如 deleted（也可以是 created、updated 的组合）。
   • notificationUrl: 您的PHP系统上用于接收通知的HTTPS端点。
   • expirationDateTime: 订阅的有效期，到期后需要续订。
   • clientState: 一个由您生成的秘密字符串，用于验证通知的来源，确保其来自Graph API。

2. 验证通知URL： Graph API在创建订阅时会向您提供的notificationUrl发送一个验证请求。您的服务器必须正确响应此请求（通常是返回请求头中的validationToken），以确认URL的有效性。

3. 处理接收到的通知：

   • 验证来源： 接收到通知后，首先验证clientState是否与您订阅时提供的值匹配，以防止伪造通知。
   • 解析负载： 解析通知的JSON负载，提取被删除用户的信息（通常是用户ID）。
   • 执行操作： 在您的PHP系统中执行相应的用户删除操作。

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

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

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的应用预配服务虽然也处理去预配，但其删除触发机制通常发生在用户被永久删除之后，可能存在时间延迟。根据您的业务对实时性的具体要求，选择最适合的同步策略并结合最佳实践，是构建健壮集成系统的关键。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。