From the page about Azure CLI Sign-in:
Service principals are accounts not tied to any particular user, which can have permissions on them assigned through pre-defined roles. Authenticating with a service principal is the best way to write secure scripts or programs, allowing you to apply both permissions restrictions and locally stored static credential information
It seems that a service principal is kind of a service account, a sort of identity which isn't tied to any specific person.
On the other hand, from here it seems that a service principal is an instantiation of the Application object in the domain of App registrations. This has something to do with registering an application so it can be authorized using OAuth 2.0 etc. etc.
So I can't understand the relation between these two concepts. Can someone help?
Service principal is sort of a service account.
It is the thing that permissions are assigned to.
For example, if you consent to an application reading your user profile on your behalf, that adds an OAuth 2 permission grant to the service principal.
Application permissions add an app role assignment to the service principal when granted.
When you make an app registration, a service principal is also created in that same Azure AD tenant.
Even though you add required permissions and consent to them through the app registration forms, the permissions are actually assigned to the service principal.
The app registration is only really a template.
Where this gets interesting is if you have a multi-tenant app (other Azure AD tenants' users can use your app).
In this case a service principal representing your app is also created in other Azure AD tenants when a user consents to the permissions your app requires.
Essentially you get an automatically generated service account in each tenant using your app.
This allows admins to decide which permissions to grant your app, which users can access the app etc.
Related
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
Say I have an App1 in Tenant1. This App1 has contributor access to a subscription SUB_1 in the same Tenant1. There is a App1_ClientId and App1_ClientSecret associated with the App1.
Now, I can use this id and secret to login to that tenant and do stuff with the SUB_1 using the URL:
https://login.microsoftonline.com/Tenant1_ID/oauth2/token
Now how does it make a difference if this App is single tenant App or Multi Tenant App? Using this Id/Secret, I can access login to this app from any service anywhere.
Also, What does it mean by "Adding users to this App" ? Say if i add a user to this app, does it mean that that user will have access to the subscription in Tenant1 as well?
Now how does it make a difference if this App is single tenant App or
Multi Tenant App? Using this Id/Secret, I can access login to this app
from any service anywhere.
The difference would come if you want this application to be available in other tenants.
With single tenant, the Service Principal will be created only in your tenant. If you make this application multi-tenant, once a user in a different tenant consents to the application a Service Principal will be created in that tenant. That Service Principal must be granted appropriate Azure RBAC permissions in Azure Subscriptions associated with that other tenant. Only then your application will be able to perform operations on an Azure Subscription using client id/secret.
Also, What does it mean by "Adding users to this App" ?
When you create an application, you can define some roles specific to that application. When you add users to the application, you can assign users in one or more of those roles and then whenever your users access the application, they will be able to do operations allowed by those roles.
To elaborate, let's say your application is a Web API that has 2 controllers actions - Get and Post. What you can do is restrict the access to these controller actions based on the application roles. A user in appropriate role will be able to access those controller action.
Say if i add a user to this app, does it mean that that user will have
access to the subscription in Tenant1 as well?
Not necessarily true. If you're invoking Azure management APIs on behalf of the signed-in user, then they must be assigned proper Azure RBAC role to perform operations. However if you're invoking Azure Management APIs on behalf of the application, then you can configure your application so that these APIs are called in appropriate portions in your code which are protected by the application roles. For example, you would want to implement read operation in your Get controller action and a create operation in your Post controller action.
In your example, if App1 was a single tenant app, it will only have access to the resources granted to it in Tenant1. While you can use that app_id and secret in a code that runs anywhere: in that tenant, in another tenant or even in another cloud, the code can only access the relevant resources in Tenant1.
If you want your app to be able to access resources across multiple tenants, it needs to be added to each of those tenants by an administrator in the respective tenants. This can only be achieved when you have configured App1 as a multi-tenant application.
Adding a user to an application allows the user to access the application itself. The user does not automatically get/inherit any permissions that are granted to the application (such as a role in a subscription in your case)
i was reading about AAD privilege escalation in one of the article where the author states that "if you compromise an Application Administrator account or the on-premise Sync Account you can read and modify directory settings, group memberships, user accounts, SharePoint sites and OneDrive files. This is done by assigning credentials to an existing service principal with these permissions and then impersonating these applications"
my questions are?
1.how can i find what privilege my app admin account has and how it is different from the permissions
that "application " has.
2. what does assigning credentials to a service principal means?
As mentioned in Carl's link,
The Application Administrator role allows users to create and manage all aspects of enterprise applications, application registrations, and application proxy settings. This role also grants the ability to consent to delegated permissions and application permissions, with the exception of permissions on the Microsoft Graph API.
Applications can have different privileges added to them, and a user in the Application Administrator role can add extra permissions to an application and theoretically use those credentials to impersonate the app's identity and have more privileges than originally intended.
An Azure service principal is a security identity used by user-created apps, services, and automation tools to access specific Azure resources. Just as a user is represented by a security principal called a user principal, an app is represented by a service principal. The service principal provides an identity for your app, allowing you to delegate only the necessary permissions to the app. It improves security if you only grant it the minimum permissions level needed to perform its management tasks. So if you assign credentials to a service principal you can grant or restrict the app's access to certain resources.
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.
Azure Active Directory has applications and service principals.
https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals
Both objects seem to have credentials.
New-AzureADApplicationPasswordCredential
New-AzureADServicePrincipalPasswordCredential
If both a service principal and an application object have credential(for example password), which one is used for authentication? If service principal's credential is used, what's the purpose of application object's credential? Is it for fallback when a service princial doesn't have credential?
I read this question, but I cannot understand the difference between application's password and service principal's one.
Authentication difference between using AAD app key and Service Principal Password
Both of the two passwords can be used to authenticate, but the password of the service principal just can be used to authenticate in the tenant which it located in, the password of the application can be used to authenticate in all the tenants where its service principal instances located.
The service principal is just a instance of the application in a specific tenant, when a tenant consent an application, azure will install it as an Enterprise Application(i.e. serivice principal) in the tenant. There can be several service principals in different tenants, but the application is the only.