Companies that want to move their employees to SaaS apps like Office 365 are sometimes worried about opening their networks to information leaks. If users can access Office 365 with their corporate identity, they can also access these same services with other identities.
Before cloud services, network admins could simply block access to unwanted apps or websites by blocking their URL or IP address. This is no longer an option with SaaS apps, where a single endpoint (like outlook.office.com) is used by all consumers of the SaaS app.
Our solution for this common IT challenge is Tenant Restrictions. This new feature enables organizations to control access based on the Azure AD tenant the applications use for single sign-on. For example, you can use Tenant Restrictions to allow access to your organization's Office 365 applications, while preventing access to other organizations' instances of these same applications.
An on-premises proxy server is configured to intercept authentication traffic going to Azure AD. The Proxy inserts a new header called "Restrict-Access-To-Tenants" that lists the tenants that users on the network are permitted to access. Azure AD reads the permitted tenant list from the header, and only issues security tokens if the user or resource is in a tenant on that list.
The following diagram illustrates the high-level traffic flow.
If a user on the Contoso network tries to sign in to the outlook.office.com instance of an unpermitted tenant, he or she will see this message on the web page:
As always, we want to hear your feedback about this new feature. If you have any feedback, questions, or issues to report, please leave a comment at the bottom of this post or tweet with the hashtag #AzureAD.
Best regards, YossiYou must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.