Our solution require a custom user attribute to be available for Graph API post/get operations and to be exposed with claims in the JWT for user user-in.
I have configured a custom policy with for Local Account.
The template files were downloaded from and the only changes made is to add a new custom user attribute that is available for Azure AD read/write, persistent storage, claims output.
I added the policy files to a public repo here:
https://github.com/frode/azure-ad-b2c/tree/master/LocalAccountSignIn
The extension_tenantId attribute becomes available for Graph API operations, setting value and retrieving it works fine, however the attribute is never exposed in the JWTs claims section as we intended.
Can User flows and custom polices be used together or is that the problem that we have defined a user flow with the same name as the custom policy?
/Frode
Was able to spot the issue in our configuration today.
src/Policies/LocalAccount/TrustFrameworkExtensions.xml was missing the IdentityExperienceFramework app registration & GUID value.
Regards
Frode
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.
For multiple applications. we are using AAD B2C for our authentication system.
We have opted for custom policies. One of the reasons for this is that we want to allow different user groups to access different applications, in the following way:
superusers can access all Applications, including our CMS
product admins can access the customer facing CMS and the end product
product users can access the end product
For this, we have the policies:
B2C_1A_xxx_cms
B2C_1a_xxx_product
B2C_1A_xxx_customercms
In all policies, we do an API call to an internal authentication API, which validates the user's group memberships throught MS Graph API.
The problem is that these policies seem to be able to be used interchangibly:
https://{tenant}.b2clogin.com/{tenant}/b2c_1a_xxx_cms/oauth2/v2.0/authorize?response_type=id_token&scope={scope}%20openid%20profile&client_id={client_id}&redirect_uri={redirect_uri}&nonce={nonce}&client_info=1&x-client-SKU=MSAL.JS&x-client-Ver=1.4.4&client-request-id={client-request-id}&response_mode=fragment
In the above url, users can access the CMS by replacing b2c_1a_xxx_cms with b2c_1a_xxx_product, thus bypassing the group-based validation in place for the specific application.
The original implementation of our policies are based on this tutorial:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-get-started
How can we configure these policies in such a way that changing the URL and trying to log in is impossible?
Based on your requirement, I think you need a the application assignment to users feature.
But it is only available in Azure AD rather than Azure B2C.
So I suggest that you use custom attribute to control the access of the user for different applications.
“ we do an API call to an internal authentication API, which validates the user's group memberships throught MS Graph API. ”
When User A calls Policy B, this API should return back a claim into the journey that prevents it from issuing a JWT. That can be achieved by creating a “block page” using a self asserted technical profile. Call this from the orchestration step using this claim from the API to trigger it with a precondition.
I'm evaluating Azure B2C but can't work out whether it will be fit for the following scenario:
We have a single UI and and a single Web API. The API has two scopes defined: read and write.
The UI has two types of users: standard and admin. When a user logs in and gets an access token they both get a read scope but only an admin user should get write.
From what I've read Azure B2C doesn't support group based application, but is it possible to hook in to the token generation (e.g. a Function) and add a custom scope programmatically? I was thinking that if I can call a Function then this could check something to see if they should have the write scope added.
Thanks
Scope o scp claims cannot be manipulated in B2C. However you can use custom policies and add (in a base policy) and output (in your relying party policy) a roles claim type so what your webapi do role base authorization (.NET core sample here). You can fill the roles values from the output claims provided by any technical profile which in turn relay on any configured Idp, AAD or even REST apis).
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.
What are ways to include custom claims (user subscriptions or roles list as example) in a token before issuing it in Azure AD B2C, provided that claims are stored somewhere on own server (not available in B2C)?
Goal to have claims in the token to avoid additional round trip to the storage on every request.
Investigation on the topic brought me to following ways:
Add custom attribute via Graph API, configure to include in JWT. Attribute values should be kept in sync with our datastorage.
Custom Sign-In Policy like in this article https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-rest-api-step-custom but if I got it right, additional Step 6 is a user journey to publicly available API in non restricted way (request not secured by secret, might be used to get user claims by presented UserId)?
IdentityServer4 Federation gateway http://docs.identityserver.io/en/release/topics/federation_gateway.html that will allow to add any claims before issuing.
The first two mechanisms you outlined are the most common and recommended ways to include custom claims in an Azure AD B2C issued token:
Add a custom attribute and include it in the JWT. You can enable the custom attribute via the B2C UI or via the Graph API. You'd need to build your own mechanism to keep the value of this attribute in B2C in sync with your external source via the Graph API.
You can use a custom policy to add a step in your authentication flow to call a Rest API to obtain the claim and include it in the token. This call to the Rest API will be performed by the Azure AD B2C service and NOT the user's browser, so it'll be a service-to-service call (versus a client-to-service call), keeping any secrets you use for authentication with your Rest API safe (such as a Azure function code).