平安企业搜索技术方案爬网权限部分.docx
- 文档编号:27254959
- 上传时间:2023-06-28
- 格式:DOCX
- 页数:27
- 大小:582.73KB
平安企业搜索技术方案爬网权限部分.docx
《平安企业搜索技术方案爬网权限部分.docx》由会员分享,可在线阅读,更多相关《平安企业搜索技术方案爬网权限部分.docx(27页珍藏版)》请在冰豆网上搜索。
平安企业搜索技术方案爬网权限部分
平安企业搜索技术方案
内容爬网&权限控制部分
Preparedfor
平安保险公司
Version1.0.0
Preparedby
微软(中国)有限公司
2008年03月06日
修订和评审记录
修订记录
Date
Author
Version
Changereference
2008-03-06
林柏
0.9.0
创建文档
2008-03-30
林柏
1.0.0
添加EOA权限分析、各子系统搜索方案设计
评审记录
Name
Versionapproved
Position
Date
目录
第1章概述1
1.1文档目的1
1.2总体需求及方案1
1.3企业搜索架构概述2
第2章需求分析3
2.1内容爬网需求分析3
2.1.1.集成搜索的业务系统3
2.1.2.档案系统内容源分析4
2.2权限控制需求分析5
2.2.1.档案系统权限分析5
2.2.2.EOA系统权限分析7
第3章内容爬网方案10
3.1SharePoint内容爬网10
3.2自定义ProtocolHandler&IFilter10
3.3WebAdapter连接内容源+ZIP13
3.3.1.WebAdapter13
3.3.2.Zipfile13
第4章权限控制方案15
4.1SharePoint权限控制15
4.1.1默认的安全过滤15
4.1.2自定义SecurityTrimmer15
4.2映射到ACL16
4.2.1Mapping16
4.2.2同步权限设置的修改17
4.3SQLQuery使用where<权限条件>18
4.3.1爬网内容项的权限信息18
4.3.2在SQL中嵌入权限查询条件19
4.3.3局限性19
第5章各系统搜索方案设计21
5.1档案管理系统21
5.1.1内容爬网21
5.1.2权限控制21
5.2EOA系统22
5.2.1内容爬网22
5.2.2权限控制22
第6章综合考虑23
5.1内容爬网23
5.2权限控制23
第1章概述
1.1文档目的
本文档阐述微软企业服务部(以下简称:
微软)对平安集团(以下简称:
平安)企业搜索平台建设的需求理解,并在此基础上提出企业搜索平台建设过程中的建议、技术解决方案。
1.2总体需求及方案
平安企业搜索的需求总体上分为部分:
1)搜索引擎平台架构设计;
2)集成搜索业务系统数据和内容。
依据对总体及详细需求的分析,微软提供的技术方案由以下各部分组成:
1)内容爬网设计方案;
2)权限控制设计方案;
3)后台管理定制与扩展设计方案;
4)用户搜索界面定制与扩展设计方案;
5)单点登陆(SSO)设计方案;
6)部署设计方案;
本文档重点阐述“内容爬网”及“权限控制”设计方案,该部分是系统的核心关键。
其他部分的设计方案的详细内容,包括系统可靠性设计、备份与恢复、扩展性设计及规范,以及项目实施计划,项目管理原则与质量保障等,将参考《平安企业搜索平台技术方案.doc》。
1.3企业搜索架构概述
本方案基于MicrosoftOfficeSharePointServer2007的EnterpriseSearch,系统架构如下图所示:
企业搜索架构图
企业搜索架构上由两部分组件组成:
1)索引引擎(IndexEngine)
索引引擎需要根据内容源定义,爬网访问内容项(如:
文件、网页、邮件等),并抽取内容、使用分词组件(Wordbreaker)把原文分解为词或段落,并存储于内容索引(ContentIndex)中;另外,文档的属性在爬网中也被抽取并存储。
2)查询引擎(QueryEngine)
当用户提交搜索关键字时,查询引擎同样使用分词组件(Wordbreaker)把查询条件分解为词或段落,并在内容索应中查询匹配的项,并返回该项文档及文档的属性,权限检查在此时被触发,未满足访问权限的文档将被过滤。
第2章需求分析
2.1内容爬网需求分析
2.1.1.集成搜索的业务系统
平安企业搜索平台需要集成搜索的系统包括:
1)档案管理系统
结构化的数据内容存储于Oracle数据库中的表:
ARCHIVE_ITEM_DESCRIPTION(档案项目信息表)
ARCHIVE_CONTENT_INFO(案卷目录信息表)
ARCHIVE_DESCRIPTION_INFO(卷内文件目录信息表)
另外,文档附件存储于Filenet。
2)EOA系统
信息结构与档案管理系统类似,需要搜索数据库中结构化的数据和外部关联的文档文件。
3)公文公告系统
结构化的数据存储于数据库中,主要来源于以下几张表RFS_COT、RFS_PERMISSION、RFS_PURSPEC、PAWEB_FILES;
文档存储于Sharepoint2003的文档库中。
4)PWS网站内容搜索
PWS网站搜索是指在HTTP:
//PWS.PAIC.COM.CN页面上的搜索入口,一个SharePoint站点。
5)更多的业务系统内容源…
平安企业搜索内容源
2.1.2.档案系统内容源分析
档案系统的结构化的数据存储于Oracle数据库中的表:
ARCHIVE_ITEM_DESCRIPTION(档案项目信息表)
ARCHIVE_CONTENT_INFO(案卷目录信息表)
ARCHIVE_DESCRIPTION_INFO(卷内文件目录信息表)
文档附件存储于Filenet。
结构化数据和文档的关联关系如下图所示:
档案系统内容源分析
该内容源描述如下:
1)ARCHIVE_ITEM_DESCRIPTION.ITEM_SEQ_NO(项目号)是档案的唯一标识,<档案类型>、<全宗号>是档案的属性。
2)ARCHIVE_COTENT_INFO表中存储档案内容的概述信息;
3)档案的附件信息存储于ARCHIVE_ATTACHED_FILES表,一个档案可以有多个附件(一对多关系)。
4)ARCHIVE_ATTACHED_FILES表中的URL,指向最终的附件文档。
在档案系统业务中,认为(结构化数据+附件文档)是一个档案的完整内容,其权限模型也是设置于ITEM_SEQ_NO(项目号)之上。
对于爬网过程,必须把(结构化数据+附件)作为一个内容项(ContentItem)来爬取内容。
2.2权限控制需求分析
2.2.1.档案系统权限分析
档案系统中权限设置界面如下:
(摘自《微软顾问服务需求》)
对于集成搜索,只要有对档案的任何操作权限,都认为有查看权限。
档案系统可以对用户设置权限,也可以对角色设置权限,用户可以隶属于多个角色。
最终的权限是一个并集。
对应于操作界面,权限在数据库中的存储模型如下:
(摘自《相关信息表》平安企业搜索平台)
基于该权限设置,当用户登录系统后,可以获得用户被授予的权限。
在查看档案信息时,会根据档案的类型、全宗号、用户所在机构编码、权限集判断用户是否有权限。
如:
深圳:
0-K46
当用户有0机构操作权限时,深圳用户可以操作全宗号是K46的文件。
上海:
0–K45
当用户有0机构操作权限时,上海用户可以操作全宗号是K45的文件。
“全宗号”可以根据“机构编码”按规则转换而成。
分析档案系统的权限关系,可以按以下的权限数据结构理解:
档案系统权限关系分析
对档案系统的权限分析如下:
1)档案按部门结构一层层组织归类,类似于<文件夹/文件/子文件夹>树状结构;
2)用户同样按部门结构一层层组织;
3)业务规则上用户可以看本机构级别的文件或下级机构的文件;
4)用户最终能否查看什么档案,由其权限集合定义:
用户权限定义
档案类型
本机构
下级机构
合同档案
√
会计档案
√
√
…
…
…
2.2.2.EOA系统权限分析
EOA系统的权限控制分为两类:
1)签报流程涉及的人员(申请人、审批人、秘书、委托人)可以查看该签报。
如下图所示:
该权限信息的关系模型如下:
2)对于固定流程,可以指定人员和部门,该人员或部门也有权限查看由该固定流程模板生成的签报流程,即使不在流程链上。
该权限信息的关系模型如下:
第3章内容爬网方案
3.1SharePoint内容爬网
Sharepoint内置支持5种类型的内容源:
1)SharePoint类型的站点;
2)Web站点
3)文件共享
4)Exchange邮件服务器的共享文件夹
5)业务数据,存储于关系型数据库中,如SQLServer或Oracle等。
3.2自定义ProtocolHandler&IFilter
根据对档案系统的内容源分析,不属于内置支持的5种内容源类型。
SharePoint中定义了标准接口,可以扩展支持自定义的内容源,其IndexEngine的架构如下:
自定义ProtocolHandler&Ifilter是扩展SharePointSearch内容源的默认方式。
ProtocolHandler
对于档案管理系统内容源,自定义的ProtocolHandler,可以以编程的方式访问数据库中的结构化数据和Filenet中的附件文档,并调用自定义的IFilter,分析抽取其中的内容。
同时,实现IUrlAccess.GetSecurity()接口,可以返回内容项的权限信息(基于ACL)。
IFilter
由于需要把<结构化数据+附件文档>作为一个内容项(ContentItem),因此需要合并结构化数据中的档案属性和附件属性,并调用已存在的Filter如.docFilter抽取附件的内容。
同时,可以把档案的权限信息作为属性返回,在爬网的过程中爬取权限信息,并存储到IndexServer的PropertyBag中,备查询时权限过滤使用。
自定义ProtocolHandler&IFilter需要实现以下接口:
ISearchProtocol
[
uuid(c73106ba-ac80-11d1-8df3-00c04fb6ef4f),
]
interfaceISearchProtocol:
IUnknown
{
HRESULTInit([in]TIMEOUT_INFO*pTimeoutInfo,
[in]IProtocolHandlerSite*pProtocolHandlerSite,
[in]PROXY_INFO*pProxyInfo);
HRESULTCreateAccessor([in]LPCWSTRpcwszURL,
[in]AUTHENTICATION_INFO*pAuthenticationInfo,
[in]INCREMENTAL_ACCESS_INFO*pIncrementalAccessInfo,
[in]ITEM_INFO*pItemInfo,
[out]IUrlAccessor**ppAccessor);
HRESULTCloseAccessor([in]IUrlAccessor*pAccessor);
}
IUrlAccessor
[
uuid(0b63e318-9ccc-11d0-bcdb-00805fccce04),
]
interfaceIUrlAccessor:
IUnknown
{
…
HRESULTGetDocFormat([out,length_is(*pdwLength),size_is(dwSize)]WCHARwszDocFormat[],
[in]DWORDdwSize,
[out]DWORD*pdwLength);
HRESULTGetLastModified([out]FILETIME*pftLastModified);
HRESULTGetSecurityDescriptor([out,size_is(dwSize)]BYTE*pSD,
[in]DWORDdwSize,
[out]DWORD*pdwLength);
…
HRESULTBindToStream([out]IStream**ppStream);
HRESULTBindToFilter([out]IFilter**ppFilter);
};
IFilter
[
uuid(89BCB740-6119-101A-BCB7-00DD010655AF),
]
interfaceIFilter:
IUnknown
{
SCODEInit([in]ULONGgrfFlags,
[in]ULONGcAttributes,
[in,size_is(cAttributes)]FULLPROPSPECconst*aAttributes,
[out]ULONG*pFlags);
SCODEGetChunk([out]STAT_CHUNK*pStat);
SCODEGetText([in,out]ULONG*pcwcBuffer,
[out,size_is(*pcwcBuffer)]WCHAR*awcBuffer);
SCODEGetValue([out]PROPVARIANT**ppPropValue);
}
3.3WebAdapter连接内容源+ZIP
3.3.1.WebAdapter
另外一种爬取档案系统内容源的方式可以采用“WebAdapter”,其工作原理如下图所示:
创建“WebAdapter”动态页面,动态页面中读取Oracle数据库中的结构化数据和Filenet总的附件文档;IndexEngine添加Web内容源。
使用WebAdapter,把档案系统的内容源转换为动态Web内容源,而SharePoint内置支持Web内容源的爬网。
使用动态Web内容源地好处是避免开发复杂的ProtocolHandler和IFilter,并且只有在Http请求时才动态生成内容,无需复制全部的内容。
3.3.2.Zipfile
档案系统需要把(结构化数据+附件文档)作为一个内容源,因此,可以巧妙的利用.zip压缩文件的特性,满足要求:
1)把数据库中结构化的数据转换为XML文件;
2)把附件文档和XML文档压缩为ZIP文件。
当SharePoint爬网Web站点时,根据参数返回ZIP文件给IndexEngine。
SharePoint需要安装.zip文件格式的Filter组件,从而可以抽取ZIP文件的内容。
第4章权限控制方案
4.1SharePoint权限控制
4.1.1默认的安全过滤
SharePointIndexEngine在内容爬网的过程中,ProtocolHandler会抽取内容项的安全信息(SecurityDescriptor),并把并把该信息存储到内容索引(ContentIndex)中。
该安全信息基于WindowsACL。
默认情况下,搜索的结果会在查询返回时进行访问权限检查。
根据关键字返回搜索结果时,查询引擎根据当前的登录用户身份,对每个内容项的SecurityDescriptor进行判断,没有查看权限的内容项将被过滤,最后返回结果给用户。
例如,对于Windows文件,其SecurityDescriptor如下图所示:
4.1.2自定义SecurityTrimmer
SharePoint企业搜索可以扩展定义SecurityTrimmer,允许您在查询时,根据自定义的业务规则过滤返回的搜索结果。
在爬网时,需要爬取与权限相关的信息。
例如,对于档案系统,需要爬去“全宗号”和“档案类型”属性;在查询时,根据当前用户在业务系统中的权限设置,对每个内容项进行访问检查。
定义SecurityTrimmer需要实现以下接口:
publicinterfaceISecurityTrimmer
在CheckAccess方法中逐一判断每一个URL,最后返回一个是否允许访问的数组。
publicBitArrayCheckAccess(IList
{
//CheckAccessmethodimplementation}
}
由于该机制需要枚举每一个搜索结果,因此在性能上会有所影响,通常建议设置返回结果限制,避免用户长时间等待。
4.2映射到ACL
4.2.1Mapping
要使用SharePoint默认的地权限过滤机制,必须把应用系统的权限模型影射到基于WindowsACL的权限模型。
对于档案系统,其影射关系如下图所示:
文件夹及其允许访问的用户组的对应关系如下表:
文件夹
允许访问的用户组
合同档案\[0]平安集团\[046]深圳\本级文件
[046]用户组
合同档案\[0]平安集团\下级机构
[0]下级用户组
合同档案\[0]平安集团\下级机构\[1]寿险总公司\本级文件
[1]用户组
合同档案\[0]平安集团\下级机构\[1]寿险总公司\下级机构
[1]下级用户组
合同档案\[0]平安集团\下级机构\[1]寿险总公司\下级机构\
\[101]寿险北京分公司\本级文件
[101]用户组
如果User1是深圳用户,又希望有权限查看下级机构的档案,把User1添加到[046]用户组和[0]下级用户组。
由于文件的ACL继承文件夹级上级文件夹的ACL,以“寿险公司北京分公司”目录下的“P101.doc”文件为例,其SecurityDescriptor中的ACL表达如下:
P101.DOC文件的ACL
[0]下级用户组
[1]下级用户组
[101]用户组
结合WebAdapter方案,在爬网过程中返回zip文件之前,可以先设置该文件的ACL。
4.2.2同步权限设置的修改
当应用程序中的权限设置修改后,权限信息需要同步。
由于文件中的ACL都是设置为与用户组关联,被没有直接与用户关联,因此,只需要在AD中修改用户所属的用户组即可。
不需要重新爬网该内容项,权限修改就可以生效。
例如,设置User1没有查看下级机构的权限,从“[0]下级用户组”删除user1即可。
4.3SQLQuery使用where<权限条件>
OfficeSharePointServer2007企业搜索提供FulltextSQ语法支持复杂搜索条件,例如:
SELECTrank,title,path,authorfromScope()WHERE
Freetext(title,'Keyword)
对于档案系统的权限控制,需要在where子句中嵌入权限过滤条件:
SELECTrank,title,path,authorfromScope()WHERE
Freetext('Keyword')AND全宗号=”K46”
要使用该SQL语法签入权限过滤条件,需要以下几个步骤:
1)爬取内容源的权限信息,如“全宗号”、“档案类型”,使其成为“CrawledProperty”;
2)创建ManagedProperty,影射到CrawledProperty。
ManagedProperty就可以嵌入到FullTextSQL语句中。
4.3.1爬网内容项的权限信息
对于档案系统,需要爬取内容源的权限信息,如“全宗号”、“档案类型”,使其成为“CrawledProperty”。
在内容爬网设计中,WebAdapter把数据库中的结构化数据转化为XML:
需要把权限信息导出到XML文件,如:
xmlversion="1.0"encoding="utf-8"?
>
SEQ_NO="123456" FONDS_NO="K46" ARCHIVE_TYPE="合同档案" ... > archivedescriptionhere...
IndexEngine在爬网时,可以把它处理为“CrawledProperty”:
4.3.2在SQL中嵌入权限查询条件
爬取到权限信息后,把它Mapping到ManagedProperty:
用户登录时,可以获取用户在档案系统中的机构信息和部门信息,把机构信息或部门信息按规则转换为全宗号,如:
K46,动态构造SQL语句如下:
SELECTrank,title,path,authorfromScope()WHERE
Freetext('Keyword')ANDFONDSNO=”K46”
使用SQL语句实现了权限过滤。
4.3.3局限性
对于档案系统,完整的权限控制条件需要添加“档案类型”过滤条件。
对于当前登录用户,其查看本级机构的档案类型列表可以通过以下T-SQL获得:
SELECTArchiveTypeFROMUserPermissionsWHERE
Username=’username’ANDOrg_allowed=1
完整的搜索查询SQL语句含义表达如下:
SELECTrank,title,path,authorfromScope()WHERE
Freetext('Keyword')
ANDFONDSNO=’K46’
ANDARCHIVETYPEIN(
SELECTArchiveTypeFROMUserPermissionsWHERE
Username=’username’ANDOrg_allowed=1
)
但是,FullTextSQL并不等于T-SQL,它不支持子查询,In等语法,因此上面的语句必须写成:
SELECTrank,title,path,authorfromScope()WHERE
Freetext('Keyword')
ANDFONDSNO=’K46’
AND(ARCHIVETYPE=‘合同档案’
ORARCHIVETYPE=‘会计档案’
…)
因此,必须根据业务需求作预处理,适当简化查询时的权限控制逻辑。
第5章各系统搜索方案设计
5.1档案管理系统
5.1.1内容爬网
对于档案管理系统,由于需要搜索的内容存储于数据库和文档中并有关联,建议采用WebAdapter+Zip的方式爬网内容源,其ZIP文件的内容如下图所示:
5.1.2权限控制
建议采用“在SQLQuery中嵌入where<权限条件>”的方式进行权限控制。
因此,需要把档案的权限
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 平安 企业 搜索 技术 方案 权限 部分
![提示](https://static.bdocx.com/images/bang_tan.gif)