我使用AAD Graph API在Azure AD中创建了一个新应用程序。 (code)
不幸的是,在我访问Azure管理门户中的应用程序配置页面并进行外观修改然后保存之前,它不允许我的客户端访问所请求的资源。删除更改并再次保存后,它仍然有效。 更改前的应用程序清单文件+更改后的步骤以及它们之后的完全相同(如diff.exe中的说明它们是相同的)。
在比较应用程序进行身份验证时返回的JWT令牌时,它会显示更改后的访问令牌包含“角色”部分。在将应用程序保存在管理门户中之前返回的访问令牌中不存在整个“角色”部分。
因此,在保存更改时,Azure管理门户似乎会对应用程序执行“某些操作”。问题是它是什么,我可以使用AAD图API来做同样的事情吗?
答案 0 :(得分:1)
有几个问题。 Azure上后端的一些错误现已修复,还有一些我不知道的API调用缺失是必要的。 感谢MS Support的一些非常有帮助的人,我们能够让它发挥作用。
创建应用程序时,您需要执行以下操作:
最后一部分是我以前缺少的。即使您已在应用程序对象上配置了RequiredResourceAccess,服务主体仍然需要AppRoleAssignments实际拥有访问资源的权限。
在创建AppRoleAssignments时,弄清楚要分配哪个PrincipalId有点棘手,因为那是另一个资源的服务主体的AAD ObjectId。
以下是添加AppRoleAssignment以访问Azure AD Graph API的代码段。 client
是ActiveDirectoryClient个实例,sp
是我的应用程序的ServicePrincipal:
// find the azure ad service principal
var aadsp =
client.ServicePrincipals.Where(csp => csp.AppId == "00000002-0000-0000-c000-000000000000")
.ExecuteSingleAsync().Result;
// create the app role assignment
var azureDirectoryReadAssignment = new AppRoleAssignment
{
PrincipalType = "ServicePrincipal",
PrincipalId = Guid.Parse(sp.ObjectId), //
Id = Guid.Parse("5778995a-e1bf-45b8-affa-663a9f3f4d04"), // id for Directory.Read
// azure active directory resource ID
ResourceId = Guid.Parse(aadsp.ObjectId) // azure active directory resource ID
};
// add it to the service principal
sp.AppRoleAssignments.Add(azureDirectoryReadAssignment);
// update the service principal in AAD
await sp.UpdateAsync();
我的经验是,您需要等待很短的时间,可能需要2-3分钟,然后才能在AAD中新创建的对象生效,然后您可以使用新的应用程序进行身份验证。
答案 1 :(得分:0)
除了RasmusW上面的回答之外,根据你想要达到的目标,还有一些你可能需要做的事情。