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).
Related
We have 3 people that need access to our Azure B2C portal pages. How granular are the permissions on the Profile page and All Users page?
We want to restrict the visibility of a User's first name and last name to a single administrator.
Can the User "Profile" page be restricted whilst the "All Users" page is still available to the whole admin team?
Is it possible to set visibility controls on specific fields? That would allow us to have the Profile page available but the fname and lname as hidden fields.
You cannot control the visibility of the fields in the Azure Portal in this way. Yuo can only control which fields can be modified based on the Azure AD Admin role of the user.
The only option to provide more granular access would be to surface your own Admin tool built on top of the MS Graph API.
Or there maybe a solution which a partner offers.
In my application I have the following scenario:
Users first register in the application Using SignUp-SignIn user flow, so at that point the user is created in Azure AD B2C. Then when the users starts to use the application I want to add some information to the user and retrieve it in the token during the next authorizations.
The information I want to add to the user is the following:
1- Identifier I use in my database to store data related to that created user
2- Some application role (e.g. customer, shop owner...) - here, it would be great if I can prevent users to make requests based on that role, but not a big deal to check it in the code after the request is executed
The idea I have is to use Graph API and assign this data in a custom attribute to the users, so this data is always managed by the API and user can't change it himself.
Then I am thinking if mixing that approach with groups could be also and option so some requests will be only available for users that belong to some group.
What is the best approach to achieve my requirements?
Out-of-the-box AAD B2C SignUp-SignIn user flow does not expose any functionality related to Security Groups.
If you want to use group claims in B2C, choose to add some custom code through custom (IEF) policies. See this answer and this post.
In order to achieve your requirements, you could use custom attribute which you have mentioned.
Please note that if you don't want the user to set the custom attribute by themselves, you don't need to do this 3rd step under "Use a custom attribute in your user flow":
Select User attributes and then select the custom attribute (for example, "ShoeSize"). Click Save.
After you create the custom attribute, you can Get the application properties and Using custom attribute with MS Graph API.
Update the custom attribute for a user with Microsoft Graph:
PATCH https://graph.microsoft.com/v1.0/users/userID
{"extension_831374b3bd5041bfaa54263ec9e050fc_ShoeSize": "123"}
Then you can get the custom attribute claim in token like this: "extension_ShoeSize": "123".
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.
I have created a set of new User Attributes and used them in my new User flow (Policy) in Azure AD B2C.
These attributes are of data type "Boolean" but when I run the user flow I get a textbox input instead of a checkbox.
Usually, I get the possibility to change it on the portal but now I can not find where to do so now.
Have anything changed?
Once the custom user attribute is added, go to page layout. In my case the attribute to add is on the local account registration page, you select where you have added it or want to add it.
Below you will have appeared the user attributes that that part of the flow has (yours should appear). From there you change the type of ticket, you can also change if it is optional or mandatory ...
Go to Azure AD B2C > User flows (policies) > Your user flow > Page layouts.
The User attributes section of the Page layouts page allows you to change the user input type.
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.