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.
Related
I'm building a web app (SPA) that is a case management system. Each user (mainly external to organisation) has a case on the system. I've been told by an architect we should be able to use Azure AD B2C to allow the users to login on this so I've been investigating this.
From what I can see I will get a token back from B2C saying the user is authenticated. What I don't understand is what use is that? Ok the user is authenticated but I have no idea who they are i.e. I will need to identify their case ref somehow so I can bring back their details...
If i was doing this in the old days when they login they'd be checked against a user table then their ID would be used to get their case details .. a token and data object would be returned from an api.. job done
I don't see how this would work in Azure AD B2C... am i missing something?
The JWT that is returned contains a configurable set of claims.
You can use these to identify the user. Typically, this would be email or UPN.
In your case, you need a userID. If this isn't one of the supported attributes, you can use an extension attribute to store it.
B2C can also call an API (if you use custom policies) so you could call an API to get the userID from e.g. a table and then return it as an extension attribute in the JWT.
I have created Azure B2C Sign-In and Sing-Up policy as Built-In policy. Where i need to collect User First Name, Last Name and Country information.
Above built-in policy support below two identity provider login..
We need Country attribute information only when local User sign-up very first time. But as we have made Country as mandatory attribute, so it is coming for Azure AD user as well when they login very first time and we don't want to collect any country information for Azure AD users login.
How can we handle this scenario that within Single Built-In policy handle mandatory attribute differently.
Not able to get any thought though whether this will work using custom policy or not. Because User needs to login either sign-in/Up over login page by using above two Identity Providers.
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
I would like to store both, an email address and a phone number for MFA in Azure AD B2C and found the properties above. However, when writing one of the attributes, the other one seems to be getting purged. Unfortunately, I found very little information about MFA attributes in AAD. Any Idea on how to handle this?
These two attributes are protected attribute and inaccessible with Graph API, hence lack of public docs. With AAD B2C, you will write to these attributes within a User Flow when the user signs up with a Username (strongAuthenticationEmail), or enrols for MFA (strongAuthenticationPhoneNumber). But these cannot be read/write by Graph API by you.
If you use Custom Policies, you have full control over where you store the data, in the case where you need to feed in these attributes/prepopulate, or require an Admin pane to manage these attributes outside of the B2C Policy execution, simply use an extension attribute instead and configure the Custom Policy to R/W from the extension attribute, rather than the mentioned protected attributes.
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