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.
Related
We use Azure AD user provisioning, to create and manage users in Salesforce. In itself this is working correctly. But... we have created a new (custom) profile in Salesforce (which Azure AD refers to as role) and this new profile is not being loaded into Azure AD. When creating a new user, we see our old custom profiles, but not the new one.
We started looking in the provisioning logs and saw a lot of "failed" entries. The first part of these logs reads like this:
The name, id, and claim properties of an app role in Azure AD must be
unique. We are unable to update an app role as one or more properties
are not unique. This is most commonly caused by having non-unique role
names in the directory from which roles are being imported.
And then a bunch of non-unique profiles/roles are listed. These are all standard profiles, such as Standard User and System Administrator. They appear twice in the list.
Going back to the screen where we add users, sure enough, these double entries are there as well. Each duplicate being an inactive choice. And: some old custom profiles are shown, also inactive. But not the new one.
This has worked before, as we see the old custom profiles listed. But somewhere/somehow double entries have been added and now we are stuck.
What is the solution? I have no idea on how to remove those duplicate entries from Azure AD. In Salesforce, there are no duplicate profiles. And even if I could remove the duplicate entries from Azure AD, maybe they would be added again on the first provisioning run.
I have an (external to Azure) application to integrate with AzureAD through OIDC. The requirement is to add a custom claim to id_token with a list of groups where the user is an owner in AD.
For example if the user is in the owner of group with id = "123abc", I need to add the following custom claim to id_token.
"ownedGroups": ["123abc"]
If this is not possible is there at least option to add sth like this
"hasOwnedGroups": true
I could not find any relevant example for this in docs. Can you share an example for doing this? If this is not possible in the exactly same way, I 'd like to know the alternative solution for putting information about ownership in id token.
Azure AD does not support Groups as source for custom claims or claims mappings. You can however create directory extensions, update them with any data you want and get them in the token as optional claims.
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 large AAD Dynamic group that I need to search and query membership for (100K+ member group) and search for users by name. This group is generated based on a custom attribute on the user in AAD.
I am trying to figure out if I can get this information out the MS Graph or if I need to move these calls to the AAD Graph ?
I've checked the users for extensions and schema data but there doesn't seem to be anything there.
Are custom attributes not replicated in MS Graph?
The problem I am trying to solve is:
I have a people picker that I want to return results that satisfy membership of a this group. The problem is MS Graph doesn't support OData queries of the members of a group on their displayName. Since the group is driving by the custom attribute I was hoping to take a short cut and include that in my query
You may need to get the custom attribute with AAD Graph instead of MS Graph, seems the MS Graph will not return the custom attribute.
Sample of AAD Graph:
GET https://graph.windows.net/{tenant}/users/{objectId}
returns:
{
"odata.metadata": "https://graph.windows.net/{tenant}/$metadata#directoryObjects/Microsoft.DirectoryServices.User/#Element",
"odata.type": "Microsoft.DirectoryServices.User",
"objectType": "User",
...
"extension_917ef9adff534c858b0a683b6e6ec0f3_CreatedTime": 1518602039
}
Here are two posts related to this issue, see : How to get/set custom Azure Active Directory B2C user attributes in ASP.NET MVC? and How to read Azure B2C Custom Attributes with Graph API (works OK with Azure AD Graph)
I am working with aspnetcore v2.1 (latest dev branches) in order to create a multi-tenant app where each tenant authenticates against their own Azure B2C AD tenant. This aproach was chosen so that email/password selections and social login associations are unique per-tenant.
Instead of a static ClientId applied in Startup.ConfigureServices, I want to apply the correct ClientId and Authority based on the current tenant identity (which I determine based on the hostname). Based on previous inspection of the 2.0-* code, I had been using an IOptionsSnapshot to allow me to apply the correct options as shown below.
In Startup.ConfigureServices:
services.AddSingleton<IOptionsSnapshot<OpenIdConnectOptions>, OpenIdConnectOptionsSnapshot>();
services.AddAuthentication().AddCookie().AddOpenIdConnect();
In Startup.Configure:
app.UseAuthentication();
With an implementation of :
public class OpenIdConnectOptionsSnapshot : IOptionsSnapshot<OpenIdConnectOptions>
However, now I find that my OpenIdConnectOptionsSnapshot is no longer being instantiated or referenced.
What is the correct way to apply a dynamic per-tenant ClientId, Authority, etc under AspNetCore Security 2.1.0-*?
(I am open to "you're doing it completely wrong" and suggestions of different ways to achieve multi-tenancy for tenants that have no pre-existing AzureAD footprint)
Try using IOptionsMonitor instead, we changed how IOptionsSnapshot worked fairly late in 2.0 and switched auth over to use the monitor instead.
OptionsSnapshot is now scoped