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.
Related
Is it possible to direct a user to a user flow along with a value that we want to set on a custom attribute? We dont want the user to be able to edit this field, it is ok if they see it.
I would like to have a custom app where the user will fill out some info, the app will validate their info against an internal database and return a value we would like to store in a custom attribute (an internal username).
I would then like to send the user off to a sign up user flow where they can either create a local account or create an account with an external IDP and the custom attribute would be pre populated for them and not editable.
To pre-populate the claim, set it as an input field on the form.
To make it non-editable, copy it to a readonly claim and display the readonly claim as an output.
To pass the data, make the whole flow a sign-up flow.
You can call a REST API in the flow to validate the data. Store the return value in an extension attribute.
Then ask the user if they want to federate with an external IDP.
If so, do the federation and add the value to the social account.
If not, create a local account and add the value.
You would have to create an external account beforehand.
I figured out you can send back custom errors from a rest API. What I am ending up doing is gathering the data from the user, sending it to a custom API for validation, then if it validates properly, the API returns the custom attribute.
If the validation fails I can return errors to the B2C that will be shown on the sign up page.
I am putting together a PoC to show Sign In followed by selection of a value from a dropdown box that is populated from an external API.
Standard Sign In is perfect and the example at https://github.com/azure-ad-b2c/samples/tree/master/policies/selectemail is great but I need to chain the 2, eg must successfully sign in first and then call the API to retrieve data for the user to select.
I know that this can be done with a 3rd part application between B2C and the end application but I am trying to avoid that. Can anyone point me to how I would go about doing this?
Concatenate the user journey steps in the sample with the user journey you have. And concatenate the technical profiles in that sample into the policy file you are currently using (eg TrustframeworkExtensions).
Now you will have sign in -> rest api call -> display dynamic drop down box page.
This is mostly playing around at the moment but I'm attempting to use Azure AD B2C as the login provider / user store for a website I'm working on.
I want to limit what users can access based on a user level.
At the moment, in order to handle this I have a database entry for UserLevel that stores the users OID, and an enum for the user level (admin, moderator, user etc) and then for page / api access I've set up a requirement that checks the authenticated user is in the UserLevel repository, and that their level matches, or exceeds the required level.
What I'm wondering is if there are any major problems with doing things this way / is there a better way to handle this.
You can use Custom Attributes to save all your User properties - it will act like DB columns in B2C.
How to create?
Navigate to the directory that contains your B2C tenant.
Choose All services in the top-left corner of the Azure portal, search for and select Azure AD B2C.
Select User attributes, and then select Add.
Provide a Name for the custom attribute (for example, UserLevel)
Choose a Data Type as String (Note that only String, Boolean, and Int are available).
Optionally, enter a Description for informational purposes.
Click Create.
The custom attribute is now available in the list of User attributes and for use in your user flows.
How to use in your User Flows?
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, UserLevel). Click Save.
Select Application claims and then select the custom attribute.
Click Save.
You should now see UserLevel in the list of attributes collected during the sign-up journey, and see it in the token sent back to your application - based on which you will be able to identify the access you want to give to that user (instead of making another DB call which will increase latency).
I setup a password reset flow using Azure B2C and local Azure accounts that uses the user's email address and verification code. However, my client would like to have a password reset email sent to the user based on the user name, not email address. The user email would be looked-up behind the scenes and an email sent that would include a link to the password reset page as shown in the flow below.
After reading a gazillion articles on custom Azure B2C policies, I'm struggling to convince myself if it is possible to do what the client is asking for using Azure B2C.
In the sample password reset flow shown below, some of the areas I'm struggling with include:
Is it possible to create custom pages in the password reset flow such as the page in Step 4 that displays the user's masked email address, or the information page in Step 7?
Is there built-in functionality to look-up a user's email address and Active Directory Object ID based on their user name or would I have to call out to a custom Azure Function and use the Graph API to do this?
Is it possible to create and send a custom email that includes a hyperlink to the password reset page that includes the user's Active Directory Object ID as a query string parameter so the password reset page knows which user's password is being reset?
At the moment, it seems like it would be easier to create a completely custom ASP.NET MVC app to handle the requirements than it would be to use Azure B2C custom policies, but that isn't really a path I want to go down.
Is it possible to create custom pages in the password reset flow?
Yes you can create your own custom password reset user flow using azure active
directory B2C
In your case if you want to figure out your custom page you could
refer here
Is there built-in functionality to look-up a user's email address and
Active Directory Object ID based on their user name or would I have
to call out to a custom Azure Function and use the Graph API to do
this?
Using Microsoft Graph REST API you could fetch your user
information.
In your case you could use
List users
Get a user
To access user information you could also refer here in a great
details
Is it possible to create and send a custom email that includes a
hyperlink to the password reset page that includes the user's Active
Directory Object ID as a query string parameter so the password reset
page knows which user's password is being reset?
You can use the company branding feature to customize the
content of verification emails for resetting password.
Note : For better clarity you could check the Azure AD B2C: Frequently asked
questions (FAQ) before final work around Which definitely guide you to
define ultimate go ahead.
Update
As per Microsoft document right now you cannot create according to your sample exactly. See the screen shot there is and important remarks.
Thank you.
This GitHub project covers the case you describe. Still needs a lot of understanding about custom flows to get it working.
https://github.com/yoelhor/aadb2c-verification-link
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.