【发布时间】：2014-12-11 20:37:22
【问题描述】：
我一直在阅读 Vittorio Bertocci 的博客，试图了解如何使用 ADFS 来管理 MVC 应用程序或 WebApi 服务中的身份验证和声明。看起来它变得非常平易近人了。
我现在正在尝试使用 ADFS 构建 POC，以便为我们企业中的内部站点/服务进行常见的索赔解决。我们的用户将与我们的端点一起在内部网络上。现在，我们默认使用 Windows 集成身份验证，每个站点都会查找用户的姓名、电子邮件和其他 AD 详细信息，并通过 IsInRole 检查声明主体的角色。我们通过集成身份验证获得的声明仅包括一个 SamIdentifier 和一堆组 SID。我希望 ADFS 为我们完成这项工作，但仍为我们的用户提供无挑战的体验。从长远来看，我们可能会在某些站点/服务上添加对未加入域的设备的支持，这是探索 ADFS 的另一个动机。
所以我在 VS2013 中使用组织帐户（本地）设置了一个简单的示例应用程序，它将转储当前用户的声明，配置元数据端点和受众 uri，将该信息与我想要的声明一起传达映射到我的 ADFS 管理员（2012 年，顺便说一句），并将我的站点部署到开发服务器。所以我的主机还是 IIS，虽然我希望使用 Owin 中间件来设置身份验证而不是 web.config（WIF 样式）。
鉴于 IIS 是我的主机，我如何为我的站点配置身份验证：匿名？我的 web.config 应该为身份验证模式指定“无”并拒绝 =“？”授权，对吗？
Vittorio 在他关于本地 adfs 的帖子中没有提到的另一个问题是不记名令牌的性质以及我们是否需要明确配置中间件以使用 cookie。我的启动配置现在看起来像这样：
public void ConfigureAuth(IAppBuilder app)
{
app.UseActiveDirectoryFederationServicesBearerAuthentication(
new ActiveDirectoryFederationServicesBearerAuthenticationOptions
{
MetadataEndpoint = ConfigurationManager.AppSettings["ida:AdfsMetadataEndpoint"],
TokenValidationParameters = new TokenValidationParameters() { ValidAudience = ConfigurationManager.AppSettings["ida:Audience"] }
});
}
看起来这个中间件需要 JWT 令牌（假设类上有一个 JwtSecurityTokenHandler）。我们需要在 ADFS 端进行任何配置来发布 JWT 令牌吗？我的理解是默认情况下我会收到一个 SAML 令牌。
我们应该期望使用 CookieAuthentication 中间件来管理令牌，还是浏览器会在会话的整个生命周期内继续包含它？
谢谢大家！
更新： 因此，基于 Vittorio 在下面的帮助和一些进一步的研究，我现在有一个简单的网站，其中只有一个页面受 [Authorize] 属性保护。我的启动类的 ConfigureAuth 方法现在看起来像这样：
public void ConfigureAuth(IAppBuilder app)
{
app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);
app.UseCookieAuthentication(new CookieAuthenticationOptions());
app.UseActiveDirectoryFederationServicesBearerAuthentication(
new ActiveDirectoryFederationServicesBearerAuthenticationOptions
{
MetadataEndpoint = ConfigurationManager.AppSettings["ida:AdfsMetadataEndpoint"],
TokenValidationParameters = new TokenValidationParameters() { ValidAudience = ConfigurationManager.AppSettings["ida:Audience"] }
});
}
我们已将我的网站添加为 ADFS 中的信赖方信任，并创建了六条声明规则。到目前为止，一切似乎都是正确的，但我仍在努力。我点击受保护的“声明”页面并获得带有 WWW-Authenticate:Bearer 标头的 401 响应。到目前为止，一切顺利。
但就是这样。浏览器如何知道在哪里进行身份验证并接收令牌？如果我要证明单独的客户端场景，我的客户端将配置令牌授权的位置，但在这个简单的网站场景中，我显然遗漏了一些东西。
更新 2： 我想知道本地 ADFS 的实施是否还没有准备好？或者文档可能还没有 - 或者两者兼而有之......
我取出所有 Owin 包并恢复使用 WSFederationAuthenticationModule 和 SessionAuthenticationModule 以及 system.identityModel 和 system-identityModel.services 中的所有 web.config 设置，这些设置已经存在了一段时间。基本上，当您选择组织帐户 --> 内部部署时，我使解决方案看起来像您从 VS2013 获得的解决方案。一切都很顺利，我所有的配置声明都来自 ADFS。我看到最初的 302 重定向到 ADFS、质询响应，并最终将 SAML 令牌序列化为安全会话 cookie。在网站上，我回应了这样的说法：
var user = User as ClaimsPrincipal;
ViewBag.Claims = user.Claims;
return View();
这就是我怀疑中间件不完整的原因：当您在 VS2013 中使用该新模板时，向导会转到您指定的联合元数据端点并通过读取该 xml 来构建所有 web.config 设置，此外，设置一些智能默认值。这就是我期望在 Owin 中间件中发生的事情——它应该有它需要知道的一切，因为我传入了相同的元数据端点。我希望“魔法”能够取代使用 FAM/SAM 模块和所有随附的配置。
【问题讨论】：
-
您是否尝试过从客户端的 cookie 中获取 Bearer 令牌（使用 javascript）并将其放入请求授权标头中？ (
Authorization: Bearer asdfghjkl)。我的印象是，您需要这样做才能从 javascript 客户端应用程序访问 API。 -
不使用 Owin 中间件。我仍然遇到的问题是网站（我的应用程序）没有响应未经授权的请求，并通过 302 重定向到在 startup.cs 代码中配置的 ADFS 端点。它只是返回一个 401。没有该重定向，所有客户端都必须知道首先去 ADFS 服务器获取令牌。
-
@Stuart，我的声明 var user = User as ClaimsPrincipal; 返回 null。所以我无法阅读索赔。我需要改变什么来阅读索赔？是否有明智的配置更改？
标签： authentication iis owin adfs