发布时间 : 星期一 文章asp.netwebapi更新完毕开始阅读7c1be5ecc67da26925c52cc58bd63186bdeb9261
ASP.NET Web API
ASP.NET Web API
具有 Windows Azure AD 和 Microsoft OWIN 组件的安全 ASP.NET Web APIVittorio Bertocci随着 Web API 角色的重要性日益增加，在可能暴露敏感数据和操作的高价值方案中确保能够信心十足地使用 Web API 的需求也愈加迫切。
我们可以清楚地看到，整个行业都在寻找一种解决方案，以便为依赖 OAuth 2.0 标准的 REST API 提供保护。 但在实践中，关于应该在项目层面上做些什么，并没有提供详细的指导。
此外，Microsoft .NET Framework 中用于保护通信的现有类和工具设计用于特定应用程序类型（基于回发的 Web UX 应用程序）。
它们不适用于 Web API 及其支持的多客户端方案。 因此，保护 Web API 的工作在相当程度上已成为一种手工活动。
这些保护工作不见得不安全，但各解决方案之间的差异很大，
需要过多的自定义代码。
随着 Visual Studio 2013 的发布，您可以将这些烦恼全都抛诸脑后。
此版本引入了来自 Microsoft Open Web Interface for .NET (OWIN) 组件的创新 ASP.NET 工具和安全中间件，它们可为您的 Web API 提供直接的保护。
通过新型 ASP.NET 工具和模板，您可以对 Web API 项目进行配置，使之将身份验证直接外包给 Windows Azure Active Directory (AD)，从而发出本地项目和 Windows Azure AD 相应条目中的必要代码。
在本文中，我将向大家介绍如何利用 Visual Studio 2013 的这些新功能创建受 Windows Azure AD 保护的简单 Web API。
我还将向大家展示如何创建一个测试用客户端，从而演示实际使用中的 API。
我还将简单探讨一下后台情况，如果您想要更深入探究此方案的更高级方面，可将其作为起点。
请提供凭据
归根结底，身份验证的功能是在调用方向服务器发送消息时，要求调用方提供可验证其身份或检索其属性的某种凭据。 服务器随后使用这些信息进行授权：确定是否应授予访问权限，以及在哪些方面授予访问权限。
资源通常将大部分身份验证功能转移给外部服务提供商，通常称为颁发机构或身份提供者。
这些提供者负责繁重的任务，例如让用户登录、分配凭据、处理生命周期流程（如密码恢复）、提供用于用户身份验证的 UI、验证多个协议上的凭据、多身份验证因素管理、欺诈检测等。
将这些功能放到一边，剩下的唯一身份验证任务是确认身份验证是否在所选颁发机构成功通过。
此项工作通常涉及对安全令牌的检查，安全令牌是身份验证成功后颁发机构向调用方发放的数据片段。
安全令牌通常根据特定的格式创建，由将明确识别颁发机构的密钥进行数字签名，并且包含一些将此令牌唯一绑定到目标资源的数据。
资源在收到请求时，会寻找随附的令牌。
如果发现一个符合所需验证属性的令牌，调用方即通过身份验证。
在这一详细级别上，此模式通用性很高，以致于其能够描述许多不同的身份验证方法。
我将通过为具体实体分配高级角色将其应用于此方案。
资源 资源将是我需要保护的 ASP.NET Web API 2 项目。 您可以在更细的粒度上应用身份验证要求。
例如，您可以定义操作的子集来进行保护，并让其他操作接受匿名调用方。
颁发机构 我将对 Web API 进行配置，使之将身份验证需求