What OAuth API and permissions are required by an AAD application so that I can use it to authorize creating new AAD application as described in this example
You can give the app this permission on the Azure AD Graph API:
Manage apps that this app creates or owns
It is an app permission that allows the app to create applications and manage them. It does not allow it to manage other applications.
I created an app with this app permission, granted the permissions, got a token with client credentials flow and was able to create an app in my directory. So can confirm it should work once you get the permission granted.
Related
I've registered a single application in Azure AD for the following reasons.
Azure AD SSO (From Any Azure AD directory)
Read users, groups, and their members
Provided following permissions and granted admin consent.
NOTE: We still depend on some of the Azure AD Graph API. So, we have added the legacy API permissions.
I can able to contact the Azure AD using REST API and get the user, groups and other information.
When I try to sign in to the application from any other directory, I'm getting the following consent screen. I can able to provide the consent and proceed to log in.
But, when I try to login into the same directory, I'm not getting the consent screen even when I logged in with the Azure AD admin. Stuck in the following screen.
When I register separate applications for SSO and REST APIs, this issue doesn't occur.
I would like to know why I'm stuck in the above screen when combining both SSO and REST API permissions.
• Please check whether the correct Azure AD roles have been assigned to your account ID, i.e., Global Administrator, Cloud Application Administrator, Application Administrator, or owner of the app object through the as one of these is needed for you to access the application. Also, ensure that you have assigned your account ID the correct app role assignment for the admin consent to be allowed during the SSO signup process as below: -
You can check the app role assignments for your account ID through the Enterprise application blade and searching your application there, then opening it and selecting the users and groups blade, check the app role assignment that your account ID has to that application while also, giving ‘Azure Service Management’ api permissions for user_impersonification as below, thus ensuring that you account ID will be having correct API permissions.
Once, the above settings are configured correctly, you should be able to access the application through your admin credentials.
I have registered my REST Api project into my AzureAD so I can use AzureAD authentication. Lets call this app "RestApi".
I have also registered another console app, that will access this API. Lets call this "ConsoleClient".
How can I restrict access so only ConsoleClient will be able to access RestApi? I am able to set similar permissions for users (Enterprise apps -> Users and groups) but not for another Azure AD app.
You have to define app permissions in your API. My blog article has details on how to do that: https://joonasw.net/view/defining-permissions-and-roles-in-aad
Also, you have to check in the API that any access token has valid permissions in it. So, you have to check the roles claim in the case of app permissions.
I am working with an organization that has disabled user consent for azure apps.
"Users can consent to apps accessing company data on their behalf" is set to No in the Azure Portal.
I would like developers to be able to give consent to they own apps in azure without setting the above setting to yes. (the apps needs the "Sign in and read user profile" delegated permissions Azure AD).
1: Is it correct that the only other way is the assign the developers to one of the Azure AD roles that has one of these permissions: Application Developer, Application Administrator or Cloud Application Administrator?
2: I would also like to automate this process during a AzureDevOps release pineline. Currently the release pipeline creates all needed Azure resources via ARM Templates.
But how do I automate the App Registration without going to the Portal?
And how do I ensure that the release pipeline has the correct Azure AD permission to give consent?
Can I force the Pipeline to run as an "Azure AD Service User that I give the above role?
Update 1
It seems that its possible to do Azure AD Registration with powershell. http://blog.octavie.nl/index.php/2017/09/13/creating-azure-ad-app-registration-with-powershell-part-1
Since the AzureAD is using MFA, the script will display an interactive credential dialog when running. Not sure if we can suppress that.
Update 2
And give app consent with powershell. https://www.mavention.nl/blogs-cat/create-azure-ad-app-registration-with-powershell-part-2/?cn-reloaded=1
Update 3
So to automate the whole process, I was thinking if we could use a Azure DevOps Service Connection to execute these powershell scripts during the release pipeline?
Not sure what permission is needed for the Azure DevOps Service Connection?
It should also suppress the MFA credential dialog.
Is it correct that the only other way is the assign the developers to one of the Azure AD roles that has this permission: Application Developer, Application Administrator or Cloud Application Administrator?
It depends on the permissions the app is requesting, and who you would like the developers to be consenting for (themselves, or the entire organization):
Members of the Application Developer directory role can consent only to delegated permissions (not application permissions), and only on behalf of themselves (not on behalf of the entire tenant). Only other members of this role would be able to use the app (they would each consent on behalf of themselves), and only if the permissions requested are user-consentable delegated permissions. If your only requirement is for developers to be able to get delegated User.Read permission to Microsoft Graph, then this would work.
Members of the Application Administrator and Cloud Application Administrator directory roles can consent on behalf of all users for both delegated permissions and app-only permissions, except for app-only permissions to Azure AD or Microsoft Graph. These roles are both very privileged, and it is unlikely you would want the average developer to posses this--certainly not if the only permission needed is delegated User.Read.
But how do I automate the App Registration without going to the Portal?
With the Microsoft Graph API, you can register an app by creating an Application object. As of 2018-12-05, this is still in beta in Microsoft Graph.
If you require a production-ready endpoint, the Azure AD Graph API supports this, which is what's used by the various command-line and PowerShell options: New-AzureADApplication, az ad app create, and New-AzureRmADApplication.
To do this without a user involved, the client application (the one creating the app registration) requires the Application.ReadWrite.OwnedBy application permission, at minimum.
And how do I ensure that the release pipeline has the correct Azure AD permission to give consent?
This is where things get complicated. While it is possible to create the app registration (the Application object) as described above, these is currently no application permission that would allow an app to grant consent for another app. Though there is work underway to allow for "normal" application permissions to allow one app to grant other apps some permissions, currently only members of the directory roles authorized to consent to these permissions are able to perform this action.
We have an Azure resource app whose APIs we want to expose for access by a client app on Azure. The two apps are on different tenants. The users accessing the APIs (Office 365 account holders) are on different tenants.
The whole set up works when we manually provision a service principal on the tenant that is trying to authenticate from the client app against the resource app. By that I mean they are able to log in using their Office 365 account and are shown the consent screen.
If we do not provision a service principal on the AAD tenant of the user trying to authenticate, we get this error:
AADSTS65005 - The app needs access to a service <service> that your
organization org.onmicrosoft.com has not subscribed to or enabled. Contact
your IT Admin to review the configuration of your service subscriptions.
It is not feasible for us to provision a service principal on every tenant that is accessing our app (resource app). Is there something we are missing? Are we using the right flow?
You can find help for your scenario here: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-devhowto-multi-tenant-overview#understanding-user-and-admin-consent. (Scroll down to Multiple tiers in multiple tenants)
In the case of an API built by an
organization other than Microsoft, the developer of the API needs to
provide a way for their customers to consent the application into
their customers' tenants.
The recommended design is for the 3rd party
developer to build the API such that it can also function as a web
client to implement sign-up:
Follow the earlier sections to ensure
the API implements the multi-tenant application registration/code
requirements
In addition to exposing the API's scopes/roles, ensure
the registration includes the "Sign in and read user profile" Azure AD
permission (provided by default)
Implement a sign-in/sign-up page in
the web client, following the admin consent guidance discussed earlier
Once the user consents to the application, the service principal and
consent delegation links are created in their tenant, and the native
application can get tokens for the API
Basically, all of the parts that your app needs must be present as service principals in the customer's tenant. This is a requirement of AAD.
The only way for that to happen is for an admin to go through consent for the API and app separately, since they are registered in different tenants.
If they were registered in the same tenant, you could use the knownClientApplications property in the manifest to allow consenting to both at the same time.
In my case, I am exposing my own API and trying to access this API from my other Application (Client Credentials mode), I removed the default permission on both of the app(consuming app and api app) - "Azure Active Directory Graph-> User. Read" since I thought I don't need that but that caused this problem "The app needs access to a service .... that your organization has not subscribed to or enabled. Contact your IT Admin to review the configuration of your service+subscriptions.
I got the clue from the answer of #juunas - point 2. Thx Juunas
I am using https://www.nuget.org/packages/Microsoft.Azure.Management.Fluent for creating resources in Azure programmatically. The package requires me to create an Azure AD Application which will be used by my console app to authenticate for the resource management api. So far so good - I created that AD app and use that in my console app, "normal" resource management is working fine.
Now I wanted to start to also programmatically create other Azure AD Applications using the https://www.nuget.org/packages/Microsoft.Azure.Management.Graph.RBAC.Fluent package, which is a direct dependency of the package mentioned above. While I can use the package e.g. for listing existing Azure AD Applications, I am getting authorization issues (401) as soon as I try to create new Azure AD applications with it. I tried playing around with the permissions I gave to the AD app used by the console app, but had no success.
Is there either a way to...
give an Azure AD Application permission to create other Azure AD Applications (this is my preferred way), and if so, which are the permissions required?
or to use the Microsoft.Azure.Management.Fluent package with an actual "human" user account that has the permissions required to create Azure AD Applications?
The https://www.nuget.org/packages/Microsoft.Azure.Management.Graph.RBAC.Fluent package uses Azure AD Graph to create the application.
And there is no such app-only permission that we can create the application. As a alternative way we can grant the Directory.AccessAsUser.All permission for the Windows Azure Active Directory and the sign-in user with Global Admin for that tenant. Here is a figure which grant the specific permission for your reference:
Update
This library which using the Resource Owner Password Credentials Grant is designed for the native client application.
In this scenario, you can register an native client app which is public app that there is no secret. Or you can perform the Resource Owner Password Credentials Grant flow using the HttpClient class. Here is a piece of code for your reference:
HttpClient client = new HttpClient();
string body = String.Format("resource={0}&client_id={1}&client_secret={2}&grant_type=password&username={3}&password={4}", Uri.EscapeDataString("https://graph.windows.net"), "{clientId}", Uri.EscapeDataString("{client_secret}"), Uri.EscapeDataString("{userName}"), Uri.EscapeDataString("{password}"));
StringContent sc = new StringContent(body,Encoding.UTF8, "application/x-www-form-urlencoded");
var resoult= client.PostAsync("https://login.microsoftonline.com/xxx.onmicrosoft.com/oauth2/token", sc).Result.Content.ReadAsStringAsync().Result;
Console.WriteLine(resoult);
In addition, since the Resource Owner Password Credentials Grant flow use the users' username/password to authentication, please ensure that the you trust the client which run this app( refer Resource Owner Password Credentials Grant).