Are in B2C Custom Policies a way to validate claims comparing them?
Lets say we need to validate the user postal code to reset a password, can we do:
insertedPostalCode == actualPostalCode ( compare two claims ).
Of course, this is after reading the user from B2C using a email, or some other signin name.
You can absolutely do this.
I'm going to assume you're using B2C custom policies.
Use a claims transformation, either the AssertStringClaimsAreEqual, or the CompareClaims, in a technical profile that can be added as a validation step in the self asserted page you are using to collect this postal code from the user.
Here are the Microsoft docs that should point you in the right direction.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/string-transformations#assertstringclaimsareequal
https://learn.microsoft.com/en-us/azure/active-directory-b2c/string-transformations#compareclaims
Related
I have a web application that uses Azure AD B2C, with custom policies, for security. When I look at the user accounts in the Azure AD B2C portal, I can see an editable Employee Id field. This field would be very handy to store an internal company employee Id, but I would like to include this field as an output claim in the auth token.
I've read the various documentation about the user profile attributes that are available through the portal, etc (https://learn.microsoft.com/en-us/azure/active-directory-b2c/user-profile-attributes), but EmployeeId is not listed there.
Based on the documentation, I'm assuming EmployeeId is not available to custom policies, but I thought I would ask the question, anyway, to see if anyone has worked out a way to include the property as an output claim in the JWT auth token?
• Yes, you can surely include the ‘employeeId’ attribute claim in the Azure AD B2C custom policy as below to be included as an output claim in the authentication token. For that purpose, you will have to define the employee Id as a claim with the proper ‘DisplayName, DataType, UserHelpText, UserInputType’ wherein you will have to modify the ‘TrustFrameworkExtensions.xml’ as below: -
Then, add the claim to the user interface in the local account signup technical profile as below since you want the ‘employeeId’ attribute to be included as a field in the output claim under ‘LocalAccountSignupwithLogonEmail’: -
Once done, then use the ‘PersistedClaims’ to write data to the user profile and ‘OutputClaims’ to read data from the user profile within the respective Active Directory technical profiles as above. Then, include a claim in the token in the ‘SignuporSignin.xml’ file and that output claim will be added in the token after a successful user journey and then modify the technical profile element within the relying party section to add the ‘employeeId’ as an output claim as below: -
Once the above things are done, then you surely can upload the custom policy and test it through your web app for the ‘employeeID’ attribute.
For more information regarding this, kindly refer to the below links for more information: -
https://learn.microsoft.com/en-us/azure/active-directory-b2c/configure-user-input?pivots=b2c-custom-policy
Custom policies Azure AD B2C issue with read the value Employee ID of user of Azure AD
To solve this, I ended up adding a REST API call, in the custom policy, that extracted EmployeeId via Graph API. Great suggestion by #juunas.
This works well, although it would be good if EmployeeId could be exposed as a claim without the REST call as I feel this adds a point of failure to the whole Sign Up/Sign In flow.
But it works.
Currently our team is struggling with propper architecture of Azure B2C solution for our multi tenant app.
Here is what we want to achieve. We want to enable users from certain Azure AD to authenticate. This is nicely described here with restricting tenants we want to enable.
We just want to enrich this solution with google authentication. We do not want to enable all users to be able to sign up. Is there a possibility to create google federated user programatically? We basically recieve list of emails from customer company and we create accounts in tenant). As far as I know there is no possiblity to achieve this using ms graph API when I don't have issuerUserId of user.
Do we have any possible solutions for this type of scenario? Like invitation email or so? Or maybe B2C is not a propper solution in this case.
Thanks in advance
A solution would be create the allowed users in b2c as a local account in graph api with accountEnabled as false and some generated password. Since the accountEnabled is false, user will not be able to sign in or reset the password as the default set of custom policies verify that attribute.
In the federated flow in custom policy,
Let the user complete federation.
Read the account using email address received.
If a local account exists, then link the federated account (Write alternateSecurityId to the account using objectId).
If a matching local account cannot be found, block the user by showing a selfAsserted page saying you are not allowed to sign up/in to this application.
You could also have some custom boolean extension attribute set to the local account to have an extra validation and update it's value once user completes the signup.
I'm struggling to find an example of this or how to do it, I'm sure that it's possible. Below the the scenario
User directed to to custom policy
User asked for email address
Policy then checks the email address against a database (via Azure Function). This function will return the provider to use. At the moment either https://login.microsoftonline.com/organizations or b2c
If the function returns https://login.microsoftonline.com/organizations then direct to Microsoft Sign in (passing email as hint so it's already filled in). This will then return back to the B2C signin flow
If B2C is returned then authentication is carried out by the B2C
Once user is authenticated via microsoftonline or B2C returned to app as normal
I know that external functions can be called from a custom signin policy. However, it's the user journey where it will send of to microsoftonline to sign in or carry on with the normal B2C flow that I'm struggling with. This artical is close https://learn.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-azure-ad-multi-tenant-custom?tabs=app-reg-ga, however, I want this choice to be made dynamically based on return value from an Azure Function.
Hopefully, someone will understand what I'm talking about
We call this home realm discovery, see this sample:
https://github.com/azure-ad-b2c/samples/tree/master/policies/default-home-realm-discovery
The sample uses a lookup inside the B2C policy itself, with a claims transformation. But you could swap that out for a REST APi instead if needed.
I have a requirement to take new User attributes for users already authenticated in Azure AD B2C. Is there any way i can force the user to provide the new attributes before logging in next time.
Assuming you are using custom policy, at the time of user sign-in, check if the desired user attribute value is not null. If it is, then you can ask them to provide the values for missing user attributes. You can also build more sophisticated logic but this should get you started.
I have a custom policy that allows a handful of users the ability to authenticate as themselves but then enter an email address of another user they need to impersonate (for help desk calls, etc). The users in the AAD B2C directory are of two types -- 1) local users (third party partners) and 2) federated users from our internal, corporate AAD. Impersonating the local users is working. The solution is based off of sample github.com/azure-ad-b2c/samples/tree/master/policies/
What is not working is impersonating federated users. What I'd like to do is read the user based on otherMails (which will be unique among active users)but when I attempt to upload a custom policy with a step to Read the user from the B2C directory by the otherMails claim I get a validation message '.Input Claim 'otherMails' is not supported in Azure Active Directory Provider technical profile 'SelfAsserted-TargetEmailExchangeFederated' of policy 'B2C_1A_Impersonation'.
'otherMails' is defined in the base policy so it seems it is just not supported to 'Read' on. I get this same error message if I try the mailNickname attribute. I can successfully upload and run the policy searching by other attributes such as employeeId, or immutableId however these have other limitations (size, uniqueness) that don't make them viable to store email addresses in.
Is there a way to read a user profile by otherMails?
If not, is there another field I could use? (I tried adding an extended attribute, policy would run but the account would not be found).
Short of either of those, is there a way to read the account from our corporate AAD by email from the custom policy? (calling the graph api, etc?)
If it helps anyone, what I ended up doing was creating a custom api that wrapped the graph api to look up identities based on entered email and then called out to the api from the impersonation policy.
similar to:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-custom-rest-api-netfw
for reference:
Find a User by Email Address