我一直在阅读Vittorio Bertocci的博客，试图在MVC应用程序或WebApi服务中使用ADFS来管理身份验证和声明 . 看起来它变得非常平易近人 .
我现在正在尝试使用ADFS构建POC，以便为我们企业中的内部站点/服务执行常见的索赔解决方案 . 我们的用户将与我们的终端一起位于内部网络上 . 现在我们默认使用Windows Integrated身份验证，每个站点都会查找用户的姓名，电子邮件和其他AD详细信息，并通过IsInRole检查角色的声明主体 . 我们使用集成身份验证获得的声明仅包括SamIdentifier和一组组SID . 我希望ADFS为我们做这项工作，但仍然为我们的用户提供无挑战的体验 . 从长远来看，我们可能会在某些网站/服务上添加对非域加入设备的支持，这是探索ADFS的另一个动机 .
所以我在VS2013中使用组织帐户（On Premise）设置了一个简单的示例应用程序，它将转储当前用户的声明，配置元数据 endpoints 和受众uri，传达该信息以及我想要映射到我的声明ADFS admin（2012，btw），并将我的站点部署到开发服务器 . 所以我的主机仍然是IIS，虽然我希望使用Owin中间件来设置身份验证而不是web.config（WIF风格） .
鉴于IIS是我的主机，如何为我的站点配置身份验证：匿名？我的web.config应该为身份验证模式指定“None”并且deny =“？”授权，对吗？
另外一个问题我维托里奥没有在他关于内部部署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设置 . 基本上，当您选择组织帐户 - > On Premise时，我使解决方案看起来就像您从VS2013获得的解决方案 . 一切都很美妙，我所有配置的声明来自ADFS . 我看到最初的302重定向到ADFS，质询 - 响应，并最终将SAML令牌序列化为安全会话cookie . 在网站上，我回应了这样的说法：
var user = User as ClaimsPrincipal;
ViewBag.Claims = user.Claims;
return View();
这就是我怀疑中间件不完整的原因：当您在VS2013中使用该新模板时，向导会转到您指定的联合元数据 endpoints ，并通过读取该xml来构建所有web.config设置，此外，还会设置一些智能默认值 . 这就是我期望在Owin中间件中发生的事情 - 它应该拥有它需要知道的所有内容，因为我传入了相同的元数据 endpoints . 我希望使用FAM / SAM模块和所有附带的配置替换“魔术” .
2 回答
1）如果您正在配置Web UX应用程序，即要通过浏览器重定向使用的内容，您要使用http://www.cloudidentity.com/blog/2014/04/29/use-the-owin-security-components-in-asp-net-to-implement-web-sign-on-with-adfs/ . 在这种情况下，您会看到cookie中间件确实起作用 .
2）如果您正在配置Web API，如富客户端或其他服务器使用的内容，或者通常不是浏览器往返的任何内容，请参阅http://www.cloudidentity.com/blog/2013/10/25/securing-a-web-api-with-adfs-on-ws2012-r2-got-even-easier/ . 在这种情况下，您不需要cookie，因为没有会话 - 每次调用都必须携带令牌 .
HTH V.
正如Vittorio所说，如果你创建一个只有web api或web api的网页，你需要区分 . 按照他的博客文章，他们很棒！
如果您在IIS中托管仅限webapi的项目，则需要将身份验证设置为“表单身份验证” . 如果您的Web api包含在Web应用程序代理后面，这也适用 . 确保将 endpoints （已发布的Web应用程序）配置为不进行预身份验证 . “preauthenticate”的值应该是“通过” .
bg Andrej