Active Directory Federation Services与IIS的区别及ADFS独立访问权限咨询

Great question! Let’s break this down clearly because even though both touch web access, ADFS and IIS serve entirely different roles.

Core Differences Between ADFS and IIS #

First, let’s get their core purposes straight:

• IIS (Internet Information Services): The Web Host
  • IIS is a full-fledged web server. Its main job is to host, serve, and manage web content—think websites, ASP.NET applications, REST APIs, static HTML files, etc. It handles incoming HTTP/HTTPS requests, processes them (like running server-side code), and sends back content to the user’s browser.
  • While IIS can handle basic authentication (Windows Auth, Forms Auth, etc.), this is only for the content it hosts. It’s focused on delivering web content securely, not managing cross-app identity.
• ADFS (Active Directory Federation Services): The Identity Broker
  • ADFS has nothing to do with hosting web content. It’s an identity federation service built to handle cross-organization, cross-application authentication and single sign-on (SSO).
  • Its core job is to verify a user’s identity (usually via an Active Directory domain) and issue trusted security tokens that other applications can use to grant access. It acts as a middleman between users and apps, so users don’t have to log in separately to every service they use.

Functional Differences for Web App Access #

Let’s tie this to your use case of web app access:

• Using IIS for web app access:
  • When you access an app hosted on IIS, IIS itself handles authentication (if enabled) by checking credentials against a local or AD domain. This authentication is tied directly to the specific app hosted on that IIS instance.
  • Without extra configuration, users might need to log in separately for each app hosted on IIS—there’s no built-in cross-app SSO here.
• Using ADFS for web app access:
  • ADFS decouples authentication from the app. Users first log into ADFS (using their AD credentials), and ADFS issues a token. The user can then present this token to any app that’s integrated with ADFS (whether it’s hosted on IIS, a cloud service like Office 365, or a third-party tool).
  • This enables true SSO: one login, access to all authorized apps. The app doesn’t need to store or validate user credentials—it just trusts the token issued by ADFS.

What Can You Access After Logging Into ADFS (Without a Specific App)? #

ADFS itself doesn’t host any end-user content, so there’s no "default" content to browse after logging in. That said:

• If your organization has configured an ADFS Application Portal (sometimes called a "My Apps" portal), you’ll see a list of all web apps, cloud services, and on-prem tools you’re authorized to access. You can click any of these to launch them without re-authenticating.
• You can access ADFS’s metadata endpoints (like https://your-adfs-server/FederationMetadata/2007-06/FederationMetadata.xml), but this is technical data for developers to configure app integrations, not user-facing content.
• In short: ADFS’s value post-login is the ability to seamlessly access all your authorized apps, not content hosted by ADFS itself.

内容的提问来源于stack exchange，提问作者Bodhi