Let's say I have a company of 100 employees/users in its Azure AD Premium P1.
This company has 100 monthly active external users in its Azure AD.
This company has some SaS multitenant applications(app registrations) which are used by 1000 monthly active users from different companies who have their own Azure Ad subscription.
For 100 users from the company's Azure AD Premium P1 applies pricing $6 per user/month.
For 1100 users(100 externals and 1000 from other Azure Ad subscriptions who use the multi-tenant apps) apply the MAU pricing - First 50,000 MAU $0/Monthly Active Users.
Am I right?
I'm quite sure that you don't pay anything for the users that are not represented as users in your tenant.
Only for the ones that sign in against your tenant.
If you publish a multi-tenant app, those users will log in against their Azure AD tenant.
On the other hand if you have an internal application (single-tenant) and you also allow partners to access it, those would count as external users in your tenant.
Related
I am building an application which will use Azure B2C as the identity system. It will include some local accounts, and some federated accounts for Enterprise SSO logins.
The application will have “application tenants”, representing customer organization/company.
I’d like a user to be able to grant users access to one or more application tenants (in case some users will manage multiple company accounts within the app).
There will also be multiple roles within the app (e.g. read only, full admin).
What is the recommended way to map a B2C User to “app tenants” and roles?
Create AAD group per tenant and role and check membership?
Custom attribute for tenantid(s)?
Or must I map users to tenants & roles in app DB/ outside of B2C?
Is this scenario described in any docs that might point me in the right direction?
Thanks!
I am migrating a "On-Premise WinForms App" to a "Multi-tenant SaaS App" written in ASP.NET CORE. The SaaS application will be used by multiple tenants and the tenants don't see each others data. In our legacy product, user profiles and credentials were stored in each customer's database and the CUSTOMER could add/remove users from the system, as they saw fit.
In a web environment, it looks like an Identity Provider is the suggested route, by separating the user profiles and credentials from the application data itself. However, much of our data is tied to a UserId, so its important to know which USER created a record.
Now, in Azure AD, the setup would put ALL users from ALL CUSTOMERS into 1 Azure AD. I don't particularly have an issue with that, but HOW do I know what CUSTOMER the USER account belongs to?
For example, customer ACME has 2 users: Bob and Bill. My other customer FOOBAR has 2 users: Jean and Jack. If Jean authenticates against Azure AD, I need to know a unique ID for FOOBAR, so I can filter data in the web application. When Azure AD sends back an IDToken from OpenId Connect, the TenantId in the claims is the TenantId of my company, NOT a tenant identifier for the CUSTOMER.
What is the recommended setup if we are going to deploy a multi-tenant SaaS application and use Azure AD for Authentication and still control which users can access the application? Azure Active Directory B2B?
You group users using security groups (one per customer) and Configure group claims so that you get them in the tokens.
Imagine that a large company that has a number of subsidiaries. A shared IT company manages the Active Directory (and almost all other IT services) centrally for all subsidiaries. There also currently exists an Azure tenant which is connected to the On Premises Active Directory, however for issues surrounding who controls/owns which resources employees cannot use this Azure tenant.
One of the subsidiaries decides it wants to create it's own Azure tenant so it can progress it's development work. However that company is told that "Only a single federation to an Azure tenant is currently supported per Active Directory Domain".
I found this document. Would it be reasonable to presume that if the company consisted of the Contoso implementation that it would still be possible to federate 2 azure tenants to that single On Premises Active Directory. Are there any reasons why one implementation of On Premises Active Directory would be capable of this functionality and another not.
Yes, you can do this but you can only have one AD Connect instance per tenant as there is a 1:1 relationship between an Azure AD Connect Sync server and an Azure AD tenant. So you need to register three separate UPN suffixes for each tenant with the on-premises Active Directory and use three separate sync servers (one for each tenant). You need to apply filtering while syncing AD users for each tenant.
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-single-adfs-multitenant-federation
When I log onto the Microsoft Graph Explorer with my Microsoft account and run the following query https://graph.microsoft.com/v1.0/users/ I get the correct user returned.
On Azure AD (using the same login) I created an application with a key and when I sign in through c# using Microsoft.IdentityModel.Clients.ActiveDirectory.ClientCredentials with a token for resource https://graph.microsoft.com and run the same query I get a completely different user. They are out of sync and I'm baffled.
Any ideas? Should I create a new Azure account as I've had the Azure account from day 1 and I'm only doing this now to test for a client request.
Don't create a new Azure account. When you are using Graph Explorer, are you signed in with a user from your Azure AD tenant? If not, Graph Explorer will default to use a demo tenant for your queries.
Also (if you have more than one tenant) you need to make sure that you select the correct tenant as part of the token acquisition (from https://login.microsoftonline.com/{tenantId | tenantDomain}. If you want the results to match between Graph Explorer and your app, the tenant the signed-in user belongs to (for Graph Explorer case) and the tenant used by your app needs to be the same.
UPDATE based on comment below:
I think I know what's going on here. In graph explorer, you are signing in with your personal account - and it's showing you profile data of that personal account, including the unique ID for this account in the Microsoft Account system. In this case you aren't signing into an Azure AD tenant at all. Microsoft Graph supports access from both personal and commercial accounts.
Now, additionally, I'm guessing when you signed up for an Azure subscription, you used this personal account. When you do that, it creates an Azure AD tenant, and creates a guest user in that tenant that is (linked to) your personal account - this account is also configured as an admin account. This mechanism allows you to sign in with your personal account (authenticated by the Microsoft Account system) into an Azure AD tenant, because the personal account maps to this guest user in your tenant. In your application, you are getting an app token to your Azure AD tenant. When you query the tenant for users, you don't see any user with the same id or email address as you did with graph explorer. However if you actually look at the userPrincipalName, you'll see it should be a mangled form of the original email address of your personal account. This indicates that this Azure AD user account in your tenant is a guest/external user (similar to a foreign principal).
Hope this helps,
When RBAC was introduced in Azure Active directory, roles can be granted to users or collection of users (groups).We followed this blog post and added that functionality for our apps when it first got introduced. But now, we have to go for active directory premium to assign roles to groups and get roles in bearer token.Going with Azure Active directory is not a feasible solution for us as premium is gonna cost us $6 user/ month and we have lot of groups and each group has lot of users. Looking at the costs our IT team is not willing to go for this package. I was just wondering if there an alternative approach for mapping roles to groups. Or this is only doable using premium.
Using Azure Active Directory (Azure AD) with an Azure AD Premium or Azure AD Basic license, you can use groups to assign access to a SaaS application that's integrated with Azure AD( refer here about detail).
So if you want to manage the roles using the group, we need at least the Azure AD Basic license. If you were using the free edition, we can only assign the roles to the users one by one.
Instead using the role manage the access for the application, we can also use the group which also supports for the Azure AD free edition. You can check the code sample about authorization in a web app using Azure AD groups & group claims from here.