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，其它的技术平台都应该会有这个问题。