Skip to main content
Microsoft 365
Subscribe
4 min read

Works with Office 365 – Identity program

By

Editor’s note 10/3/2016:
As we continue to expand the number of qualified third-party identity providers, the “Works with Office 365 – Identity Program” has been updated and is now the “Azure AD Federation Compatibility List.”

Paul Andrew, @pndrw, is technical product manager for Identity Management on the Office 365 team.

Your company directory is the list of users who can sign in to use applications and the users that you can look up so you can send an email or grant access to documents. Office 365 provides three ways for you to manage user accounts in your directory: cloud identity, directory synchronization, and federated identity-all described in this post. Often customers using the third way, federated identity, need to integrate Office 365 with an existing (third-party) identity provider that holds their directory. The Works with Office 365-Identity program, which we also describe here, facilitates this process by qualifying third-party identity providers with Office 365.

Three ways to manage user accounts in Office 365

1.       Cloud identity: Users are created and managed in Office 365 and are stored in Windows Azure Active Directory (AD). There is no connection to any other directory.

Cloud identity has no integration requirements. Each user is created once in the cloud and the account exists only in Windows Azure AD.

2.       Directory synchronization: Users are created and managed in an on-premises identity provider and are synchronized to Windows Azure AD, where they can be used for login to Office 365.

Directory synchronization uses an existing on-premises directory and synchronizes it to Windows Azure AD. This synchronization can be done from an on-premises active directory using the Directory Synchronization tool, or it can be done from a non-AD on-premises directory using PowerShell and the Azure AD Graph APIs. Synchronization means that accounts are managed on-premises and properties cannot be edited through the Office 365 cloud interface. If you’re using the Directory Synchronization tool with Active Directory, then password hashes can also be synchronized so that users can log in with the same password on-premises and in the cloud. For more information about directory synchronization and password hash synchronization, see TechNet Documentation for Directory Sync and Password Sync.

3.       Federated identity: In addition to directory synchronization, login requests are handled by the on-premises identity provider. Federated identity is usually used to implement single sign-on.

Federation provides for a user to be signed in using the federated identity provider for the user’s password check. Directory synchronization is also required as a prerequisite in order to populate the cloud-based directory. When using federated identity, many Office 365 customers use Active Directory Federation Services, which manages login password checks with the on-premises Microsoft Active Directory infrastructure. Some customers use third-party identity providers and Microsoft supports Office 365 when it is connected with a variety of qualified third-party identity providers. Here are the federation options:

The Works with Office 365-Identity program

The Works with Office 365-Identity program provides testing and qualification of third-party identity providers with Office 365. Office 365 uses Windows Azure Active Directory for identity management and through this includes directory synchronization and federation. Microsoft supports Office 365 for customers who are using Office 365 with a federated identity provider that is qualified under the Works with Office 365-Identity program. Identity providers that have not been tested by Microsoft  are not qualified for federation with Office 365.

If you’re an Office 365 customer, you can use an identity provider that is qualified in the Works with Office 365-Identity program and know that Microsoft has tested the configuration and that it will be able to support Office 365. Please note that for information about configuring or troubleshooting the third-party identity provider you should contact the third party instead of Microsoft.

The Works with Office 365-Identity program is currently focused on WS-* identity providers. These providers use one of the following two protocols:

  • WS-Federation is the protocol used to support sign-in to Office 365 using the web interface, sometimes known as “passive authentication.” This includes the Office 365 portal, SharePoint Online, Outlook Web Access, and the Office Web Apps.
  • WS-Trust is the protocol used to support sign-in to Office 365 using Office client applications, sometimes known as “active authentication.” This includes Outlook, Lync, Word, Excel, PowerPoint, and OneNote.

SAML-P and Shibboleth are alternative protocols to the WS-* protocols, and they provide sign-in support for web applications that is similar to WS-Federation. In some cases SAML-P and Shibboleth can also be used to sign in to Outlook using the Enhanced Client or Proxy (ECP) extension. Sign-in to Office 365 from other Office client applications is not possible with SAML-P or Shibboleth.

Qualified Works with Office 365-Identity partners are listed below, according to the protocols they use.

Frequently asked questions about the Works with Office 365-Identity program

Q: I want to use Office 365 with an identity provider that is not listed here.

A: Please check back here for updates as we work on qualifying new identity provider partners. If you are working with a Microsoft account manager, please let them know about your needs.

Q: I represent an identity provider that is not listed and I want to become qualified with the Works with Office 365-Identity program.

A: At this time there is a backlog associated with on-boarding new partners to this program. We are interested in hearing from you. However please expect a delayed response. Send email to idp@microsoft.com.

— Paul Andrew, @pndrw

Related Posts