I'm working with Azure B2C from a MVC (4.6) WebApp. I've followed this guide to make it work and it's all good:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-devquickstarts-web-dotnet
However, regarding the Edit Profile Policy, I need custom values coming from another system for a specific User profile property (i.e: Favorite Categories, coming from a custom Categories table). I don't want to add all the possible categories to the User profile property settings in the Azure portal, cos values can change frequently. So, couple of questions:
1- Is there a way to tell Azure AD B2C Edit profile policy, what are the values to use for a specific user profile property? (I don't think so)
2- Can I call the Edit Profile policy Endpoint to update the user profile? that way, I'd have a custom page with the user profile properties, and I will update the user from code. I've "fiddled" the MS page, and it's doing a post to a specific endpoint, but I'm not able to make it work from code. I've also tried a bunch of different things.
The only approach that seems will work is to call the Graph API from code, following this article (but it requires to register another App from PowerShell, and also, execute the action with an App Token, instead of the current logged user):
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-devquickstarts-graph-dotnet
Any help would be very appreciate it.
Thanks a lot.
1- Is there a way to tell Azure AD B2C Edit profile policy, what are the values to use for a specific user profile property? (I don't think so)
No. All the users use the policy you config on the portal. We can create multiple profile edit policy and choose the right policy based on you business with custom code.
2- Can I call the Edit Profile policy Endpoint to update the user profile? that way, I'd have a custom page with the user profile properties, and I will update the user from code. I've "fiddled" the MS page, and it's doing a post to a specific endpoint, but I'm not able to make it work from code. I've also tried a bunch of different things.
No. It is impossible. As you mentioned, if you want to update the users profile programatically, the Azure AD Graph is recommend.
you not able use JS, but you able customize with css;
(enable cors to ms login domain on your web app etc)
see msdm docs all are desribed;
you able add custom properties in AD B2C to user sign up; so to edit profile should be possible too;
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-ui-customization
Related
In my application I have the following scenario:
Users first register in the application Using SignUp-SignIn user flow, so at that point the user is created in Azure AD B2C. Then when the users starts to use the application I want to add some information to the user and retrieve it in the token during the next authorizations.
The information I want to add to the user is the following:
1- Identifier I use in my database to store data related to that created user
2- Some application role (e.g. customer, shop owner...) - here, it would be great if I can prevent users to make requests based on that role, but not a big deal to check it in the code after the request is executed
The idea I have is to use Graph API and assign this data in a custom attribute to the users, so this data is always managed by the API and user can't change it himself.
Then I am thinking if mixing that approach with groups could be also and option so some requests will be only available for users that belong to some group.
What is the best approach to achieve my requirements?
Out-of-the-box AAD B2C SignUp-SignIn user flow does not expose any functionality related to Security Groups.
If you want to use group claims in B2C, choose to add some custom code through custom (IEF) policies. See this answer and this post.
In order to achieve your requirements, you could use custom attribute which you have mentioned.
Please note that if you don't want the user to set the custom attribute by themselves, you don't need to do this 3rd step under "Use a custom attribute in your user flow":
Select User attributes and then select the custom attribute (for example, "ShoeSize"). Click Save.
After you create the custom attribute, you can Get the application properties and Using custom attribute with MS Graph API.
Update the custom attribute for a user with Microsoft Graph:
PATCH https://graph.microsoft.com/v1.0/users/userID
{"extension_831374b3bd5041bfaa54263ec9e050fc_ShoeSize": "123"}
Then you can get the custom attribute claim in token like this: "extension_ShoeSize": "123".
I want to use custom attributes in AAD B2C as a shortcut for authorization. I would love to set values on users that I can use in my apis to know what they have access to do.
I see that I can create a User flow for a user to edit their own attributes, but that is the opposite of what I want.
If I don't create a user flow to edit the attribute, can I be confident that the user can't edit it on their own through Microsoft Graph or something like that? I tried doing it through graph but I can't tell if I did something wrong or if the user is not allowed to change it.
It is better not to depend on User attributes for authorization. As user profile information (user attributes)can be managed by the user self or organization level.
I don't think users can adjust their own attributes if they don't have the graph permissions in Azure. When signing in your users within your application you can allow them to access certain scopes. As long as they cant access these scopes they cannot perform any actions on the graph API. Updating user details would in this case require 'User.ReadWrite' scope assigned.
Hoping someone can shed some light on the following matter;
I got an Angular & .Net core Web API application that uses Azure B2C to authenticate users.
User accounts are created by the users themselves via the signin/signup custom policy or administrator can create accounts via the app using the Graph API.
Due to the requirements, the app uses usernames (as opposed to email addresses) to log into the application. So far I've managed to get everything working except for the following scenario:
When an account is created via the Graph API, the owner of that account cannot reset the account's password. The error is "An account could not be found for the provided user ID".
This isn't the case for accounts that get created via the custom signup policy so I did some comparison and found that for those account that get created via the Graph API, the Email is missing (which can be found under User -> Authentication Methods). I looked at populating that field, but it appears the "Mail" attribute is 'read only' (not sure if that's the right attribute anyway).
At the moment I'm having to manually set the email via Azure so those account's passwords can be reset by their owner if necessary. This is obviously not ideal and wanted to see if there is anyone that might have gotten around this issue, or a least get confirmation that this is indeed a limitation of the Graph API.
Thanks in advance for your help
So I managed to get this working using the approach outlined by Jas Suri. These are the steps that I went through
Created a custom attribute in my B2C tenant to hold the account email address
Included the custom attribute claim type (extension_emailAddress) as well as the strongAuthenticationEmailAddress in the TrustFrameworkBase.xml
Updated my apps's custom policies to include the technical profile for local account discovery. I basically just copied the necessary bits and pieces from here
Updated the local account discovery to perform the comparison against the extenstion_emailAddres instead of strongAuthenticationEmailAddress.
Added an extra step to the Sign up user journey so that the value in strongAuthenticationEmailAddress is copied to extension_emailAddress
Updated my Web API / Graph API "create user" function so that it sets the extension_appidguid_emailAddress
That's it. Now it doesn't matter how the account gets created, the email address will be stored in the extension attribute and the password reset will be able to find the account using that attribute.
happy to provide more details if anyone comes across this.
The problem is as you’ve identified, the Sign Up policy uses the strongAuthEmail attribute to store the verified email for a username based account. The Password reset policy will use this to verify the user owns the username. When creating the user with graph api, you can’t populate this field, it’s not exposed. The only option is to use a custom policy which stores this secure email in an extension attribute, and your graph api created users can then also target the same attribute to allow the stars to align.
Mail attribute is not the same as the Email under Authentication Methods, and currently there is no such graph api to set the Email value under Authentication Methods.
By the way, there is no need to create Azure AD B2C user for a user as users can sign up themselves.
I'm new to azure active directory and I'm trying to implement a group based access mechanism in my mvc5 (C#) app. I have the Azure side sorted, my users are assigned to groups but I want to be able to determine which group they are in to control access to areas within the web app. (similar to roles based access)
so I need something like this
if (User.IsInGroup("Admin") || User.IsIngroup("Creator"))
{
//do something here
}
there are only 2 groups so I don't really need roles. I've looked at a few options using the graph api and they seem like massive overkill for what I'm trying to achieve. Whats the best way to implement this ? Do I need to implement the graph API ? Id appreciate any advice
You could enable Group Claims in Azure AD app, that will makes it simple to enable access management using AD groups. To enable your application to receive group claims :
1.In your application page, click on "Manifest" to open the inline manifest editor.
2.Edit the manifest by locating the "groupMembershipClaims" setting, and setting its value to "All" (or to "SecurityGroup" if you are not interested in Distribution Lists).
3.Save the manifest.
Then when user login , you will get the groups information in token ,but it will return the object id of group(that is unique identity, group name could be changed).Please click here and here for more details , also see the new groups claim sample published in the Azure AD samples github repo: https://github.com/AzureADSamples/WebApp-GroupClaims-DotNet
Please let me know if it helps .
I'm using an Azure B2C tenant to store users. At present I have to go through the graph API to retrieve the user details from my MVC application.
The annoying thing however is that the most of the details I'm interested in are already contained within the list of claims within the ClaimsPrincipal.Current object (in this case name, job title and email), so for the most part this call isn't actually needed. Department is the only one not included by default and is the only reason I'm making the call. In addition going through the graph API seems to slow things down enormously when running the site on Azure.
Is there any way of including the department in the claims list contained within the ClaimsPrincipal.Current object so I can skip the call to the graph API entirely?
If I understand your question, it sounds like you are asking how to include additional claims in the ID token returned by Azure AD B2C. The claims returned are configured on a per-policy basis.
Navigate to the B2C features blade on the Azure portal.
Click All policies.
Click your sign-up policy to open it. Click Edit at the top of the blade.
Click Application claims and select the attribute. (for example "Department") Click OK.
Click Sign-up attributes and make sure "Department" is one of the attributes collected from the user.
Click Save at the top of the blade.
Click "Run now" on the policy to verify the consumer experience. You can use "http://jwt.ms" as the redirect URI to inspect the token returned by Azure AD B2C. You should now see "Department" in the list of attributes collected during consumer sign-up, and see it in the token sent back to your application.