在Azure API管理(APIM)中拥有一个API。API操作使用后端应用程序注册的作用域(作用域不是)验证Azure Active Directory (AAD)生成的JWT。User.Read
)。注意:客户端id是另一个应用注册,它是该后端作用域的授权应用。
在JWT验证之后,我是否能够获取该令牌,从中提取用户信息并验证用户是否属于电子邮件分发列表(DL)的一部分?如果是这样,如何在APIM策略中实现它?
我知道MS图形api。使用Postman,我可以确认DL在租户的组中列出,并可以获得其组ID。我也可以确认这个用户是这个群组的成员。我坚持图形API的位是,它需要一个不同的令牌由客户端应用程序提供的(由于范围是从不同的域自定义应用程序注册vs图形),我被困在这一点。我是否应该让客户端应用程序也得到一个图形令牌,并在一个单独的头传递它,或者有办法从APIM或其他东西内编排的东西?
此解决方案的非apim部分由Microsoft的一篇文章提供。我在以下步骤中总结了这些内容,并将其与APIM部分结合起来:
- 在Azure中,创建一个新的Azure应用程序注册(稍后注意客户端id)
- 在"证书和秘密"下,添加客户端秘密(注意后面的秘密)
- 在"API permissions"下,添加一个新的MS Graph Application Permission(根据您的情况,可以是
User.Read.All
,Group.Read.All
,GroupMember.Read.All
)。MS Graph的"组";包括AD组和分发列表(DL)。注意:不要使用委派权限。 - 应用程序权限允许授权的应用程序查询任何用户/组。你将需要一个Azure管理员来授予管理员同意,以便应用程序注册具有所选的应用程序权限。
- 现在在Azure APIM中,转到您的API并编辑入站策略。
- 验证来自发起调用的用户的JWT(参见
validate-jwt
或更新的validate-azure-ad-token
)以确保用户被授权调用此API。 从JWT中提取 - 使用
client-credentials
流为MS Graph添加send-request
策略请求和认证令牌(这是当您需要早期应用程序注册的客户端id和secret时)。注意:秘密应该存储在像KeyVault这样的安全存储中,但这超出了本文的范围。 - 从JSON响应体中提取
access_token
字段,并使用set-variable
策略将其放入变量中。 - 创建另一个
send-request
策略,但这次是到MS Graph端点。对于User.Read.All
权限,您将使用/users/<userIdFromJwtOidClaim>/memberof/<groupId>
。MS Graph v1.0 API引用,并使用<set-header>
元素在授权头中传递access_token
。 - 状态码为200表示用户属于该组。状态码403表示用户不是该组的成员。
- 使用
choose
策略根据用户的组成员身份执行逻辑。 - 使用
return-response
策略向用户发送响应。
oid
声明(这是我将用于图形调用的用户ID),并使用set-variable
策略将其保存在变量中