I have a custom registration B2C policy where a user is presented with a mobile multi-factor page. If they have not registered before their mobile number is verified and saved against the strongAuthenticationPhoneNumber property.
On subsequent logins they must use multi-factor authentication and the verified phone number value is read and populated into the phone number field on-screen with a mask hiding half the numbers. This field is not editable.
In the case where a user loses access to their number, is it possible to update this strongAuthenticationPhoneNumber value or remove it completely from a users account using Graph API? Currently attempting to make a PATCH request using this property results in a 400 response.
Graph API currently does not support this. The only way is for the admin to go to users panel in portal.azure.com and then remove or update the phone number.
Related
In Azure AD B2C, is it possible to have a password less sign in policy where user enters email and OTP is sent to associated mobile number?
Can we associate multiple phone numbers to a consumer account
without custom/extension attribute?
Regarding point 1, even if we manage to create it, should we use this policy. Is it a good practice?
Yes, you'd have to create it via custom policy.
Yes, via custom policy you'd have to create an additional endpoint. This endpoints points to a db with a list of phone numbers and returns true if it's in that list. As for best practice, it's dependent on the user requirements.
It's a bit tricky to develop custom policies.
Here's a good starting point: https://learn.microsoft.com/en-us/azure/active-directory-b2c/solution-articles
I am implementing MFA custom policy with Email or Phone option. I want to restrict user to login if phone number is not registered. In my current implementation it is showing a screen to input new number if it is not registered yet , I wanted to restrict user from adding new mobile if not found.
I tried playing with orchestration steps but not able to find the correct output claim to check if user is already registered or not?
You can’t really check per se, AAD B2C has a built in uniqueness checker if you write to the identifier field - signInNames. You can store the phone number in signInNames.phoneNumber and then your uniqueness check is handled by the policy itself when you try to write the value. That prevents any user enrolling a phone number that already exists on another account.
After users has done the sign up I want to set some information and receive it in the token when they sign in.
In order to do that I am using custom attributes and setting the value using GraphAPI.
The way I add the custom attributes is as described here:
In your Azure AD B2C tenant, select User flows.
Select your policy (for example, "B2C_1_SignupSignin") to open it.
Select User attributes and then select the custom attribute (for example, "ShoeSize"). Click Save.
Select Application claims and then select the custom attribute.
Click Save.
Those attributes should not be a concern of the user so I am not doing the step number 3 and here is where the problem comes.
I am able to set/get the value of the custom attribute using Graph API but the attribute is not present in the token. If I do the step number 3 then the custom attribute appears in the token.
Is there any workaround to achieve having the custom attributes in the token without having them in the sign up screen?
The link above also says:
The custom attribute is now available in the list of User attributes
and for use in your user flows. A custom attribute is only created the
first time it is used in any user flow, and not when you add it to the
list of User attributes.
Which I believe is the reason why I can't see the attribute in the token, but I though that after setting it with GraphAPI and being able to read it, it would be in the token.
It's not true.
Based on my test, if we don't do the step number 3 but do the step number 4, the custom attribute won't appear in sign up page but still can be included in the token.
Please make sure that you have updated the custom attribute for the signed-in user and use the same user to sign in with that user flow where you didn't do the step number 3 but did the step number 4.
Kindly check it.
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.
We have a problem where individual user are registered to our application but with permission to see a single set of data. These are all setup as local accounts.
At the moment each user is associated with a single set of data.
We now need to be able to link different sets of data to the same user.
After or during login the user would be presented with the options that are linked to their account and it would remember this throughout their session.
We would also need to be able to add new permissions to an account through an API.
What is the best way of achieving this through Azure B2C ideally without using custom policies if possible.
If you want to insert a page during the authentication journey (sign in) which reads the users access ability, and then allow the user to choose one of these options, and then issue that choice in the token, you will need a custom policy. I am assuming that this list could be different for each user ("options that are linked to their account").
If that list of options is stored on the user object, then it needs to be read from the user, and a dynamic radio box selection be presented to the user.
You need to create a comma delimited list and insert it into a claim, if its already stored as comma delimited, or some other delimited list, then you are already good to go. Otherwise youll need to have B2C send the data to a Rest api to build a comma delimited list.
That claim needs to be shown on the page after 'sign in' in a text box via B2C (hidden with CSS), where javascript on your custom HTML page (configured in B2C) builds a radio box from that list in the hidden text box.
Then the javascript needs to record the choice into another B2C rendered text box. You should then verify at B2C or via Rest api whether the submitted value was valid.
Then issue that value into the token.