I was wondering if anyone has some real-life information on Azure B2C performance in production with thousands of customers registered. We got a task to create a new system based on an old one which contains 100 000+ customer profiles. As such we would like to use B2C to store and query profile data.
How is the B2C performance for up to 100 000 profiles when it comes to:
JWT-token generation and validation
Using graph api to filter on built-in and extended fields (especially string filtering like startsWith)
If the filtering performance is poor for such many profiles, is there a way to increase it? Like a way to group profiles via some tag info or similar?
Have a look at Azure Active Directory B2C service limits and restrictions.
The following end-user related service limits apply to all authentication and authorization protocols supported by Azure AD B2C, including SAML, Open ID Connect, OAuth2, and ROPC.
Category
Limit
Number of requests per IP address per Azure AD B2C tenant
6,000/5min
Total number of requests per Azure AD B2C tenant
12,000/min
The number of requests can vary depending on the number of directory reads and writes that occur during the Azure AD B2C user journey. For example, a simple sign-in journey that reads from the directory consists of 1 request. If the sign-in journey must also update the directory, this operation is counted as an additional request.
EDIT:
Also, see this:
Azure AD B2C is a customer identity access management (CIAM) solution capable of supporting millions of users and billions of authentications per day. It takes care of the scaling and safety of the authentication platform, monitoring, and automatically handling threats like denial-of-service, password spray, or brute force attacks.
This quote, taken from What is Azure Active Directory B2C?, shows us two things:
Performance shouldn't be an issue
AAD B2C is an identity solution, not a user profile solution
i don't have a bench, but for sure you should check the service limits here: https://learn.microsoft.com/en-us/azure/active-directory-b2c/service-limits.
Those for sure would impact the "JWT Generation" since this happens inside a user journey and every interaction with the underlying tenant counts as a request. The "JWT Generation" performance could also vary depending on your user journey complexity: if you are using the Identity Experience Framework to create a custom User Journey, every Orchestration Step will take time to execute so your users will wait for the journey to complete prior to getting a token. So more Orchestration Steps equals more waiting time, especially if you use Restful Technical Profiles which involve third-party services.
I don't get the "JWT Validation" part: AAD B2C doesn't validate your JWTs, it just issues them. Your application or API should validate them.
About the Graph API queries, the performance are usually good. You're using the underlying AAD tenant which is an enterprise-grade service so such queries are pretty common. Doublecheck if the fields you want to filter on support the function you want to use since not all fields support all the functions. Also keep in mind that even the Microsoft Graph API has limits: https://learn.microsoft.com/en-us/graph/throttling and you should keep them in mind.
If you plan to use your AAD B2C tenant as a database and continuously query it for extracting info, probably you're using it wrong.
Regards, F.
Related
After investigating what Azure AD B2C can do, I'm not sure if it can do everything we need it to do through custom policies / we would have to make some compromises. I was thinking of still using it purely for authentication actions against our users: sign in or sign up - local & social media accounts, reset password etc.
However, we also want to collect more details about the user that they either provide at sign up or at a later date, and I'm finding the ability to edit profiles quite lacking.
Therefore I was thinking instead to create a bespoke dot net core or framework application which will act as a 'preference centre' that the user goes through. We will have much greater customisation o this, as we will not be limited to what Microsoft allow through custom policies. The user would either be passed through this application after signing in and before reaching one of our applications, or they can get to it from a link on our applications. All the data that is stored for the user will still be held in the Users section in our Azure AD B2C. Then the application will use the Graph API to query and update the data for the user.
Is this a sensible approach? Or can you recommend something else?
We have a simple scenario but technologies(or implementation) have made things bit complex -
We have Sitecore as CMS for client's main web site and for business functionality we have Dynamics 365 Portal and we are using Azure AD B2C as identity provider for both.
We have heavily customised B2C custom policy to cater specific requirements.
We are using same custom policy in Sitecore and in Dynamics 365 Portals so sign in individually and works perfect without any issues.
With regards to SSO, we have kept the configuration as OOTB as you can find it here.
Only 1 or 2 user journeys are absolutely perfect as good as seamless journeys. In specific journeys we need user to be logged in both ends to make it work (we can force user to go to sign in page, but it is not required on all the pages).
In order to understand how real and proper SSO should work in Azure AD B2C, I have no idea or experience to relate this process to. so I am looking for guidance and help here.
I found very good information in this about how B2C works in terms of signin and providing tokens process but it bit old question and things have changed a lot since then specifically UI and some of the operations.
Use the following docs when configuring sessions management for a custom policy. Session Behavior section is where you define which SSO behavior. Specifically:
<SingleSignOn Scope="Application" />
If you want your users to get SSO between all applications, then define this value as "Tenant". There are several useful scenarios in creating separation between sessions - such as a company that has multiple brands that do not want to conflict each other. Or a separation of experiences.
Follow the exact format and location to be placed in your policy or you will not get the desired result.
Another concept that is important is the understanding the session provider:
SSO session management has two parts. The first deals with the user's interactions directly with Azure AD B2C and the other deals with the user's interactions with external parties such as Facebook. Azure AD B2C does not override or bypass SSO sessions that might be held by external parties. Rather the route through Azure AD B2C to get to the external party is “remembered”, avoiding the need to reprompt the user to select their social or enterprise identity provider. The ultimate SSO decision remains with the external party.
Session providers are used to define maintain what goes into generating the session when your policy is being executed (inside the Identity Experience Framework). If marked incorrectly, this could lead to undesirable results such as wrong claims being sent, additional MFA prompts, parts of your policy not being maintained when ran or just general errors.
This is for those who are interested in how we achieved this -
Sitecore also does offer OOTB Azure AD B2C configuration however the supplier of Sitecore delivery side decided not to use OOTB configuration approach and hence it caused lot of issues. From what I have read about Sitecore configuration for Azure AD B2C it does work smoothly with B2C with careful configuration.
Work Around: We had to rely on external triggers(e.g. cookie) which will indicate and trigger that a user has signed on either sides and accordingly the sign in process on both side kicks off.
I don't understand how the 'Scopes' in Azure B2C are supposed to be used. They are associated with an API, but not a user. I'm sure I'm missing something, but I see no practical use for something associated with an API. I've used and implemented Claims-based authentication based on a user's role in the database.
For example: ordinary users of an API should not have the authority to delete an object, but administrators should have the authority. Does someone have a practical example of how these B2C 'Scopes' can be used to limit a users access to the API?
They are associated with an API, but not a user.
That is correct. I like to think of the association to the API as defining the 'surface area' of the API. For example, this API defines 2 scopes
read
write
Now, you could define two applications. One application that only has read permissions and one that has read and write permissions.
For the common use case of one Web App and one Web API it adds no value. I've been using a scope of no-op for such cases.
I've used and implemented Claims-based authentication based on a user's role in the database
You can use custom attributes to assign "role(s)" to the user. You can set them via the Azure AD Graph API to keep the setting of them secure. You can also set them during sign-up (this is much more involved though).
When you request an access token for that user, the custom attirbute(s) you defined and set will be readable in the API to check permission(s).
Comment Feedback
If I promote or demote a user, I need to change the endpoints (policies) they access at the client.
No need to change the policies. You would update the custom attribute for that user via the Azure AD Graph API.
My problem is that I'm mystified at the an authentication system that authorizes endpoints ("scopes") instead of users
Yeah, me too! I think it might have to do w/ the purpose of the product. B2C is about self-service sign-up, password reset and federating w/ other IDPs (like FB, Google, etc). Maybe Azure AD is a better solution when you want to control permissions on a user. Not sure, still learning!
I still don't see the practicality of splitting your API into several different parts based on the security. An API should be a collection of functionally related services
You don't split your API. You can split your app(s) that utilize the API. See above.
Documentation Reference: Requesting access tokens, GitHub Issue to improve the documentation.
Roles and scopes provide the two halves for this user access control.
Roles -- such as Administrator, Member, and Guest -- determine whether an authenticated user is permitted to delete objects.
Scopes -- such as read, write, and delete -- determine whether an authorized application can delete objects on behalf of an authorizing/consenting user if this user, through their role assignment/s, is permitted to do so.
Azure AD B2C doesn't have any current support for managing roles and assignments of them to users.
It does, however, have support for managing scopes and assignments of them to applications.
Dear Microsoft Azure AD personnel, (and anyone else who has been down this road)
We are building a User Interface as a front-end to our back-end architecture in Azure, mainly comprised of Azure SQL databases, VM clusters, Azure Search indexes, and SFC's.
Users who will login to this UI will be both internal (company employees) and external (our clients). The internal users will log in to perform various functions for services we provide our clients. Our clients will log in to perform search queries on certain tables of our databases.
Where we are lost is in the area of trying to plan and execute our identity management architecture along the lines of permissions and policies.
For our internal users, we will have several different permissions profiles that need to be defined - for example, User 1 should be able to access and write information about client 1, but not client 2. User 2 should be able to access and write information about client 2 and client 3, but not client 1. That is just a simple example.
For our clients, thus far, we have set a up a B2C tenant to allow them to sign-up for access with their email address. While this part is simple and straight-forward, it seems the B2C functionality is rather limited in that there are only policies for signup/sign-in, password reset, and profile editing. We will eventually need to offer different levels of access permissions to our clients as well.
Here are my questions:
For our internal users, should we be using our domain Azure AD (B2E), or should we also use B2C for them so all users are under the B2C architecture?
Are these different kinds of permissions I've mentioned defined and set inside Active Directory settings, or coded into the Application?
Should we use B2C at all, given that we will need to give different permissions structures to different users within our clients? Should we be using B2E for our clients as well, even though they are customers and not internal users on our domain?
I've been reading Azure documentation and watching videos since end of last week and I'm still having trouble determining what's right for us for what we're trying to accomplish.
I am by no means an expert in Azure AD (either the most generic enterprise/domain, B2C, or B2B), but based on my reading and experiments:
1) You can funnel all users through AAD B2C, using AAD B2C custom policies to allow enterprise/domain AAD users to be connected to your AAD B2C directory; this means your application(s) only have to integrate with a single directory (AAD B2C);
2) None of the AAD flavors is really designed to do fine-grained permissions/authorization; you will probably need to handle this in your own code, or using some other feature/service.
Martin
We are looking into Azure AD B2C as a general identity management solution for our SaaS services.
One scenario we need to support is around distribution of pre-paid (stored value) payment cards, sold in stores or offered by other 3rd parties to customers. The customer gets the card with a PIN or one time registration code, and with that they can sign up to the cardholder portal, a web application / native app that allows them to view card history, balances and so on.
The sign up process needs to eventually identify the card as a custom claim, but also needs to validate the supplied code right there and then. The user needs to be able to go to the cardholder portal, click 'sign up' and be presented with input fields for the basic info plus the PIN/ reg code. On submit, the PIN/reg code needs to be validated.
Can Azure AD B2C support this type of scenario? Can the UI be completely custom? Are there any pricing implications to this? Also....is there anyway of having the native version of the app have a completely native version of the UI?
I believe you can configure this type of validation for new users signing up using Azure AD B2C Custom Policies. Custom policies allow you to define your own policy rather than using the built-in set. Specifically for your case, you'll be able to validate user data given at sign up with your own API.
Fair warning, custom policies can be complex to configure properly.