We are using Azure AD OWIN to authenticate the user in a MVC application.
When I need to get the user's name or even preferred_username, I look at these properties. But the name is null.
HttpContext.User.Identity.Name = null
User.Identity.Name = null
But the Claims property under Identity contain the values that I need.
How can I get the Claims properties values under Identity, such as "name" or "preferred_username"?
have you tried using the Azure AD attributes? "displayName" might work. Please let me know if this works.
Best,
James
Related
I am integrating AzureAD with a SCIM endpoint. So far integration seems to work: AzureAD sends "POST" requests to create users, then later it queries/updates users using their 'id'.
Reminder from SCIM standard (RFC 7643): The 'id' is
A unique identifier for a SCIM resource as defined by the service provider
My SCIM endpoint generates this unique ID upon user first creation. It sends this ID to AzureAD in the reply, as required by the standard. I know that AzureAD stores the ID somewhere, because it uses it in subsequent requests.
My question: where is this ID stored in AzureAD? I need to read it, so I can forward it somewhere else. Using Graph Explorer I tried a lot of properties:
https://graph.microsoft.com/v1.0/me?$select=id,userPrincipalName,extensions,employeeId,externalUserState,identities,externalId
But none of them work. They are empty or do not contain the SCIM id.
Does anyone know if the property is publicly available?
Azure AD Provisioning has an internal data store that is not exposed via any external/customer-facing APIs where this is stored. If the service is evaluating an object that it does not know the SCIM ID value for it will try to locate that using a filtered GET such as GET /Users?filter=userName eq "user#domain.com", but once it has located that object the service will store internally a record stating that object X in Azure AD with objectId value of 123 is matched to object Y in with ID value of 456.
To specifically answer your end goal of "I need to find this value in Azure AD and forward it somewhere else" - this is not possible.
It is not like you think that AAD will save the user id from SCIM.
You can use Provision on demand to understand how it works.
Simple steps:
Click on "Provision on demand" in SCIM enterprise app.
Then select an AAD user and click on "Provision".
After it is executed successfully, you will be able to see the following:
Import user is retrieving User from Azure Active Directory.
Determine if user is in scope is determining if User in scope by evaluating against each scoping filter.
Match user between source and target system is retrieving User from SCIM and matching it with the AAD User in step 1. This is the point that you didn't know before. AAD will Get User by query in this step.
GET /Users?filter=userName eq "{userName}"
Then the user id from SCIM will be returned (As above screenshot shows).
Perform action updates User in SCIM using the id from step 3.
So AAD doesn't store the id from SCIM. It queries the user in SCIM firstly to get the id and then use this id to send update request to SCIM endpoint.
I'm setting up SAML SSO for an application. I have it working except that I'm unable to return a suitable value for the NameID claim. Existing userid's in the application are firstname + last initial so they don't match display names, email addresses, or any of the typical stuff found in Azure AD. I could use a transform to generate that but the available functions don't appear to do what I need.
I could also manually enter the userid in Azure AD and then map the claim to that but I hate to "misuse" an existing field (e.g. putting the userid in user.jobtitle or some such).
I also don't want to have to change everyone's userid in the app to match something that already exists in Azure.
I feel like I'm missing something obvious here since there have to be a lot of apps that don't use a common Azure property as their userid.
Thanks in advance for any help here!
Tom
You can map the attributes & claims present in the active directory to your app fields. For example if user.givenname is present in the active directory and in your app, the field name is firstName, you can achieve this by doing the mapping in manage claim section of User attributes & claims. Same could be done for others fields.
You go into the Enterprise applications > Your App > SAML-based Sign-on > click on edit
I have a Microsoft Teams tab app and I'm using SSO for authentication. My users are both native and guests. My requirement is to show different screens depending on the type of incoming user (native/guest), so I have to identify the user type first. To ensure security, I first obtain the id token for the incoming user and then validate it first before identifying the user type. Is there any reliable way to identify the incoming user type with just the id token? I don't trust the info in tab context.
If you don't want to use Microsoft Graph API, you could add all the guest user into a security Group and include Groups claim in your token as instructed here. You just need to modify the "groupMembershipClaims" field in application manifest:
"groupMembershipClaims": "SecurityGroup"
Then the ID token will contain the Ids of the groups that the use belongs to like below :
{
"groups": ["1ce9c55a-9826-4e32-871c-a8488144bb32"]
}
You can also Add app roles in your application and receive them in the token.
You can use microsoft graph api(beta) get user.
https://graph.microsoft.com/v1.0/users/{id | userPrincipalName}
If the id token contains objectId of the user, just put the objectId as the parameter of this api. In the response, we can find an attribute userType. The value of this attribute could be Member or Guest.
If the id token doesn't contain objectId of the user, just contains email. We can also put it as the parameter in the graph api, but if the email is a guest user, the api will not get response data. So I asked you if it contains objectId in the comments.
By the way, the attribute userType just exists in the beta version of microsoft graph api but not exist in the v1.0 version microsoft graph api. So if you're not comfortable with beta version, I suggest to use Azure AD graph api(get user) instead of Microsoft graph api.
Hope it helps~
I've created a 'customerId' user attributes in my development AD B2C tenant. When querying these via the graph API I now get the following;
"extension_b0ba955412524ac8be63e24fa7eb0c23_customerId": "2"
Perfect! I use JSON.Net to convert this to a strongly typed object, and hence my POCO has the following property.
public string extension_b0ba955412524ac8be63e24fa7eb0c23_customerId { get; set; }
Not great, but I can live with it. My concern is that when I create these properties in our staging and production environments, the attribute names will change and I will have to rewrite a lot of code. How do I migrate these user attributes to our other environments, ensuring the property names do not change?
Custom user attributes in Azure AD B2C will always have a guid in the name that's unique per Azure AD B2C tenant.
This guid is the Application ID of the 'b2c-extensions-app' and will be the same for all custom attributes within a tenant, but different across tenants.
Given this behavior, you could make the code that handles custom user attributes dynamic such that it derives the full name* using the following pattern:
extension_<appId>_<attributeName>
And obtain the appID via the Graph:
https://graph.windows.net/yourtenant.onmicrosoft.com/applications?$filter=displayName eq 'b2c-extensions-app'
Of course, you can always provide feedback requesting that this is made easier in in the Azure AD B2C feedback forum.
We're using Active Directory to manage some of the accounts in our Sitecore instance. In the database the usernames are in the domain\username format (as you'd expect).
In Sitecore, I can do
var user = User.FromName(item["__Created by"], true)
and I get back a user object, but I can't seem to get the Guid associated with the user in the aspnet_Users table.
Other than using AD, we're not doing anything funny with the membership provider.
Edit: I probably should have stated: I've got the ProviderUserKey but it's not the UserId from the aspnet_Users table as it would be if this were using the membership provider that comes with Sitecore, it's very different (it's of type System.Security.Principal.IdentityReference.SecurityIdentifier if anyone is interested)
This is not possible without directly querying the database. You could write an extension method that queries the database for the User, but I would recommend not using a database field that is intentionally hidden/abstracted by the API. If you provide more info on why you wanted to get the UserId, we might be able to help you find some alternatives.