sharepoint 概念及认证方式介绍

3.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 提供的网址 Web技术网（SharePoint），大大简化了我整理索引链接的难度：）这篇 SharePoint 2010管理中心创建Web应用程序和这篇 SharePoint2010管理中心管理Web应用程序可以作为创建、设置 SharePoint Web 应用程序的一个很好的开始。

2013-1-3 补充：上面这个网站链接已经打不开，我在博客园找了一篇类似的：SharePoint 2010 使用笔记（应用篇-管理中心-应用程序管理）。原来的 Web技术网内容不错，可惜不知道为什么打不开了。但那个网站也不是没有问题，最大的问题就是：罗列 SharePoint 功能，不讲应用。就好比教你所有 PhotoShop 的菜单命令，但是，你还是创作不出来绚丽的图片作品一样。

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

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

3.1身份验证方式

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

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

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

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

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

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

有本书讲这个主题的，叫做 A Guide to Claims-Based Identity and Access Control，原理讲得很好。不过，实际操作指南少，还得靠自己再去找。

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

微软有个帮助你规划应用的图 Design Sample: Corporate Portal with Claims-based Authentication。

配置 Form Based 身份验证： Sharepoint 2010 Form 身份认证的实现（基于SQL）和 Configuring Forms Based Authentication for SharePoint 2010 using IIS7。

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

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

不得不说的是，SharePoint 自己是不验证用户身份的，它依赖于其它的 IDM （IDentity Management）系统（如 AD、FBA 里面的数据库等等）。看得出来，SharePoint 甚至一开始都不打算存储用户的信息；不过，为了提高性能（不至于每次显示一个用户名还要去 IDM 里面兜一圈），SharePoint 还是存了一些用户信息的，叫做 User Profile。然后，有一个叫做 User Profile Service 的服务从 IDM 同步用户信息过来存到 SharePoint 管理数据库里面。
所以，你打开当的“我的设置”（My Settings）界面的时候，发现连你自己的邮件地址都不能改，就是因为这些是从外部同步而来，改了也会被覆盖掉。

3.2主机头、端口

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

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

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

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

3.4第一个内容数据库的名称

这个名称，其实无所谓，不重名即可。不过，我喜欢在 WSS_Content 后面加上 “_端口”，看上去好区分。
一个 Web Application 里面可以使用多个内容数据库，但是，一个网站集（site collection）只能存在于一个内容数据库中。你可以将不同内容的网站集放到不同的内容数据库，这样对于改进性能和提升管理水平很有帮助。SharePoint 2010 默认是把新创建的网站集放在最新创建的那个内容数据库中，这样显然是不方便的，在数据库之间移动网站集提供了按照我们本来的意思安排网站集和内容数据库的方法。

3.5关联的服务应用程序

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

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

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

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

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

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