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?
Related
I'm wondering a few things about azure ad.
I currently have a little software with self users managed, in database, with custom properties, and access token self generation, etc.
In order to develop micro services, azure functions, and handle SSO the right way, i would like to migrate my users management to azure active directory, but i'm a bit lost with its features.
Is there a way to handle custom properties for users in azure ad ?
Users can be affected to one or many 'agencies', with some 'roles' in this affectation, such as 'agency supervisor', 'agency user' etc, which aad feature is the best designed for this ? Groups ? Roles ?
Is it a best practice to store custom business-related user properties in an associated database instead of aad ? (Maybe in order to migrate user management later ?)
I'm sorry for these questions but after a lot a research i'm still there.
Maybe some of you have great feedback or documentation for me.
Thank you !
There are two products, Azure Active Directory (AAD) and Azure B2C Active Directory. The first one is used within organizations, the latter can be used for multi-tenant situations where you let people from 'outside' your domain register with their own identity provider (other AAD, Oauth, etc).
Simply said, the AAD is for within the organization, Azure B2C AD is for external users.
The B2C AD features are a layer on top of the 'regular' AAD, so every feature in the AAD is available in B2C AAD as well.
Azure B2C was made with extensibility in mind, and you can (programmatically) add extra schema attributes to the users in your B2C Organization (such as companyId or other identifiers you use to differentiate in your product). We use a mixture of security groups for setting user 'roles', and we use custom claims with the extra schema attributes so I know what client a user belongs to (I'm working on a multi-tenant SaaS app).
If you are going to store a lot of information about the user that is LOB-application data, use a separate database to store that, as the (B2C) AAD is not a very good place to store large amount of (nested) data.
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'm new to Azure ADB2C, and am confused by some of the terminology.
I am building a motorcycle ride monitoring website that I would like users to be able to log in to by verifying a social media identity (Google & Microsoft Account, for now).
But I only want users who are members of the site to be able to use certain features. For example, I'd like everyone who authenticates to be able to apply for membership, read about the benefits of membership, etc., but I only want members to be able to initiate ride monitoring.
Is the recommended approach here to only authorize (rather than authenticate, if I'm understanding the terminology correctly) certain authenticated users (i.e., members) to use the ride monitoring services?
If so, what's the best way to authorize a member? Look up their email (which I require to be returned from the authentication process) in a standalone database and proceed accordingly? If I go that way, what's the simplest way of adding their membership status to their credential, so I can access it throughout the site?
Apologies for not providing code here. I've got a bit of it hanging around :) but this is more of a design question than a coding one.
Azure AD B2C is primarily Authentication as a Service. There are ways in which it can be used for what you are trying to achieve here.
You can use custom (extension) attributes in AADB2C (https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-custom-attr) in combination with AAD Graph apis (https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-devquickstarts-graph-dotnet). So when user authenticates and applies for membership, you can call AAD graph api to set the custom attribute on user object. You can get the extension attribute in a the token after the authentication happens. This token will give you membership of the user.
You can also use AAD Groups instead of custom attributes. In the tenant, create membership groups. Once user authenticates, call AADGraph to set/get user's membership of a group and that will give the authorization information.
You can also do what you described, maintaining the info in a database store of your application. But the first two functionalities provide in-built functionalities for user management.
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.