英文:
App roles & groups claim (emitted as roles) in Azure Active Directory App
问题
我已经注册了一个名为read
的Azure AD应用程序
,其中包含一个App角色
。
用户主体
如果将用户主体分配给read
应用角色,并在Azure AD应用程序中添加了groups
声明(启用了emit_as_roles
),则用户的令牌(roles
声明)中仅会显示AAD安全组,而不会显示用户被分配的应用程序角色。这在文档中有提到:
> 如果使用了“emit_as_roles”,则用户分配的任何应用程序角色都不会出现在角色声明中。
服务主体
显然,对于服务主体,似乎也适用相同的规则,尽管如下所述:
如预期的那样,默认禁用token
配置中的emit_as_roles
设置会再次允许我在roles
声明中看到read
信息。
我认为这是Azure AD中服务主体的_预期_行为。但是,文档只提到了用户,而没有提到服务主体。
英文:
I have registered an Azure AD Application with an App role
called read
.
User Principal
If a user principal is assigned to the app role read
and the groups
claim (emit_as_roles
enabled) is added in the Azure AD App, only the AAD security groups show up in the user's token (roles
claim) but not the app roles the user has been assigned to.
This is mentioned in the documentation:
Service Principal
Apparently, the same seems to apply for Service Principals, even though
> Service principals won't have group optional claims emitted in the JWT.
As expected, disabling (default) the emit_as_roles
setting in the token configuration allows me to see the information read
in the roles
claim again.
I assume that this is the expected behaviour for service principals in Azure AD. However, the documentation only mentions this for users but not for service principals.
答案1
得分: 2
你说得对。这是Azure AD中用户和服务主体的预期行为。
由于服务主体是服务的安全主体,但在用户术语中它是用户主体。
因此,当启用了“emit_as_roles”用于组声明时,分配给用户或服务主体的任何应用程序角色将不会出现在角色声明中。
我已经检查了令牌:
在组声明中启用了emit_as_roles时:
令牌URL:https://login.microsoftonline.com/xxx/oauth2/v2.0/token
令牌声明:
{
"aud": "https://graph.microsoft.com",
"iss": "https://sts.windows.net/4xx/",
"iat": 1684912827,
"nbf": 1684912827,
"exp": 1684917432,
"acct": 0,
"acr": "1",
"aio": "AYQAexxxx",
"altsecid": "5::100xx14397",
"amr": [
"rsa",
"mfa"
],
"app_displayname": "kavyarepo",
"appid": "xxx",
"appidacr": "1",
"email": "xxx@microsoft.com",
"family_name": "Kavya",
"given_name": "xx",
"idp": "https://sts.windows.net/xxxx/",
"idtyp": "user",
"ipaddr": "115.110.154.186",
"name": "xxx",
"oid": "xxx",
"platf": "3",
"puid": "100xxxC5",
"rh": "0.xxxx.",
"scp": "Directory.AccessAsUser.All openid profile User.Read User.Read.All email",
"sub": "xxxx",
"tenant_region_scope": "NA",
"tid": "xxx",
"unique_name": "xxx@microsoft.com",
"uti": "p6nDIxxxxsjAzAA",
"ver": "1.0",
"wids": [
"xxxx",
"xxxx",
"xxx"
]
}
如果需要在令牌中包括应用程序角色,无论是对用户还是服务主体,必须禁用“emit_as_roles”选项。
英文:
You are right. This is the expected behavior for both users and service principals in Azure AD.
As service principals are security principal for a service ,but in user terms it is user principal .
So when the "emit_as_roles" is enabled for the groups claim, any application roles assigned to the user or service principal will not appear in the roles claim.
I have checked the token:
When enabled emit_as_roles in the groups claim:
Authorize url:
https://login.microsoftonline.com/xxx/oauth2/v2.0/authorize?client_id=xxxbb5&scope=https://graph.microsoft.com/.default&grant_type =authorization_code&response_type=code&redirect_uri=https://jwt.ms
Token url
token claims:
https://login.microsoftonline.com/xxx/oauth2/v2.0/token
{
"aud": "https://graph.microsoft.com",
"iss": "https://sts.windows.net/4xx/",
"iat": 1684912827,
"nbf": 1684912827,
"exp": 1684917432,
"acct": 0,
"acr": "1",
"aio": "AYQAexxxx",
"altsecid": "5::100xx14397",
"amr": [
"rsa",
"mfa"
],
"app_displayname": "kavyarepo",
"appid": "xxx",
"appidacr": "1",
"email": "xxx@microsoft.com",
"family_name": "Kavya",
"given_name": "xx",
"idp": "https://sts.windows.net/xxxx/",
"idtyp": "user",
"ipaddr": "115.110.154.186",
"name": "xxx",
"oid": "xxx",
"platf": "3",
"puid": "100xxxC5",
"rh": "0.xxxx.",
"scp": "Directory.AccessAsUser.All openid profile User.Read User.Read.All email",
"sub": "xxxx",
"tenant_region_scope": "NA",
"tid": "xxx",
"unique_name": "xxx@microsoft.com",
"uti": "p6nDIxxxxsjAzAA",
"ver": "1.0",
"wids": [
"xxxx",
"xxxx",
"xxx"
],
If application roles need to be included in token, for both user and service principals, the "emit_as_roles" option must be disabled.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论