I want to create a multi-tenant application where users will log in using Azure AD B2C. I will grant access to certain tenants that are our customers using policies. Only business customers from select tenants will have access.
I have a customer that requires granular control over which of their users can access my application. From what I've understood, my application will be registered as a service principal in their tenant as soon as a user consents to the applications requested permissions.
That as all well, but the service principal is only a kind of account, with access to certain resources in their tenant that was granted when the application was accepted. When the application has been registered in their AD, anyone from that organization can sign in. When someone signs in, that automatically creates a Consumer account in Azure AD B2C in our tenant.
The consumer user can sign in to applications secured by Azure AD B2C, but cannot access Azure resources such as the Azure portal. The consumer user can use a local account or federated accounts, such as Facebook or Twitter. A consumer account is created by using a sign-up or sign-in user flow, using the Microsoft Graph API, or by using the Azure portal.
Now, I have a customer that also wants to control that only certain accounts within their AD can login. So basically, a user identity should not be able to access a service principal?
Is this a use case that is supported, and if so, how do I handle it and what terminology am I looking for? I don't want my organization to handle any of this if possible. I just want to give all users in a tenant access, and then it is up to the customer to grant/revoke access to individual users.
If I understand correctly, As you have created a multi-tenant application it will be registered in your tenant as a Service Principal and for the customers tenant it will be in Enterprise Application . So , if they want to give access to few users or a particular group then they can assign user/group to that particular Enterprise application.
Example:
Service Principal Created on my tenant :
It gets registered as a Enterprise application in other tenant So in there we can select Assign Users and Groups to give access to this Application from their tenant or they can set conditional access policy as well for specified set of conditions.
Reference:
Restrict Azure AD app to a set of users - Microsoft identity platform | Microsoft Docs
Related
I want Azure for my application's identity management. Also I require a customer to sign up and become the owner account of my application. And he should send invitations to others. Example consider a university principal sending invitations to his instructors. An instructor sending invitations to his students. This should look like an inverted tree structure. Also my application should have many owner accounts. For example, multiple university principals should have an account in my application. How can I implement this using Azure? Should I use Azure AD B2C or Azure AD B2B?
I need azure only for authentication.
Difference to see to choose between the services is which user (random cunsumer or user from same organization) .
You can make use Azure AD B2B which is a feature of AzureAD service if the Application is for organisations and their corporate users.
Azure AD B2C target is to build a directory for consumer applications where users can register themselves with e-mail ID or social providers like Google, FB, MSA, known as Federation Gateway. Azure AD B2C is not targeted at organisation users but consumers.
Both are azure ad identity management services .It depend on who your users are from same organization or random customers that registers themselves.
In both services,user can send invitation to other user through portal or bulk of users using csv template from portal or powershell.
First the user need to sign in as global administrator to assign roles to users and groups.
The user can be given owner role to the app.
You can make more than one member as owner to an application
References:
azure-ad-vs-azure-ad-b2c-vs-azure-ad-b2b -SO reference
add-users
https://learn.microsoft.com/en-us/azure/active-directory/privileged-identity-management/groups-assign-member-owner
I'm building a C# MVC webapp.
The plan is:
First time user creates a custom account
When logged in, add a tenant with Microsoft OAuth2, agree to permissions
The webapp aggregates pre-configured Log Analytics items for each user's onboarded tenants.
How do I handle multitenant onboarding, where one user supplies multiple tenant accounts?
How do I authenticate and authorise once and call Azure APIs forever?
Multi-tenant mentioned by #StanleyGong should make sense.
In this case, you can add your account as guest user to the multiple tenants, assign RBAC roles to give the user access to the Azure Log Analytics.
Configure the authority as https://login.microsoftonline.com/{tenant-id} for multiple tenants in a configuration file. When you sign in with this account, choose different tenant based on different {tenant-id}.
You cannot sign in once to access to all the Azure Log Analytics data from all tenants. And you also can't authenticate and authorize once and call Azure APIs forever. Access token has lifetime. After it expires, you should re-authenticate.
General Overview of what I am trying to achieve
I am trying to build an Azure AD Multitenant Web application which allows me to manage resources in customer subscriptions/tenants using the Azure Resource Manager (ARM) APIs. I am pretty new to Azure AD Multitenancy.
The Ideal control flow
1. A customer browses the Applications (ideal an admin of the customer tenant)
2. Will be granted with Azure AD authorize flow
3. Accepts everything and grants admin consent for the AD App in their tenant
4. Unclear: The AD App will be granted contributer access on a subscription or resource
5. My Web App will be able to use the AD App credentials to manage the customer resources using the ARM APIs
Problem
Steps 1-3, 5: Are clear and I know how to build that.
Step 4: I am not sure how to build that so that step happens automatically.
Solutions I have considered
The worst case would be the customer AD Admin must manually grant the AD App access to a subscription or resource using the Azure Portal.
One idea that came to my mind is that you require the user_impersonation permission on Azure Service Management API.
After the user logs in, you could list out the subscriptions available, allowing the user to select one.
Then list out the resource groups if needed.
Once the user confirms a selection, your app could add itself as a Contributor on the targeted resource through the Management API, on behalf of the currently signed-in user.
To do this, you will need the object id of the service principal for your app created in the target tenant.
You can get it by acquiring an app-only token for e.g. the Azure Management API from that tenant's token endpoint after the user has logged in.
The token will contain an oid claim, which is the object id for the service principal.
Of course the user who signs in would have to have the ability to modify access to the target resource.
I would say the downside of this approach is that the organization must trust your app to only do the thing it claims to do.
The approach where they grant the access manually allows them to be in control fully.
I registered a mutitenant application in my tenant. This application is shown in both App Registration and Enterprise Application menu in my tenant as I registered it. And I'm getting the users by using Graph Api.
My Question is : - I provided my multitenant application to other tenants and I wanted to get all the users of that tenant who get to registered in my application. How do we get the other tenant's user if they registered in my multitenant application?
If it's not an B2C scene, I assume that the other tenants have added your multi-tenant application.
Then you should implement Get access on behalf of a user with an account of the target tenant. And use this account to query the users with Microsoft Graph API: List users.
You can't use an account of your tenant to query the users of other tenants unless you add your account as a guest into other tenants. But this is another scene, it doesn't require muti-tenant application.
I find the authorization flow confusing for calls to Azure's management APIs, i.e. not Azure API management which is the API gateway SaaS, and I'm hoping for some clarification.
From documentation at https://msdn.microsoft.com/en-us/library/azure/dn629581.aspx:
Although Azure originally allowed access only by Microsoft account users, it now allows access by users from both systems. This was done by having all the Azure properties trust Azure AD for authentication, having Azure AD authenticate organizational users, and by creating a federation relationship where Azure AD trusts the Microsoft account consumer identity system to authenticate consumer users. As a result, Azure AD is able to authenticate “guest” Microsoft accounts as well as “native” Azure AD accounts.
and http://blogs.technet.com/b/ad/archive/2014/08/15/prepping-for-new-management-features.aspx:
Your Microsoft Azure subscriptions uses Azure Active Directory to sign users in to the management portal and to secure access to the Azure management API.
The documentation leads me to believe the Azure AD tenant associated with a subscription acts as a STS with management API being the RP, or authorization server and resource server respectively using OAuth terminology. The tenant can also choose to trust third-party STSes, e.g. another tenant or Microsoft Account services, and thus allow for users from external identity providers access to the management API.
The blog post also writes:
Azure will soon require administrators to be registered in Azure Active Directory to be able to sign in to the Azure portal or use the Azure management API.
Disassociating an admin's account with the subscription's Azure AD tenant, irrespective if it is a "native" account to a tenant or a federated account, should in my mind revoke their access to the management APIs.
I tried validating the assumption using one my subscriptions and couldn't quite make sense of the result. Let's say the subscription has three admins:
Service admin SA using a federated Microsoft Account
A co-admin CA-AAD using an account "native" to the tenant trusted by the subscription
A co-admin CA-MSA again using a federated Microsoft Account
With all three accounts registered with the tenant, any of them can manage resources belonging to the subscription as well as use an web application that in turn access the Insights API through user impersonation.
Removing CA-AAD from the tenant disallowed the account from managing resources and accessing the Insights API once the cookie/access token had expired. This is the expected behavior, except the now non-exitant account still remains listed as a co-admin for the subscription.
However, removing CA-MSA from the tenant did not prevent the account from managing resources or accessing the API. This behavior even persisted between sessions and the account remained listed as a co-admin and not quite the expected outcome.
And now onto the questions:
Why is CA-MSA allowed continued access to management APIs despite it not registered with the tenant?
What is the authorization flow for accessing the management APIs?
How are accounts mapped to those listed as co-admins for a subscription?
Azure subscription refers only two directories for authorizing the users for accessing the management API.
the Azure AD to which the subscription is associated to.
Microsoft AD(MSA).
When a user with Microsoft Account is added as a subscription co-admin, user is indirectly registered in the Azure AD to which the current subscription is associated to. If the user is deleted from Azure AD, it still has the subscription access. It is because the user is still present in Microsoft Account AD.