Note For more information, see the Microsoft TechNet article . Granting access with the consent experience prior to March 12, 2014 The "legacy" consent experience allows you to only grant the following permissions: Sign on users from their organization. Sign on users and read the their organization’s directory data (as the application only) Sign on users and read and write their organization’s directory data (as the application only) In order to be effective, this implies to: Prepare the application’s project to handle multiple tenants Add sign-up capabilities to the application The article outlines how to build a multi-tenant web ASP.NET MVC 4 application that can be used by organizations that have Azure AD. Important note This illustration will be removed soon. A sample code that addresses a similar scenario is available . The rest of this chapter illustrates the two above steps for the legacy consent experience. Preparing the application’s project to handle multiple tenants (legacy) Adjusting the web single sign-on (and single sign-out) protocol coordinates in the configuration As previously mentioned, in lieu of the tenant-specific endpoints https://login.windows.net/<tenant domain name>/<protocol>, the tenant-independent endpoints https://login.windows.net/common/<protocol> enables the application to know which tenant the user is in during sign-in. Azure AD signs the user in and figures out their tenant, handling this way for you the Home Real Discovery (HRD) or Where Are You From (WAYF). You should consequently adapt the endpoint(s) being used in your application accordingly. Likewise, the authentication response must be processed to check user is from a consented tenant. For that purpose, you must validate the audience that relates to the various consented tenant. Important note Azure AD will issue a token to a user only if the recipient application has been granted access within the user’s directory. Using the tenant-independent endpoint does not weaken the access constraints established at the directory level; it just adds generality to the sign-on process. A list of the consented tenant domain name should be typically maintained by the application as part of the sign-up process. (See below.) As far as the sign-out is concerned, it can use either the tenant-specific of the tenant-independent sign-out endpoints.
Note For more information, see the Microsoft TechNet article . Granting access with the consent experience prior to March 12, 2014 The "legacy" consent experience allows you to only grant the following permissions: Sign on users from their organization. Sign on users and read the their organization’s directory data (as the application only) Sign on users and read and write their organization’s directory data (as the application only) In order to be effective, this implies to: Prepare the application’s project to handle multiple tenants Add sign-up capabilities to the application The article outlines how to build a multi-tenant web ASP.NET MVC 4 application that can be used by organizations that have Azure AD. Important note This illustration will be removed soon. A sample code that addresses a similar scenario is available . The rest of this chapter illustrates the two above steps for the legacy consent experience. Preparing the application’s project to handle multiple tenants (legacy) Adjusting the web single sign-on (and single sign-out) protocol coordinates in the configuration As previously mentioned, in lieu of the tenant-specific endpoints https://login.windows.net/<tenant domain name>/<protocol>, the tenant-independent endpoints https://login.windows.net/common/<protocol> enables the application to know which tenant the user is in during sign-in. Azure AD signs the user in and figures out their tenant, handling this way for you the Home Real Discovery (HRD) or Where Are You From (WAYF). You should consequently adapt the endpoint(s) being used in your application accordingly. Likewise, the authentication response must be processed to check user is from a consented tenant. For that purpose, you must validate the audience that relates to the various consented tenant. Important note Azure AD will issue a token to a user only if the recipient application has been granted access within the user’s directory. Using the tenant-independent endpoint does not weaken the access constraints established at the directory level; it just adds generality to the sign-on process. A list of the consented tenant domain name should be typically maintained by the application as part of the sign-up process. (See below.) As far as the sign-out is concerned, it can use either the tenant-specific of the tenant-independent sign-out endpoints.