I want the login system for an ASP.Net MVC 5 website be backed by Azure Active Directory.
Specifically I want to find out, whether the user is a member of a specific group and give access based on that.
I have code to query users/groups in AD, and only users from the AD get authenticated by Microsoft and redirected to the website.
But it seems that I need the user's principal name (UPN, ClaimTypes.Upn) to query the Azure AD graph API, while the OpenID Connect Provider just gives me some version of the user's e-mail address:
From OpenID Connect:
User.Identity.Name = live.com#timm#domain.tld
From AD Graph API:
user.UserPrincipalName = timm_domain#EXT#something.onmicrosoft.com
Is there any possibility to get the internal user GUID or get from one ID to the other in order to be able to query the AD graph API for the current user?
Indeed. Get the ObjectId of the user from the objectidentifier claim, using:
ClaimsPrincipal.Current.FindFirst("http://schemas.microsoft.com/identity/claims/objectidentifier").Value
UPN property is set by default for regular Organizational accounts - whereas you are signing is as an MSA (Microsoft Account) external user. MSA external users do not have the UPN property set by default. That said, you do not need the user's UPN to query their Group membership using Graph API - ObjectId is recommended. Further, we recommend that for authorization purpose, you use the getMemberGroup API that returns transitive group membership of the user.
Hope this helps.
For reference on other claim types: the raw JWT access token issued by Azure AD for an MSA external user looks like this:
{
"family_name": "Guest",
"unique_name": "Live.com#aadguest#outlook.com",
"altsecid": "1:Live.com:00034001C80D80E9",
"ver": "1.0",
"aud": "https://graph.windows.net",
"acr": "1",
"iss": "https://sts.windows.net/62e173e9-301e-423e-bcd4-29121ec1aa24/",
"oid": "fa6fa59a-5f2b-4069-a8e4-c76e52179f64",
"scp": "Directory.Read UserProfile.Read",
"idp": "Live.com",
"email": "aadguest#outlook.com",
"appidacr": "1",
"given_name": "AAD",
"exp": 1403260411,
"appid": "29181964-d91b-4331-859d-d815863848d6",
"tid": "62e173e9-301e-423e-bcd4-29121ec1aa24",
"iat": 1403256511,
"amr": [
"pwd"
],
"nbf": 1403256511,
"sub": "Wi6CVQ6FVj_aj3na076wm-C6eJy6CK6YhB3PR9Jpty0"
}
Related
I'm using Microsoft Graph API to create an application making an HTTP request using the following documentation:
https://learn.microsoft.com/en-us/graph/api/application-post-applications?view=graph-rest-1.0&tabs=http
Example:
POST https://graph.microsoft.com/v1.0/applications
Content-type: application/json
{
"displayName": "MyAppName",
"signInAudience": "AzureADMultipleOrgs"
}
But I need to add some API permissions (Microsoft Graph Application permissions) when creating the applications so I can do other operations like getting the Azure AD groups, modify them, create users, etc. Is there a way to add and grant the permissions programmatically as well without doing it through the portal?
Thank you.
Microsoft Graph object ID
The first thing you'll need is the object ID of Microsoft Graph service principal in your tenant.
00000003-0000-0000-c000-000000000000 is the globally unique application ID for Microsoft Graph, which we can use to get the object ID by making a request like below.
GET https://graph.microsoft.com/v1.0/servicePrincipals?$filter=appid eq '00000003-0000-0000-c000-000000000000'&$select=id,appid,appDisplayName
Example response
The object ID we need is the id in the response
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#servicePrincipals(id,appId,appDisplayName)",
"value": [
{
"id": "bd0a624d-11f8-44ab-a015-d8f276d75ad3",
"appId": "00000003-0000-0000-c000-000000000000",
"appDisplayName": "Microsoft Graph"
}
]
}
References
Application IDs for commonly used Microsoft applications
Adding API Permissions
You can add the API permissions, which is separate from granting admin consent.
PATCH https://graph.microsoft.com/v1.0/applications/{application_id}
Headers
Key
Value
Authorization
Bearer {access token}
Content-Type
application/json
Body
Key
Value
resourceAppId
The API resource to add permissions from, in this case 00000003-0000-0000-c000-000000000000 is for Microsoft Graph
resourceAccess
Array of permissions containing the ID and type
id
Use the globally unique ID of the permission want to add, which you can reference from All permissions and IDs
type
For delegated permissions, use Scope. For application permissions, use Role
Example body
The below permissions are for User.Read (delegated), openid (delegated), and Directory.Read.All (application)
{
"requiredResourceAccess": [
{
"resourceAppId": "00000003-0000-0000-c000-000000000000",
"resourceAccess": [
{
"id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
"type": "Scope"
},
{
"id": "37f7f235-527c-4136-accd-4a02d197296e",
"type": "Scope"
},
{
"id": "7ab1d382-f21e-4acd-a863-ba3e13f7da61",
"type": "Role"
}
]
}
]
}
References
Update application API endpoint
requiredResourceAccess resource type
resourceAccess resource type
Granting admin consent
Important to note that you can only grant admin consent with the API for delegated permissions. For application permissions, you'll need to use the Portal and click the button.
POST https://graph.microsoft.com/v1.0/oauth2PermissionGrants
Headers
Key
Value
Authorization
Bearer {access token}
Body
Key
Value
clientId
The Enterprise Application object ID for which you want to grant consent to
consentType
Indicates if authorization is granted for the client application to impersonate all users or only a specific user. AllPrincipals indicates authorization to impersonate all users. Principal indicates authorization to impersonate a specific user. Consent on behalf of all users can be granted by an administrator. Non-admin users may be authorized to consent on behalf of themselves in some cases, for some delegated permissions. Required. Supports $filter (eq only).
resourceId
Use the object ID we obtained earlier for the Microsoft Graph service principal
scope
A space-separated list of the claim values for delegated permissions which you want to grant admin consent to
Example body
{
"clientId": "7f244605-717f-408f-96fb-d369678cea56",
"consentType": "AllPrincipals",
"resourceId": "bd0a624d-11f8-44ab-a015-d8f276d75ad3",
"scope": "openid User.Read"
}
References
Create oAuth2PermissionGrant API endpoint
oAuth2PermissionGrant resource type
Unless you’re creating more then 10 applications, I would just go through the portal.
Creating secrets through the api is not very easy.
The portal has wizards and explanations for most options
Granting permissions and creating applications can be done at the same time, you can also create the application and then have an admin do the admin consent.
Admin consent explained: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow#request-the-permissions-from-a-directory-admin
I am building an application where users login via azure (oauth).
Now I want to find the logged in user in the local active directory, but how can I do that?
There is a promising objectId in the azure web admin ui but I can't find anywhere in my local AD.
I can't use the upn neither because the are not the same in azure as on my local ad.
There must be a way because the aad sync can keep track of changes as well.
This is the information the access token provides:
{
"aud": "00000003-0000-0000-c000-000000000000",
"iss": "https://sts.windows.net/3173e872-f73b-47d0-81c6-75e3ac726c21/",
"iat": 1637937947,
"nbf": 1637937947,
"exp": 1637943631,
"acct": 0,
"acr": "1",
"acrs": [
"urn:user:registersecurityinfo"
],
"aio": "ASQA2/8TAAAAha246r1Y5HNoFGcBvCtPqcvDnjil+dqoybNz9Gk57kk=",
"amr": [
"pwd"
],
"app_displayname": "myapp",
"appid": "b958b44a-3b5c-14ac-b245-126b7524b35c",
"appidacr": "0",
"family_name": "Lustig",
"given_name": "Linda",
"idtyp": "user",
"ipaddr": "188.31.41.234",
"name": "Linda Lustig",
"oid": "9da1be1d-af4f-4d26-a9e7-e7e7a692471b",
"onprem_sid":
"S-1-5-21-4559353447-1638600113-3447510865-117118",
"platf": "8",
"puid": "1003200160C8DCC6",
"rh": "0.AXkAcuhzMTv30EeBxnXjrHJsIUu0iLlcXaxEs0dkayUks1x5AO0.",
"scp": "openid profile email",
"sub": "zpFbfmWNaR4YWYhWKHNEf3rVHVlavGX8DVQVQpPst_c",
"tenant_region_scope": "EU",
"tid": "3173e872-b76b-27d0-51c6-75e3ac726c21",
"unique_name": "lustig#mycompany.onmicrosoft.com",
"upn": "lustig#mycompany.onmicrosoft.com",
"uti": "nAcNGfeFek6iNmBwoJ9iAQ",
"ver": "1.0",
"xms_st": {
"sub": "3CEB7AUcrDeE6SKT1qde_FXWVeK9ppxZB576-PaIfwY"
},
"xms_tcdt": 1547151622
}
• Whenever the Azure AD Connect runs and starts synchronizing, it runs a check on every object in the Active Directory and tries to match the existing object in Azure AD as well. There are three attributes that are used for this process, viz., userPrincipalName(UPN), proxyAddresses and sourceAnchor. Thus, a match on userPrincipalName and proxyAddresses is known as a soft match and a match on sourceAnchor is known as hard match. Also, please note that for proxyAddresses attribute, the SMTP attribute in AD is considered as primary email address and used.
• Thus, since as you said, UPN isn’t matching, you can try matching the other two attributes with on premises ones for finding the local users. Also, please note that sourceAnchor attribute is created when on premises AD attributes are first synced with Azure AD. After that, they remain the same for those identities synced and don’t change later unless changed externally. So, to locate the users based on sourceAnchor attribute, you can locate the equivalent attribute in Active Directory, i.e., ObjectGUID or ms-DS-ConsistencyGuid in on premises AD related to the identities that you are trying to locate.
Please refer the following link for more detailed information: -
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-existing-tenant#sync-with-existing-users-in-azure-ad
When creating multi-tenant apps that will use Azure AD Authentication to sign users in, various samples on GitHub seem to suggest that the App Registration should include the following permissions clubbed under OpenId.
email View users' email address
offline_access Maintain access to data you have given it access to
openid Sign users in
profile View users' basic profile
(See for example: https://github.com/OfficeDev/microsoft-teams-sample-auth-node Section 12)
While following the samples on the Azure portal itself, the quickstarts create an App registration with just this one permission
User.Read Sign in and read user profile
Is Microsoft's Azure AD User.Read permission a superset of the generic openid's email, openid and profile permissions?
When creating a consent URL in the https://login.microsoftonline.com/common/adminconsent?client_id={client-id} form, only the User.Read seems to appear.
What is the recommended set of permissions that are recommended for a basic app that needs to sign users in?
I just spent quite a while testing this as part of my own learning today, and here's what I found.
tl;dr
The openid scope will get you an id_token, and an access_token that allows you to call the UserInfo endpoint (https://graph.microsoft.com/oidc/userinfo). If you want to call any of the Graph APIs, (other than UserInfo) then you'll want (at least) the User.Read scope.
The Details
I have a test AzureAD tenant in which I created a brand-new client app registration (with a SPA endpoint) and a brand-new user, thus ensuring there was no residual 'consent' anywhere.
I then used the browser to sign-in with a hand-crafted URL to request only the openid scope. With line breaks added and some chars redacted this was:
https://login.microsoftonline.com/a8257b21-...6263/oauth2/v2.0/authorize?
client_id=b3f87624-...e5b&
response_type=code&
redirect_uri=https://localhost&
response_mode=query&
scope=openid&
state=12345&
code_challenge=LrTIpxRwK...
code_challenge_method=S256&
prompt=login
For this I got the below consent prompt:
It's interesting to note that it asked to "View your basic profile" and "Maintain access to data..." when I didn't ask for profile or offline_access scopes.
I extracted the authorization code from the response and sent it to the https://login.microsoftonline.com/{{tenant_id}}/oauth2/v2.0/token endpoint with the necessary fields.
The id_token I got back didn't include claims the profile scope would imply, showing only the below
{
"aud": "b3f87624-...2fb5367e5b",
"iss": "https://login.microsoftonline.com/a8257b21...263/v2.0",
"iat": 1642367777,
"nbf": 1642367777,
"exp": 1642371677,
"rh": "0.AUYAIXs...L7U2fluAAB0.",
"sub": "tcK...WXUvzWqAc",
"tid": "a82...6263",
"uti": "SjLRuw...jlhAA",
"ver": "2.0"
}
However interestingly the access_token it returned is for the Graph audience (00000003-0000-0000-c000-000000000000) did list the scopes as including profile and email, and did include claims related to those, e.g. (with some omitted for clarity)
{
"aud": "00000003-0000-0000-c000-000000000000",
"iss": "https://sts.windows.net/a82...6263/",
"app_displayname": "TestApp",
"appid": "b3f87...67e5b",
"family_name": "Bull",
"given_name": "Pit",
"idtyp": "user",
"ipaddr": "67.183.2.129",
"name": "Pit Bull",
"oid": "08a5...673de",
"scp": "openid profile email",
"sub": "6JrD7...phCH7Y",
"tid": "a825...36263",
"unique_name": "pit#example.dev",
"upn": "pit#example.dev",
"ver": "1.0"
}
(Note: Obviously you shouldn't look in tokens that aren't for your audience, but it's all there in clear text, so?)
I did also get a refresh token back, which I saved for later.
With that access token I could call the UserInfo endpoint and also see the *name claims, which would indicate profile scope (I forget to set the email on my test user, else I'm guessing that would have shown too).
From https://graph.microsoft.com/oidc/userinfo
{
"sub": "tcK6D...UvzWqAc",
"name": "Pit Bull",
"family_name": "Bull",
"given_name": "Pit",
"picture": "https://graph.microsoft.com/v1.0/me/photo/$value"
}
However, with that same access token, if I tried to call any Graph APIs such as https://graph.microsoft.com/v1.0/me or https://graph.microsoft.com/v1.0/organization I was met with the following response.
{
"error": {
"code": "Authorization_RequestDenied",
"message": "Insufficient privileges to complete the operation.",
"innerError": {
"date": "2022-01-16T21:52:18",
"request-id": "e4f58...1611",
"client-request-id": "e4f5...a1611"
}
}
}
By running through the same flow again but this time with the scopes openid profile email, the only difference I could ascertain was that the id_token now included the below claims (and again, probably would have had the email address if I'd configured it on the account)
"name": "Pit Bull",
"oid": "08a5...73de",
"preferred_username": "pit#example.dev",
The access token looked the same, and the UserInfo result was the same (which makes sense if the access_token to auth to it looked the same). I'd also note I didn't get prompted for any additional consent, which would imply profile and email were implicitly added to my initial openid-only scope request.
At this point I took a break to feed the kids, and when I came back a couple hours later decided to try out the refresh token I received (without requesting offline_access scope). It worked fine and I got refreshed tokens, so this seems to be implicitly added also when just requesting openid.
For my next test I sent the same hand-crafted request to authenticate but included the User.Read scope. As expected, I got prompted for the additional consent:
It's interesting to note how it mentions "..and read basic company information". This aligns with the docs at https://learn.microsoft.com/en-us/graph/permissions-reference which state of User.Read: "With the User.Read permission, an app can also read the basic company information of the signed-in user for a work or school account through the organization resource.".
All the tokens I got back from this looked similar to before, but obviously with the addition of the User.Read scp in the access token. Now making requests to certain Graph APIs was met with success. For example:
https://graph.microsoft.com/v1.0/me or https://graph.microsoft.com/v1.0/users/pit#example.dev
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#users/$entity",
"businessPhones": [],
"displayName": "Pit Bull",
"givenName": "Pit",
"jobTitle": null,
"mail": null,
"mobilePhone": null,
"officeLocation": null,
"preferredLanguage": null,
"surname": "Bull",
"userPrincipalName": "pit#example.dev",
"id": "08a53...b673de"
}
https://graph.microsoft.com/v1.0/me/directReports (I didn't have any direct reports configured, but it was a successful query rather than access denied)
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#directoryObjects",
"value": []
}
And https://graph.microsoft.com/v1.0/organization (trimmed for readability - and again, I'd not set up org details for this account, hence the nulls)
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#organization",
"value": [
{
"id": "a8257...736263",
"businessPhones": [],
"city": null,
"country": null,
"postalCode": null,
"preferredLanguage": null,
"state": null,
"tenantType": "AAD",
"directorySizeQuota": {
"used": 39,
"total": 300000
},
"verifiedDomains": [
{
"capabilities": "Email, OfficeCommunicationsOnline",
"isDefault": false,
"isInitial": true,
"name": "example.onmicrosoft.com",
"type": "Managed"
},
{
"capabilities": "None",
"isDefault": true,
"isInitial": false,
"name": "example.dev",
"type": "Managed"
}
]
}
]
}
So there you have it. Add User.Read if you want to query anything from the Graph APIs, else just use openid (and optionally profile email) if you are happy just signing users in and using the id_token for your needs.
As a footnote to this I'd also recommend reading the couple paragraphs at https://learn.microsoft.com/en-us/graph/permissions-reference#remarks-15 . I was only testing with a v2 endpoint, but it does look like User.Read used to be required just to sign-in with the v1 endpoint, so it being included by default may be a residual effect of that. As it states of the V1 endpoint: "To successfully return an ID token, you must also make sure that the User.Read permission is configured when you register your app."
Hence the question if user.read subsumes open_id, email and profile
perms?
No, user.read does not contain them, they are independent permissions.
I have set these required perms but in the consent popup shown to the
Azure AD admin, email and profile and openid permissions do not show
up; only offlne_access and user.read shows.
email offline_access openid profile is usually the permissions of the OIDC protocol. There are some differences between oauth2.0 and openid connect. If you only need to log in as a user, you only need to use openid connect, and it will only return you the id token of the logged in user. Regarding why the email openid profile is not displayed on the admin consent page, I think this is a problem that is still being fixed, but I don’t think you need to worry about these because these permissions themselves are permissions that do not require the administrator’s consent. When you add them in API permissions, you can use them directly.
At this time, the offline_access ("Maintain access to data you have given it access to") and user.read ("Sign you in and read your profile") permissions are automatically included in the initial consent to an application. These permissions are generally required for proper app functionality - offline_access gives the app access to refresh tokens, critical for native and web apps, while user.read gives access to the sub claim, allowing the client or app to correctly identify the user over time and access rudimentary user information. please refer to this document
I am creating an outlook add-in and am trying to use the SSO access token as authorisation for my backend.
I have the flow working. I trigger my Add-In, get the access token and use the access token to "login" to my backend.
However, the issue I have is that I am not getting the email claim in the token despite a) adding it to the API permissions in the Azure App Registration, b) adding to the WebApplicationInfo. Should I be receiving it?
Azure App Registration Permissions
Web Application Info
<WebApplicationInfo>
<Id>xxx</Id>
<Resource>api://localhost:3000/xxx</Resource>
<Scopes>
<Scope>openid</Scope>
<Scope>User.Read</Scope>
<Scope>profile</Scope>
<Scope>email</Scope>
</Scopes>
</WebApplicationInfo>
Code to receive token
OfficeRuntime.auth.getAccessToken( { allowSignInPrompt: true })
Token received
{
"aud": "api://localhost:3000/xxx",
"iss": "https://sts.windows.net/my_tenant_id/",
"iat": 1605992211,
"nbf": 1605992211,
"exp": 1605999711,
"acr": "1",
"aio": "E2RgYDDdzii4P/xP/cPTbg4lPk7dJ6c8aQnapLU19aiV+Zy400sA",
"amr": [
"pwd"
],
"appid": "xxx",
"appidacr": "0",
"family_name": "Adams",
"given_name": "Iain",
"ipaddr": "51.111.111.111",
"name": "Iain Adams",
"oid": "my_oid",
"pwd_exp": "157262",
"pwd_url": "https://portal.microsoftonline.com/ChangePassword.aspx",
"rh": "0.AAAAmj9NLsNP80SAITLYeWEJg9YOWdOzUgJBrv-q0ikqsBxHANs.",
"scp": "access_as_user",
"sub": "my_sub",
"tid": "my_tenant",
"unique_name": "iain#abc.com",
"upn": "iain#abc.com",
"uti": "1KNbNttkDUCrKXblaK5BAA",
"ver": "1.0"
}
Whilst I know the email address is being returned in the upn and unique_name claims, AND, I know that oid should be used as the unique identifier for this user, however, I need to lookup based on email address (if it exists).
You need to customize the access token configuration and then add the email as an optional claim. Go to azure portal>App registrations>your app>Token configuration.
Parse the token:
You need to pay attention to: For managed users (the users inside the tenant), it must be requested through this optional claim or, on v2.0 only, with the OpenID scope.
See: Document.
The "Email" value is part of optional claims. It's included by default if the user is a guest in the tenant. For managed users (it means, the users inside the tenant), it must be requested through this optional claim or, on v2.0 only, with the OpenID scope. For managed users, the email address must be set in the Office admin portal (https://portal.office.com/adminportal/home#/users).
I have a variety of graph permissions assigned to different web apps in Azure. Is there any way in which I can map these graph permissions back to Azure AD roles and identify which role is the permission assigned to? I need this to implement access control based on the signed-in user
Graph permissions are granted for Azure AD app. Azure AD role is to manage Azure AD rather than API permission. There is no mapping between them.
What you are looking for is appRole.
"appRoles": [
{
"allowedMemberTypes": [
"User"
],
"displayName": "Writer",
"id": "d1c2ade8-98f8-45fd-aa4a-6d06b947c66f",
"isEnabled": true,
"description": "Writers Have the ability to create tasks.",
"value": "{the custom role name}"
}
]
A sample for your reference: Authorization in a web app using Azure AD application roles & role claims.
Update
You need to add the needed Graph permissions in Azure AD APP and then control the permissions in your code.
We assume you have assigned a custom role in an Azure AD app and added a user to this role.
When a user signs in, a token which includes the role claim will be returned.
You can judge the user's role in the code. If it matches a custom appRole, he is allowed to perform an operation, such as user-invite-all . If the user does not match any of the appRoles, he does not have permission to perform any operations.
[HttpPost]
[Authorize(Roles = "Admin, Writer, Approver")]
public ActionResult TaskSubmit(FormCollection formCollection)
{
if (User.IsInRole("Admin") || User.IsInRole("Writer"))
//do something such as inviting others.
{
Please dig deeper into the sample code I shared above.
PS: Note that I have modified the value in "appRoles" in my previous answer.