Is there any way to add a custom role attribute (that the user cannot edit) to a B2C custom policy?
I have found this and this resource that show how to add a custom attribute, but it seems they add attributes that the user can edit. I wish to have a custom role or admin attribute that only administrators of my app in Azure can edit inside the Azure B2C interface. I also want the attribute included in the jwt access token that is brought down when users log in.
I am specifically looking to define application roles which can be assigned and edited through the B2C interface and not classic Azure AD. I am under the impression that this can be done through custom policies though I may be mistaken.
It depends a lot on how you plan to assign role to user in your system.
This answer summarizes three approaches you can potentially take. If you can enhance your question with what kind of roles are you looking for and how do you plan to assign them, you can get better responses.
Related
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.
we currently work on site that uses Azure B2C authentication for "normal" public users. The site has an admin backend that need "admin" users login. How do you do that? In azure B2C we can't have groups to identify which is an Admin. Can I use custom attributes like Admin-Boolean and set it to true in the Azure users portal? It is secure enough?
Unfortunately there is no easy solution here IMO.
Yes, you can use custom attributes to solve this problem.
You can set those custom attribute(s) via the Azure AD Graph API.
Then in your app you have to check those custom attribute(s).
The first problem with that solution is there has to be an account created to set those claims on. Depending upon your app this could be an inconvenience or pain point.
You can also set those attribute(s) on sign-up but that requires custom policies which is a whole nother animal IMO
I have 1 SPA-Application which uses another WebApi. (ASP.NET Core) Both are running in Azure and I am able to authenticate the user against Azure AD B2C with OAuth 2.0 Implicit Flow
Now I am asking myself how I can control the permissions of a single user. (Delete, Read, etc.) Do I have to work with claims? Do I have to leverage the graph API on the server side to check if a user has a certain permission? Can I use scopes? Where can I set the User <--> Scope relationship?
I have found several questions on SO, but I don't get the idea of how it should be done the right way? My current understanding is that I ask the authentication provider for certain scopes and I will get a token with this scopes which then can be checked by the API. But how do I manage which user can ask for which scopes?
I really have a problem to wrap my head around OAuth2 and permissions. Hope one can help me here.
Unfortunately, for one specific user, you cannot assign permissions/scopes to the user.
Because Azure AD B2C doesn't support Application Role. Generally, Azure AD B2C is for all users to access your App wit their account. Even Azure AD B2C can let you store and manage users, but it cannot assign different scopes/permissions to different users. Multiple scopes are the permissions granted to the resource. Multiple granted permissions will be separated by space.It's not for users access assignment.
If this important to you, you can upvote this idea in this Uservoice Page. Azure Team will review it.
Hope this helps!
You can implement this by creating a custom attribute of type String that stores a comma- or space-separated list of roles for a user.
You can then issue this custom attribute in the ID and access tokens or read it using the Azure AD Graph API.
This is basically a follow up to my prev question - https://stackoverflow.com/a/44738654/2896495. I've implemented an Azure B2C sign up and auth in my web app (.NET Core 2.0) and now I want to add a custom sign up logic with Graph API (as described here - https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-devquickstarts-graph-dotnet).
But I'm confused about app registrations. For B2C auth I created an app in the Portal under Azure AD B2C -> Applications. Now, in order to use custom sign up logic I need another app registration under Portal -> App Registrations -> New Application Registration (where I can grant necessary permissions to Azure AD, like Read and Write directory data).
So, if I need auth AND custom sigh up, how should I set up my app? What's the right way of doing this?
For simplicity's sake, as well as a healthy separation of concerns, I would indeed make a separate app for the custom sign-up. It doesn't have to be a full-fledged app, a microservice that does the sign-ups for the main B2C app would be fine.
If you want to use the custom attribute to implement the custom sign up process, you need to register two apps as the document you mentioned in the post. One app is for integrating with Azure AD B2C for login, and the other is using the Azure AD Graph to query the custom attribute.
After that, you can using the Azure AD Graph REST to query the relative info and handle your own business logic in the web app. And to query the extension info, we just need to query the user info like below:
If you are just trying to have your own look and feel, as opposed to the default templates with your logos and other branding, then look into providing a template for UI customizations:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-ui-customization
Also, see this other answer to a similar question:
Azure AD B2C UI Customization
If you are trying for a whole different workflow, the you will want to create a custom policy.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-overview-custom
Or if that does not work, then I guess you could just use the GraphApi, but that is the most laborious of options and completely destroys the entire purpose of using B2C in the first place. I do not recommend this approach.
Update:
I would not do everything you want to do in a custom policy. Separating the signup into it's own application/service would be a great approach (as #camsoper suggested), but only use the policies for the bare amount needed to create the initial account or authenticate an approved user. I've never used a policy to change the "accountActive" attribute, but I would be inclined to use the GraphApi to modify the user profile after the account is created by using the "NewAccount" attribute to key off. There is a "Block sign in" setting on a users profile in the azure portal which can be used to restrict access (and the signup application could set the default after the account is created), but I'm not sure if that corresponds to the "accountActive" attribute or not (yet).
Most of the administration you've described can be done in the azure portal, such as changing the "Block sign in" setting on a users profile can be used to restrict access (and the signup application could set the default after the account is created). If there is some capability that the portal does not offer, I would put that into a separate application. Avoid duplicating functionality in your customized admin app, and instead just redirect the admin to the users profile in "portal.azure.com".
https://portal.azure.com/#blade/Microsoft_AAD_IAM/UserDetailsMenuBlade/Profile/userId/{objectId}
Note: there may be some issues with that URL template if the admin has access to more than one Directory for her account. It will try to pull up the directory that her account was created on by default.