SharePoint 2013 开发——APP安全模型

最新推荐文章于 2021-01-21 22:21:23 发布

Justin-Liu

最新推荐文章于 2021-01-21 22:21:23 发布

阅读量2.3k

点赞数 2

本文链接：https://blog.csdn.net/foxdave/article/details/46045411

版权

SharePoint 2013 Development 同时被 2 个专栏收录

26 篇文章 0 订阅

订阅专栏

SharePoint 2013 开发

14 篇文章 4 订阅

订阅专栏

博客地址：http://blog.csdn.net/FoxDave

除非开启了SharePoint网站的匿名访问，否则对于入站的请求，必须要有一个身份验证的过程（Authentication），这个很重要。

SharePoint身份验证依赖于目录服务（如AD、identity providers（IdPs）像Google和Facebook），服务（如IIS、Azure Access Contro Service（ACS），以及Active Directory Services（ADFS）来实现它的身份验证业务逻辑。

基于编程模型的改变，SharePoint 2013需要处理两种类型的认证：用户认证和APP认证。对于用户认证，SharePoint使用安全组和存储在内容数据库中的Access Control List（ACL）来跟踪，但是对于APP，SharePoint使用了另一种方式。APP的认证通过ACS来提供给SharePoint，叫做OAuth（OAuth 2.0是OAuth的下一个版本，需要HTTPS）。这种架构使得用户可以授权APP去代表他们工作而不需要保存他们的凭据信息。

当SharePoint收到一个入站请求时，会检查请求中是否包含标识用户身份的登录令牌，如果找到该令牌，SharePoint就假定该请求是由通过验证的用户发出的而不是APP。然后SharePoint会检查请求的目标URL指向的是一个标准的网站还是与APP有关系的子网站（APPWeb）。如果该请求指向了一个标准的网站，那么SharePoint 2013会遵循之前版本典型的认证过程；如果是与APP相关的话，则会初始化一个包含用户认证和APP认证的上下文（context）。

如果没有找到登录令牌，SharePoint就知道这不是用户发起的请求。在这种情况下，SharePoint会寻找OAuth令牌来识别远程应用。当找到安全令牌之后，它会创建包含APP认证和用户认证（可选）的上下文。

身份认证（Authentication）之后再来看授权（Authorization）。上下文创建之后，SharePoint会决定授予APP什么样的权限，跟用户权限一样，SharePoint通过自身的内部内容数据库来跟踪授权。

具体的认证授权流可参加下图，更多信息。

每个APP都有一个manifest.xml清单文件，开发人员可以在这里通过AppPermissionRequests节点来定义APP需要访问的资源列表，下面的代码片段提供了一个示例（provider-hosted APP）：

<AppPermissionRequests AllowAppOnlyPolicy="true">
  <AppPermissionRequest Scope="http://sharepoint/content/sitecollection"   Right="Read"/>
  <AppPermissionRequest Scope="http://sharepoint/content/sitecollection/web/list"   Right="Write">
    <Property Name="BaseTemplateId" Value="101"/>
  </AppPermissionRequest>
  <AppPermissionRequest Scope="http://sharepoint/userprofilestore/feed"   Right="Post"/>
  <AppPermissionRequest Scope="http://exchange/calendars" Right="Schedule"/>
</AppPermissionRequests>

注意这里面的第一行，APP的权限请求启用了app-only策略，它意味着只有APP（没有当前用户）需要必要的权限。如果没有使用该策略，则表示APP和当前用户都需要必要的权限来完成任务如访问整个网站集或在列表中创建项目，这会使上下文同时包含APP和用户的身份。

app-only策略可以提高APP的权限，使得它可以比当前用户做更多的事。当用户安装包含AppPermissionRequest条目的APP时，该用户必须在安装时授予APP清单中声明的权限。

ACS不能在本地部署的非Office 365环境中使用，意味着本地部署也没有OAuth令牌。本地APP需要使用一种不同的安全令牌，该令牌由Server-to-Server（S2S）配置创建，更多信息。

关于APP的安全，我们还应该知道以下事情：

APP运行在它们自己的域内（防止跨网站脚本攻击），用JavaScript编写，但这并不意味着它们是安全的。作为开发人员，仍需考虑因为APP的设计导致的安全漏洞和敏感信息泄漏的问题。

SharePoint-hosted APP没有指定列表或网站级别的授权，换句话说，如果一个APP对一个列表有写入权限，它对另一个列表也有。

当用户为provider-hosted APP授权的时候，这是一个一次性过程，即使之后APP的逻辑代码改变了，SharePoint对此也并不知情。

当APP使用OAuth令牌来完成一些任务时，页面上另一个APP也可以使用该APP的身份和用户的身份。在这种情况下，黑客可以通过不安全的通信协议（HTTP）来拦截OAuth令牌。

所以，我们在开发APP时，需要用心设计并尽量使用HTTPS来加密通信协议。