SharePoint Web 应用程序

SharePoint Web 应用程序

我个人的理解，SharePoint Web 应用程序（SharePoint Web Application）代表的是 SharePoint 网站（集）的物理容器。

SharePoint Web 应用程序需要制定内容数据库、宿主 IIS 应用程序池、应用程序池管理员账号等信息，这些都是 SharePoint 网站（集）的物理容器属性。从这以后（网站集，网站，列表。。。）都是在数据库里面操作，是为逻辑容器。（姑且让我这么区分吧）

所以，像下面这样解释 Web Application 和 Site Collection, Web Site 之间的关系就是比较准确的了：

和

上面第一张图，如果是将 Web Application 画进 Site Collection 那个方框中了，就有点问题了。

顺便说一句，上面图形中只是描述这些对象之间的逻辑关系，并不意味着必须按照这个关系路径来访问这个关系树中的枝叶。你可以直接访问某个列表（List）而无需列表所在站点的访问权限。所以，对于打破了继承关系的这些对象来说，其权限其实是扁平的，并无树状继承一说。

配置 SharePoint Web 应用程序，并不是一件简单的事情。

感谢 lxrc4561200 提供的网址 ，大大简化了我整理索引链接的难度：） 这篇 和这篇 可以作为创建、设置 SharePoint Web 应用程序的一个很好的开始。

毫无疑问，创建新的 SharePoint Web 应用程序的时候，全部接受默认的选项也是可以的。

或者，你也可以面对这么多选项，做出很多“艰难”的决策来对 SharePoint 做更多的了解。

身份验证方式

有“经典”和“基于声明”的两种。

“经典”的里面，又可以选身份验证提供程序：NTML 或者 Kerberos。

“基于声明”的就更多了。

有人用 IIS 对“经典”的身份验证做了测试 IIS的各种身份验证详细测试，不过，有点儿含糊的感觉，图少，另外有图解版的，可以对照着看 Windows安全认证是如何进行的？[NTLM篇]、Windows安全认证是如何进行的？[Kerberos篇]。

NTLM 无须额外的配置即可使用，所以，一般体验和个人研究都选择它。

“基于声明”的，原理和 Kerberos 的有点儿像，都引入了 Token Issuer 的角色（SharePoint 拿到验证 Token，还要用 Security Token Service 再转换一次才能使用）。不同的是，声明 Claims 引入了证书签名加密、基于 SAML 协议，适用于非 Windows 系统的互信授权，从而可以跨过企业间的异构界限，实现联合身份验证 Federation。Form Based 身份验证也划入了“基于声明”的行列。

有本书讲这个主题的，叫做 ，原理讲得很好。不过，实际操作指南少，还得靠自己再去找。

再顺便说一句，因为“基于声明”的验证方式出现较晚，Microsoft Office 2010 以前的版本在与其整合应用的时候，会有一个二次登录的问题。（似乎问题是卡在身份验证服务器提供的登录转向页面上，不过我尚未深入研究）

微软有个帮助你规划应用的图 。

配置 Form Based 身份验证： Sharepoint 2010 Form 身份认证的实现（基于SQL） 和 。

配置 Federation 身份验证：端对端配置 SharePoint 2010 和 ADFS v2 版本。配置到最后，会用到配置“信任”：。

SharePoint 2010 无须扩展应用程序即可同时支持以上这些身份验证方式并存，麻烦的是，登录时会多出来一个选择验证方式的界面。当然，这很“讨厌”，于是有人看不下去了，Multiple Authentication Methods in SharePoint 2010、SharePoint 2010: transparent login with mixed authentication。

主机头、端口

你想弄一个 这样的网站的话，就指定主机头值。但是，按照我的印象，还是在 SharePoint2010更改网站的URL(1)、SharePoint2010更改网站的URL(2) 里面设置更加方便。

端口，别和默认端口（21 什么的）冲突即可。HTTPS 协议默认 443 端口，如果已经占用了，就换别的。不想换？！那就申请通配符证书吧。

IIS 应用程序池及其管理账户

建议挑一个非域管理员、非本机管理员的账号试试，会很好玩的。用这个账号登录网站，就会显示“系统账户”或者“System Account”。

第一个内容数据库的名称

这个名称，其实无所谓，不重名即可。不过，我喜欢在 WSS_Content 后面加上 “_端口”，看上去好区分。

关联的服务应用程序

即 SharePoint Service Application，姑且可以看做是 SharePoint 的 Web 版公共程序库，提供各种服务供各个 Web 应用调用。

没把握的话，全部选上，否则在学习、测试的时候会有各种各样的错误。

熟悉的话，你就麻烦了，这里又牵涉到一个服务应用程序规划的问题，取决于服务器场中每台 SharePoint Instance 的角色定位问题。

微软有个图可以帮助你决定（当然，你也可以被这个图扰乱），到底要怎么样分配 SharePoint Web 应用程序关联的服务应用程序 。单机环境玩不了这个 ：（

上面这些决策，显然不是（纯）程序员或者网站管理员、网站用户应该（以及能够）考虑的，这些明显是给另外一拨人去思考的。所以呢，单枪匹马的搞 SharePoint 项目的时代，不说已经过去，大概从来就没有到来过吧。

这些问题，个人在单机上面搞研究是不会遇到的，所以，弄个拟真的环境很有必要（见本文第一篇里面关于 安装和配置 的部分）。不仅仅是 SharePoint，其它的技术平台都应该会有这个问题。