In this Ask the Admin, I’ll provide an overview of Active Directory Federation Services (ADFS) and how it can be used to simplify identity management.
Microsoft is big on identity-driven security, and its Federation Services component for Active Directory is now an integrated part of Windows Server. While trust relationships can be set up between AD domains and forests to allow sharing of network resources, ADFS provides secure sharing of identity information between federated business partners.
For example, if a user in Org A needs to access a web app hosted by Org B, Org A authenticates its own user. The user provides their credentials to Org A if no open browser session has authentication information for the user, and a signed XML-document containing the user’s email address or login name, or “claim” is sent back to Org B’s web app. The claim is then mapped to Org B’s trust policy to establish whether the user should be provided with authorized access to the app.
A federation trust is designed to enable efficient and secure online transactions between business partners over the public Internet. ADFS uses the standards-based WS-Federation protocol and SAML (Security Assertion Markup Language), and credentials are only exposed to the user’s local ADFS server. Because of the standards-based approach, ADFS can also be used with other federation platforms, such as IBM Tivoli, Novell Access manager, and Sun Open SSO.
The SAML protocol is designed for secure Internet communication, performing lightweight and secure communications across public networks that are separated by firewalls and NAT connections, making federated trusts more suitable for sharing identity information across public networks.
Cross-forest or domain AD trusts were designed for private networks that are directly connected to one another and require a secure channel to be permanently established between the trusted entities, but also enable a wider range of scenarios, allowing clients to access apps and resources in one or more trusted forests and domains.
When a user requests access to a web application, that request is forwarded to an identity provider, or in this case the user’s ADFS server. Because the web app has a federation trust established with the identity provider, it’s able to verify the authentication response and authorize access to the web app.
This technology is very common on the Internet; for example, when you use your Facebook account to sign in to a third-party website. Facebook acts as an identity provider, saving you having to create an account in each web app that you use on the Internet.
Expanding on the Facebook analogy, when an organization uses ADFS to enable single sign-on to Office 365, ADFS is acting as an identity provider for the organization. Office 365 works with ADFS to authenticate users, and the user’s password information never leaves the corporate intranet. Using ADFS as an identity provider means that accounts don’t need to set up and managed in a partner’s system, greatly reducing administrative effort.
ADFS can be deployed in scenarios in which single sign-on to web apps is required, and because ADFS uses the WS-Federation specification, it doesn’t matter if those sites are outside the corporate intranet and don’t the Windows identity model.
In an upcoming article on Petri, I’ll show you how to install and set up ADFS in Windows Server 2016.