Chinaunix首页 | 论坛 | 博客
  • 博客访问: 781156
  • 博文数量: 372
  • 博客积分: 10063
  • 博客等级: 中将
  • 技术积分: 4220
  • 用 户 组: 普通用户
  • 注册时间: 2012-02-24 11:36
文章分类

全部博文(372)

文章存档

2012年(372)

分类: 虚拟化

2012-03-27 17:27:48

SharePoint Web 应用程序

我个人的理解,SharePoint Web 应用程序(SharePoint Web Application)代表的是 SharePoint 网站(集)的物理容器。

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

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

imageimage

上面第一张图,如果是将 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 以前的版本在与其整合应用的时候,会有一个二次登录的问题。(似乎问题是卡在身份验证服务器提供的登录转向页面上,不过我尚未深入研究)

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

image

配置 Form Based 身份验证: Sharepoint 2010 Form 身份认证的实现(基于SQL) 和 。

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

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

image

主机头、端口

你想弄一个 这样的网站的话,就指定主机头值。但是,按照我的印象,还是在 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,其它的技术平台都应该会有这个问题。

阅读(794) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~