I have an application which is converted to the enterprise application on Microsoft Azure. I want to make some changes in that like changing the Redirect URL, and Exposé an API URL.
Is there a way to achieve this?
In Azure Active Directory, the application you are referring to is just a template to create enterprise applications (service principals) in either the same (home) tenant or in multiple tenants.
You should still have the application template for your enterprise application within your Azure AD:
Any changes that you make to your application object are also
reflected in its service principal object in the application's home
tenant only (the tenant where it was registered). This means that
deleting an application object will also delete its home tenant
service principal object.
Source: Consequences of modifying and deleting applications
You can determine the related application id within the properties of the enterprise application:
Could someone please tell me what the difference is between "enterprise application" and "app registration" in Azure.
Appreciate if you could give me an example & why some application cannot be registered under blade "Enterprise application" and vise versa.
An App Registration is a way of reserving your app and URL with Azure AD, allowing it to communicate with Azure AD, hooking up your reply urls, and enabling AAD services on it. When you have an application that you are developing and want to integrate with Azure, you need to register your application in App Registrations, where you will configure your reply URL, logout URL, and API access if needed. When you register your application, Azure AD assigns a unique Application ID to it and allows you to add certain capabilities such as credentials, permissions, and sign-ons. The default settings allow only users from the tenant under which your app is registered to sign into your application.
The Enterprise Applications blade might be confused with App Registrations because the Enterprise Application blade contains the list of your service principals. However, the term Enterprise App generally refers to applications published by other companies in the AAD gallery that can be used within your organization. For example, if you want to integrate Facebook and manage SSO within your organization, you can integrate it from the Enterprise Applications dropdown in the applications blade. Your own applications will also be represented in the Enterprise Applications blade as Service Principals, which are instantiations of your applications in the tenant.
App Registration: https://learn.microsoft.com/en-us/azure/active-directory/develop/quickstart-v1-add-azure-ad-app
Integrating an Enterprise application (G-Suite): https://learn.microsoft.com/en-us/azure/active-directory/saas-apps/google-apps-tutorial
This is, I agree, potentially confusing to a new-to-AAD developer or administrator. Nitin's answer does a good job of summarizing this but I wanted to add an answer with documentation references.
At https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals it says:
The application object is the global representation of your
application for use across all tenants, and the service principal is
the local representation for use in a specific tenant.
Then, at https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-how-applications-are-added, it says:
You can manage application objects in the Azure portal through the
App Registrations experience.
Application objects describe the application
to Azure AD and can be considered the definition of the application,
allowing the service to know how to issue tokens to the application
based on its settings.
and
You can manage service principals in the Azure portal through the
Enterprise Applications experience. Service principals are what govern
an application connecting to Azure AD and can be considered the
instance of the application in your directory. For any given
application, it can have at most one application object (which is
registered in a "home" directory) and one or more service principal
objects representing instances of the application in every directory
in which it acts.
So, for third-party apps, you'll only have a service principal in Enterprise applications. For first-party apps that are internal, you'll have something in both places - one to define the app (App registrations) and one to allow the app to actually sign in to Azure AD (Enterprise applications). When you define the first-party app in the App registrations, you'll also automatically create an entry in Enterprise apps. If you look at the two entries, you'll see that the Application ID links the two together.
Shorter way to understand is...
App Registration are basically the apps local to the tenant/organization in which they have been registered to generate unique application id.
Enterprise apps blade shows global apps (belonging to other tenants) which can be configured and used within your tenant/organization.
The workflow is you create the App Registration (Application) in your tenant, which also creates the Enterprise Application (Service principal) in your tenant. Then when another tenant user wants to login to your app, they grant your app the permissions it requires and the Enterprise Application (Service Principal) is created in their tenant. This effectively mirrors your application in their tenant.
Additionally, within Application registration you can configure OpenId-Connect (OpenID/OAuth) based authentication. Within Enterprise Apps you can configure SAML based auth
Simple put:
Application Registration create an global application object which will allow the app to delegate to user identity for resource access, whereas the Enterprise application is the application identity(a service principle) in each AD tenant
Well, there're some good answers here but they are too verbose so I feel the simplest thing is show three pictures and one statement:
In the App Registration, we have "Application Objects":
To understand what you're seeing in the Enterprise Applications blade are "Service Principals":
And this is the relationship between the two in a multi-tenant example:
Adatum - The tenant used by the company that developed the HR app
Contoso - The tenant used by the Contoso organization, which is a consumer of the HR app
Fabrikam - The tenant used by the Fabrikam organization, which also consumes the HR app
And with that out of the way, we can understand this statement:
Similar to a class in object-oriented programming, the application
object has some static properties that are applied to all the created
service principals (or application instances).
The application object is the global representation of your
application for use across all tenants, and the service principal is
the local representation for use in a specific tenant. The application
object serves as the template from which common and default properties
are derived for use in creating corresponding service principal
objects.
Also said in a different way:
Application objects - Although there are exceptions, application
objects can be considered the definition of an application.
Service principals - Can be considered an instance of an application. Service
principals generally reference an application object, and one
application object can be referenced by multiple service principals
across directories.
Reference: https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals
I am currently use a multi-tenanted application, and have authentication working for a single azure AD. I would like to have multiple ADs connected to the authentication of the authentication page. How can I do so from within the Azure administrator console?
If I understood your question: you setup a multi-tenant app in the properties of the application in Azure, but currently your application only accepts user of one tenant to sign-in.
If this is the case, then what you have to do is to also adjust your application's code to be multi-tenant. In order to enable multi-tenancy on your application:
Double check you have set Multi-Tenanted property to Yes on your application registration's information in the Azure Portal (by default, applications created in the Azure Portal are configured as single-tenant)
Update your code to send requests to the 'common' endpoint (update the endpoint from https://login.microsoftonline.com/{yourtenant} to https://login.microsoftonline.com/common)
For some platforms, like ASP.NET, you need also to update your code to accept multiple issuers
For more information about multi-tenancy, see: How to sign in any Azure Active Directory (AD) user using the multi-tenant application pattern.
I'm working on an application that will allow users to authenticate to Azure Active Directory and then manage resources in their Azure account via Azure Resource Manager API calls.
I've found several walkthroughs on building such an app including this post. However, in the part that discusses authentication with Azure Active Directory, there's a step showing the need to manually retrieve the Azure Active Directory name from the Azure Portal.
The directory name is plugged into app settings (and ultimately authentication calls to the directory) as follows
http://login.microsoftonline.com/{directory_domain_name}/OAuth2/Authorize
Is there any way to programmatically retrieve {directory_domain_name} without requiring users to login and lookup the information in the Azure Portal?
The one answer to this question has a dead link and another pointing to the Graph API, which seems to still require the domain name.
For your particular scenario, look like you want to build an app that will be users from different Azure AD tenants. This scenario is best addressed by building a multi-tenant application.
To make your application multi-tenant, you'll need to go to the Azure Portal and in the Configure tab of your Azure AD application, set the "Application is Mult-Tenant" option to yes.
Once you do this, you can just call
http://login.microsoftonline.com/common/oauth/authorize
http://login.microsoftonline.com/common/oauth/token
And Azure AD will resolve the figure out which tenant to authenticate against based on the the credential that the user types in.
More information on multi-tenant applications:https://azure.microsoft.com/en-us/documentation/articles/guidance-multitenant-identity-authenticate/
Sample multi-tenant application: https://github.com/Azure-Samples/active-directory-dotnet-webapp-multitenant-openidconnect
I'm working on integrating Office 365 APIs into a web application that has different URLs for each organization (e.g. there could be an installation at http://organization1.com and an installation at http://organization2.com). Right now, for development, we have an Office 365 developer tenant and an associated Azure site. On Azure, we registered an application with a local URL as the return URL (e.g. http://localhost), and we use the Client ID and secret to authenticate calls to the API.
However, once we deploy this into production, we're going to have instances of the web application at many different URLs (one per organization), and organizations will have their own Office 365 account and associated Azure account. Does this mean that organizations will need to add the application themselves into their Azure directory, or is there a way for us to create an application that can be used with arbitrary tenants and return URLs?
What would be the best practice for a situation like this?
There are two approaches:
get the customer to create the application in Azure AD and get the client ID and secret key and store it in your app somewhere...either in the UI and securely store it somewhere based on the loaded tenant
OR
in Visual Studio change the setting (can do this in the Azure AD application in your tenant) to support "multiple Organizations". This is set when you go to Add Connected Service and select App Properties...