I currenly have an application that is used by multiple organisations(my customers) of which their employees can login to the application.
These organisations can have their own customers. Currenly these customers cannot login or do anything. I want to make it possible for these customers to login and view specific data about themselves. I thought Azure AD B2C would be a good solution for this, but I’m starting to have some doubt about that.
Because these organisations(my customers) all operate in the same field it is possible for their customers to also be a customer of an other organisatie. Users can only exist once in the B2C directory, so how to differentiate between these organisations. Is it possible to use Azure AD B2C for this situation(and would it be a good solution) and if possible how can I implement this?
It would not be very difficult to search the other directories and check if the user exists but what would it really achieve?
The user could just sign up with a different email address in the second B2C environment unless you restrict the email addresses that can be used to self signup.
As for how to implement this there is plenty of documentation how to do this or if you have specific problems with your implementation code please feel free to ask new questions for them.
Is it possible to federate B2C with these organisations?
If so, each federation will be different since the login address will be different e.g. joe#company1.com vs joe at company2.com.
These users won't be local; they effectively use shadow accounts and so a user can be in B2C multiple times.
Related
I’m currently working on a POC to use Azure AD B2C in a multi-tenant architecture where we have a single database of users tied to companies. Presently we have around 1000 different companies. The question I couldn’t determine from documentation and Azure support is whether I can do the following:
Allow company admins to choose the sign in providers they want for their users.
Provide per company branding to the user flows.
Of course, my main consideration is doing this in a configurable and scalable way. Right now we only have a single B2C tenant setup and unclear if we need one per company vs managing it all together well.
Finally, is this even the right product for these outcomes?
I am new to powerapps, and I need to create an app with AzureAD authentication. But I am confused by this authentication. Do I understand correctly that I don't have to implement user sign-up and login screens, because every user which will be added to AzureAD would be able to login to microsoft account and will have an access to my powerapp?
So, I don't have to write any code for user signup/login/forgot password?
But in the Internet I saw that some people use AzureAD.getUser() and Office365.User. When do I need it?
PowerApps is building enterprise apps for your organization staffs. This app has to be developed, published and shared to AD users, and users can sign-in using Active directory single sign-on.
You can invite/share with AD individuals, security group or O365 group. But not Distribution groups. You can share the app to all users by sharing with “Everyone”.
Even PowerApps can be shared with external users (guests) but they must be guest users of an Azure Active Directory tenant.
How to share a PowerApp?
Yes, no signup or login other than Microsoft AD login/challenge screen.
Those snippets will be used to get current logged in user details.
Everything #ArunVinoth said and to add a little more info about:
But in the Internet I saw that some people use AzureAD.getUser() and Office365.User. When do I need it?:
These are PowerApps connectors (API wrappers) that allow you to surface AD/O365 data within the app for your users.
Example:
You may have a way for users to lookup contact information for people within the org.
You would add the Office365Users connector to your application
Then execute the .SearchUser method from that connector to display contact info based on user input.
These connectors are not for authenticating to the app, but rather providing lookup capabilities for your users. Or automating these lookups for your app logic.
My goal is to have the user authenticate with Azure AD and then be presented with a drop-down of profiles they want to access. Based on which profile is selected, the user will have different permissions on the site. I'm trying to avoid a user having to have multiple logins to enforce the different permissions per profile.
Can Azure AD handle this or do I need to tie in custom code in a database?
No, Users have one identity and can have a set of roles on an app.
Well, just one role unless you have group-based role assignment available :)
This concept sounds like something you will have to build in your app.
Or you will have to have multiple users registered for this one person.
We are building a enterprise product, and expect a lot of customers, to not have active directory of their own.
We plan to use AAD as our IAM provider.
We plan to create a master AAD for the product, and then invite users of each customer (tenant) as external users to the master AAD, using their business email id. Each set of users for a given customer, will be added to an external group for manageability.
Would this be the right approach, for supporting multi-tenanted IAM for a product hosted in Azure?
It's a pretty hard question. AAD's multi-tenancy basically requires the org to have an AAD to have proper separation etc.
But in the case of an org not having an AAD, this is one option.
One crucial thing you must not forget with this path is to turn on the option in the AAD tenant to restrict Guest user permissions. This makes it so that the invited users can't just go to portal.azure.com and get a full list of all users in the tenant. At least usually this is a desired thing when multiple clients are in the same tenant.
Other options could be:
Setting up an AAD tenant for each customer
Good separation for customers
There might be a limit how many you can create
I'm not aware of an API you could use for this (but hey Selenium works :D)
Set up your own identity provider with e.g. IdentityServer
Maximum customizability
Lot of work for you to develop and maintain
Everything would of course be easier if they just had an AAD :)
It would depend on some details of the approach you want to follow. If you are expecting for them to use their business email, then you may consider having Single Sign-On (many organizations expect not needing to duplicate accounts and you may want to delegate your customers the hassle of resetting passwords).
Also, you need to determine what kind of isolation need(do you want to have a single set of users or have a clear separation by tenant?) and the budget (AAD cost is measured on a per-user basis) you have for this? Azure AD B2C could be also an option, or as #juunas mentioned, implementing your own solution with something like IdentityServer.
From web search it appears that to be able to manage Windows Azure services, you need an account with one of the admin roles (service administrator, co-administrator etc).
From project management point-of-view, what is a good strategy to manage accounts for your company if you have several developers working on Azure?
Examples
A simple strategy could be to have a few designated administrators (e.g. team leaders) who upload the code while other developers use Azure Emulator on their machines.
Another example would be to have a shared Azure account used by many developers (not sure about licence implications for this one!).
These are just off the top of my head and have their drawbacks. What strategies do you use?
2 Places I've worked we've done the following.
Single Common A/C
Create a common email-distribution group (myteamonazure#mycompany.com)
Register this mail address as an MSN Passport
Use it to sign up with Azure.
Pro's: Everyone on the team gets mails regarding the account.
Con's: If someone leaves the team, we need to change the account password.
Individual accounts
Let each person signup with their own account. (Mandate it must be their company email... not personal msdn passport)
Make one person the super-admin, and the rest co-admins
Pro's: If someone leaves, it's far easier to just revoke their credentials/privs
Con's: Lots more accounts to keep track of depending on the size of your team, particularly if you're company has a single Azure Account, with lots of different apps/projects hosted on it.
Personally, I prefer the second option as it's more secure/easier to revoke access to individuals.