I am a bit new to Azure AD and some of its features. I have a vendor application that wants to setup authentication & single sign on using our Azure Active Directory. The documentation they provided me with just walks through adding Azure AD SAML Toolkit as the enterprise application and configuring it accordingly. However, I noticed immediately that the description for that enterprise application was "This is the sample SAML app which customers can use to test the SAML single sign-on integration with Azure AD."
My question is, shouldn't a vendor application have setup an enterprise application for me to add to our Azure tenant or is it common and good practice for applications to use the Azure AD SAML Toolkit for production implementations?
So far I have found no reason documented that this is bad practice. We have implemented it for the vendor application and have had no issues up to this point.
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.
We have an API, we planning to publish this API in the Azure marketplace under developer service. For authentication, we are planning to use developer service SSO (Single sign-on) in API. I googled this but can't find any useful link, please suggest some links
Azure AD B2C became generally available recently and it somehow offers what you are looking for. You can use local Azure identity and/or social account for your end users to authenticate with SSO support.
https://azure.microsoft.com/en-us/services/active-directory-b2c/
With that being said and although you can secure your Web API with AAD b2C as in this guide, your customers won't be able to call this WebAPI from their own applications as the calling app must be registered in the same Azure AD directory with the same application Id. This is a limitation that is mentioned here:
Note:
Azure AD B2C currently supports only web APIs that are accessed
by their own well-known clients. For instance, your complete app may
include an iOS app, an Android app, and a back-end web API. This
architecture is fully supported. Allowing a partner client, such as
another iOS app, to access the same web API is not currently
supported. All of the components of your complete app must share a
single application ID.
If the above limitation is OK with you, then you might also be interested in this Azure article to list your app in the Azure AD application gallery.
We want to develop a mobile application which will be used by users in multiple organizations. Each of these organizations will have an Azure Active Directory tenant owned by them. We want to use Azure Mobile Services for authenticating users.
Once the user is authenticated and the mobile app has the JWT token, it will be subsequently sent to our API gateway to access various services.
Is is possible to use Azure mobile service Identity component in such a way that the app can authenticate against multiple Active Directory tenants? In other words can we create a multi-tenant mobile app which can authenticate against multiple Azure Active Directory tenants owned by different organizations?
Azure Active Directory does support development of multi-tenant web apps and there are sample applications available which demonstrates this capability. However is it possible to achieve the same functionality in a mobile app using Azure mobile services?
It is very much possible to build multi-tenant mobile apps backed by Azure Active Directory authentication. However, I doubt if Mobile Service will help here. Rather, I'll recommend creating a WebAPI project with AD authentication and consume those APIs in mobile apps. The samples that you've mentioned can be very much useful.