xx电信ad域用户管理平台系统开发建设投资可行性分析研究报告Word文档下载推荐.docx
《xx电信ad域用户管理平台系统开发建设投资可行性分析研究报告Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《xx电信ad域用户管理平台系统开发建设投资可行性分析研究报告Word文档下载推荐.docx（46页珍藏版）》请在冰豆网上搜索。
3.没有统一的密码策略，长期存在弱口令
统一认证系统本身没有密码策略校验功能，导致用户使用弱口令，长期不更改密码，导致所有应用系统都可能被冒充登录。
有部分系统采用身份映射方式纳入统一认证体系中。
按IT内控要求，系统要定期更改密码。
由于用户一般通过统一认证客户端登录系统，不会记得登录系统的密码，所以无法自行更改密码，而要系统管理员在后台查出告知后才能更改。
这将增大管理员的维护压力。
1.2.3缺乏标准规范
目前的统一认证系统采用的认证规范不是公认的认证规范，厂家可以不遵循。
另外PC机的桌面登录无法修改认证模块，无法用统一认证用户库登录，只能用AD域用户库认证登录。
这就需要考虑两个用户库间同步的问题。
2系统功能需求
功能模块
功能项
功能项说明
IT基础信息源
员工基本资料库
资料库信息包括：
唯一的工号、从MSS系统、域服务器、统一认证系统等多种来源提取员工用户名及相关数据，资料库信息管理由人员信息管理来实现。
基础信息接口
以标准的WebService接口、DLL调用、存储过程调用等多种方式为其它IT系统提供基础信息，或接受其它IT系统返回的人员信息更新到基础库。
组织架构管理
组织架构显示
以树形层次结构显示组织架构，与AD中组织架构信息进行通信，原则上保持一致，AD中无法细分的信息在本系统追加的也可以显示
组织架构编辑
1.建立分公司层次型的组织结构，支持某一部门及下级部门整枝移动；
2.为方便未来纵向集成，部门信息中应包括省公司上级节点标志；
3.组织结构的层次精确到班组/室，并能根据需要任意增减；
4.能方便地增加、删除、更新组织结构信息；
5.组织结构中部门编码满足企业中长期发展的需要,同时兼顾与现有系统的整合；
6.同一员工处于某一职位、可担任多重职务；
多人可担任同一职务；
7.本系统的管理员才有组织机构的管理权限。
人员信息管理
添加人员信息
从MSS系统、域服务器、统一认证系统等多种来源提取员工用户名及相关数据，增加新入职员工资料；
人员信息的定义：
包括个人基本信息、岗位信息、合同信息、通信信息、培训信息（考试成绩、积分等）、休假信息、域帐号和其它应用系统帐号等信息。
修改人员信息
修改人员信息；
修改人员拥有的应用系统帐号；
通过数据导入方式批量修改员工所属部门等资料；
自助服务
员工能通过企业内部门户中‘我的帐户’以自助方式更新员工基本信息和扩展信息；
人员查询统计
1．根据指定条件查询员工信息；
2．提供基本的员工统计信息；
3．分级别查询用户清单；
应用系统管理
基础信息管理
建立企业范围内的IT应用系统定义，维护分公司IT应用系统信息；
维护应用系统的主要功能模块及功能项（可用于具体访问权限管理的全局化）；
访问权限管理
结合企业层次型组织架构，实现满足业务需求的分级权限访问（HierarchicalRBAC），简化用户和存取权限之间多对多关系管理；
根据部门及岗位的设置，建立并维护基于IT应用系统的用户角色，实现对用户组（IBSS中工位概念与此类似）、部门的集中授权与权限回收；
实现基于访问时间、应用系统功能模块的权限管理。
接口定义和管理
建立集中统一的数据库接口表，简化用户认证、应用系统数据采集等接口的管理与维护。
任务计划管理
主要用于对应用系统数据的自动采集，通过接口获取各应用系统使用的原始数据，包括系统名称、模块名称、用户帐号、操作时间、操作类别、操作内容等。
用户认证
C/S应用认证接口
建立基于AD域用户的C/S应用认证接口模块，修改现有统一认证系统客户端程序，使其到AD域用户库进行认证。
B/S应用认证接口
分别针对J2ee、.net两种开发平台建立基于AD域用户的认证接口模块，包含加密、解密，Cookie加密、解密整个过程的函数。
认证授权过程使用标准的加解密算法进行客户端和服务器端的互相认证以及帐号等信息的加密传输。
利旧认证封装
对于使用其它帐号认证的B/S和C/S应用，因为一般无法修改其认证接口，保留现有的认证方式。
用户初次登录应用时，统一认证客户端自动提取帐号和密码送到数据库保存。
用户登录统一认证客户端后，再次登录应用时，统一认证客户端用AD域帐号在数据库中查找该B/S或C/S应用的帐号、密码，然后自动填写到应用的登录窗口中实现自动登录。
认证日志处理
根据日志管理要求记录认证日志。
Web服务管理
Web服务接口
1.通过标准的WebService接口提供集中域用户认证功能；
2.通过标准的WebService接口提供人员基本信息；
3.在运行环境中能隐藏WSDL信息,提供WSDL内部发布方式；
4.提供生产协作系统所需要的其它Web服务。
安全管理
1.验证用户对应用系统的访问权限,对关键的Web服务提供安全保护机制；
2.对Web服务请求有完整的日志记录及日后审计功能；
查询统计
1.提供企业组织结构详细清单；
2.可按部门、用户角色、工作组提供员工详细清单；
3.监控、统计Web服务请求；
基础数据管理
基础数据编辑
提供对基础数据的各种增、删、改操作的管理。
系统对删除或修改基础数据的操作可通过设置开关加以限制。
基础数据接口
用户自定义不同类型的基础数据，通过公共模板建立并管理全企业范围内的基础数据，并提供基于URL的Web服务和基于DOS的Web服务接口供其它应用系统访问。
基础服务保障
扩展接口
提供IT基础服务的横向扩展（HorizontalScaling），以保证IT基础服务的高可用性。
数据同步
与ADS同步管理-保持员工数据的一致性
缓存管理
对相对稳定的公共数据提供缓存机制，以提高系统性能
系统权限管理
角色管理
用户的角色按照用户所在岗位确定，通过角色管理控制各用户登录企业门户权限、以及使用生产协作系统中所定义的各应用系统的权限。
要求实现角色资料的增加、修改、删除、查询等功能。
权限管理
1.数据范围-控制用户查询、修改、统计分析不同的、可指定的数据范围，实现系统模块可定义数据操作范围。
2.功能模块-系统管理员可增加、修改、删除用户角色所能访问的功能模块。
3.权限设置必须由被授权的系统管理员完成，管理员不能设置大于自身权限的权限。
角色权限关系
系统应能建立区局层次的业务管理员角色，分担部分由系统管理员负责的、与各区局本地化的管理维护相关的工作。
系统监控
状态监控
负责检查系统运行情况、数据库接口连接和状态、WebService接口的自动测试（如HeartBeat检查）
报警设置
系统运行中出现的异常数据、系统运行日志中错误情况，及时通过声音、警告标志、短信（需通过与外部短信平台接口）报告系统运行异常情况；
提供监控数据储、查询及必要的统计分析功能。
系统日志管理
日志检索
提供灵活方便的查询方式。
例如：
系统日志的各数据项（其它信息除外）均可作为查询条件、分类条件、排序条件或统计条件；
可打印查询结果。
日志中应包括如下数据项：
•用户号码：
工号或用户登录名；
•用户IP或终端名：
由系统根据用户请求自动读取；
•类型：
为方便日志管理而对操作进行的分类；
•对象：
具体操作的对象，如具体用户、角色、功能模块、应用系统名称、具体某个参数等；
•动作：
操作的具体行为，如增加、修改、删除、登录等；
•时间：
操作时间；
•结果：
记录操作是否成功；
•其他信息：
该操作的其他相关信息。
统计报表
提供用户各种操作统计报表，辅助工作量统计和有关考核，可打印结果。
3方案整体说明
3.1建设目标
本基础服务平台须提供组织构架管理、人员信息管理、用户认证、访问权限管理等，为本系统中企业门户、XX电信现有的及未来的IT应用系统提供集中统一的、企业级的公共基础服务。
它既是本系统实现系统整合、集中管理、信息共享的关键和核心，也是XX电信地市级信息系统未来扩展的基础和信息共享的平台。
3.2功能结构图
系统包括十一个功能模块，如上图所示，各模块功能简要说明如下：
序号
1
客户端应用
界面集成
认证接口
环境配置
2
3
4
5
6
7
8
9
10
11
12
3.3拓扑图
系统说明如下：
1、AD域服务器是整个系统的核心，AD域活动目录保存着用户的账号/密码等信息。
AD域服务器的功能如下：
（1）完成PC客户端登录桌面时的认证，按组策略设置授予用户管理PC机的权限和访问打印机、文件服务器、代理服务器等资源的权限。
（2）与基于AD域用户认证的应用服务器1建立信任关系，生成解密登录票据的共享密钥。
（3）接收AD域用户管理平台系统和基于AD域用户认证的应用服务器1重定向过来的认证请求，生成登录票据，发送回客户端。
并记录认证日志。
2、AD域用户管理平台系统是用户身份信息管理的核心，负责组织构架管理、人员信息管理、用户认证、访问权限管理等，保存着用户的基本信息、岗位信息、通信信息和账号权限信息。
其认证功能说明如下：
（1）通过统一认证客户端收集不能修改认证模块的应用系统的账号/密码，并建立与统一认证ID的映射关系。
（2）当用户登录应用服务器2时，从数据库中查找该系统的账号密码，发送回客户端，由其自动登录应用系统。
同时记录用户的登录日志。
（3）增加账号时自动从人力资源管理服务器同步用户的基本信息、岗位信息和通信信息。
同时提供身份信息编辑功能。
（4）自动提取应用服务器1和应用服务器2的账号信息并汇总成用户的账号权限信息。
3、应用服务器1是基于AD域用户认证的服务器，它保存着用户账号在本系统的权限信息。
其功能如下：
（1）提供用户权限配置功能。
（2）与AD域服务器建立信任关系。
（3）接收客户端的登录请求，并把它重定向到AD域服务器。
（4）接收客户端发过来的登录票据，解密得到账号后检查该账号是否有权限登录系统，并返回认证成功或失败信息。
4、应用服务器2是不能修改认证模块的服务器，保留原有的认证功能，保存着用户账号/密码和权限信息。
5、系统预留其他系统的接口，如其他支撑系统、告警系统、日志管理系统等。
3.4系统模块逻辑结构图
3.5系统技术架构
3.6认证流程
4方案详细说明
4.1用户认证管理
4.1.1单点登录（SSO）产品比较与选择
4.1.1.1SSO商业软件
专门的SSO商业软件厂家有Netgrity的Siteminder（已经被CA收购）、Novell公司的iChain、RSA公司的ClearTrust等。
有些门户产品供应商能提供自己的SSO产品如BEA的WLES、IBM的TivoliAccessManager、Sun公司的identityServer、Oracle公司的OID等。
这些产品大多是客户对SSO的需求很高，并且企业内Domino、SAP、Sieble等较多商用的通用组件系统需要统一认证的情况下采用，一般都要对要集成的系统做些改造，如安装Agent。
要先统一这些系统的认证，一般采用LDAP或数据库，然后才能实现SSO。
产品采购和实施成本比较高。
4.1.1.2开源SSO软件
著名的开源SSO软件有几家，如OpenSSO、PingFederate等。
前者是基于SunJavaTMSystemAccessManager的Web门户SSO方案，后者支持SMAL1.0、2.0及WS-Federation协议。
SAML是联合身份认证的主要协议，允许企业发布在整个企业范围有效的用户身份认证和授权证书。
SAML2.0把结构化信息标准促进组织（OASIS）、自由联盟和Shibboleth等组织的工作整合在了一起。
SAML2.0增加了账目链接、全球注销、带隐私功能的属性交换和同Shibboleth和自由联盟的互操作等功能，尚存缺点是它和微软、IBM正在开发的竞争性联合身份认证协议WS-Federation不相容。
而PingFederate同时支持SMAL2.0和WS-Federation，应该说是扩展性比较强的开源SSO软件。
开源SSO软件优点是已经有现成的框架和常见商业软件的集成接口。
其缺点是需要研究并理清软件框架和流程，没有商业技术支持，应用效果未知。
4.1.1.3建议利用AD进行SSO本地化开发
结合商业软件的成功思路，根据实际情况，充分利用AD的安全及分布式存储优势在现有系统的基础上短期内以较低成本实现SSO，这种方式来实施项目是比较现实而且可控。
建议本项目采用该方案。
4.1.2利用ADSI进行AD扩展编程
4.1.2.1AD内部数据结构带来的局限性
AD可看作一个大的层次结构数据库，它集中存储的内容必须遵循AD当前所定义的Schema。
Schema定义了数据存储的格式，包括类、属性、类和属性之间的关系。
类（classSchema）分为抽象类（Abstract）、附属类（Auxiliary）和结构类（Structure）三种。
属性（attributeSchema），分为单值和多值属性。
类和属性之间的关系，分为可选属性和必要属性。
Schema的内容只能增加，不能删除，过程是不可逆的，最多只能禁止一些属性或者类，而且还有诸多限制。
4.1.2.2通过AD接口开发实现扩展
1）AD数据访问
AD中存储的数据被当作一个个的对象，每一个对象是一个classSchema的实例。
都有一个唯一的路径访问。
AD中对象的访问路径由所支持的Provider决定，Win2000默认的Provider有四个，安装IIS的话会增加一个IIS的Provider，对IIS进行管理。
通常使用比较多的是LDAP，可以通过这个Provider针对域用户以及其他扩展信息进行访问和管理。
2）ADSI（ActiveDirectoryServiceInterface）标准接口规范
ADSI可以作为一个框架来理解，它给上层应用提供一个统一的接口，ADSI提供了比较好的扩展的方式。
ADSI提供商提供一些接口和方法来访问域名称空间的对象，如下图所示：
ADSI支持VB、VBScript、C++及Java语言，对环境有很好的适应性，如下图所示
3）AD扩展编程
若需要为已有的类添加方法，那么需要编写AdsExtension类；
如果需要在AD中存储扩展信息，就需要修改Schema，增加新的类或者属性；
更进一步的话，完全可以自己实现一个Provider,实现自己的查询和数据存储的方式。
4.1.3能修改客户度端认证模块的系统
对能修改认证模块的应用系统，修改统一认证客户端的认证模块，使其可用AD域用户认证登录。
统一认证客户端通过认证后用户点击应用程序连接就直接进入用户对应权限界面。
系统提供C/S应用认证接口，该认证接口建立基于AD域用户的C/S应用认证接口模块，修改现有统一认证系统客户端程序，使其到AD域用户库进行认证。
系统也提供B/S应用认证接口，分别针对J2ee、.net两种开发平台建立基于AD域用户的认证接口模块，包含加密、解密，Cookie加密、解密整个过程的函数。
基于AD域用户的认证过程：
首先应用服务器要先在AD域服务器注册，建立起信任关系，并获得共享会话密钥。
1、应用客户端发起登录请求。
2、应用服务器接受到请求后，把请求重定向到AD域服务器。
3、应用客户端向AD域服务器发起认证请求，请求中包含用户名，有效时间段，应用服务器的信息。
4、AD域服务器接收到请求后，检查域用户库，如用户合法则使用和用户共享的密钥加密一张服务申请票发给客户端。
若客户端能成功用输入的密码解密恢复，就可得到服务申请票,身份被确认。
如用户不合法，则返回认证失败信息。
服务申请票中包含了动态生成的会话密钥。
5、应用客户端向AD域服务器申请拟访问服务的服务门票，申请中包含用户名，IP,有效时间段，服务名，服务申请票等信息。
申请信息用服务申请票中的会话密钥加密。
6、AD域服务器检查用户的服务申请票，若确认有效，为用户准备一张指定服务的服务票（包括用户名，IP,有效时间，服务名，会话密钥等），并用指定服务与AD域服务器共享的Key加密，和其它一些用会话密钥加密的信息一起返回给应用客户端。
服务票和服务申请票包含的会话密钥相同。
7、应用客户端收到服务票后，用会话密钥加密自己的身份、当前时间、序列号等和服务票一起发送给应用服务器。
8、应用服务器收到申请后，用与AD域服务器共享的密钥解开服务票，取出会话密钥，再用会话密钥解开用户身份认证信息，与服务票中的用户身份信息对比，确认后应用服务器根据用户名查找是否有权登录。
如有权，则向客户端确认认证通过。
如无权，则向客户端提示无权登录。
与此同时返回用户申请时在认证信息中给出的时间信息，作为用户确认应用服务器合法身份的凭证（能解密认证信息），达到双向认证的目的。
认证过程完成。
4.1.4不能修改客户端认证模块的系统
4.1.4.1认证过程
对不能修改客户端认证模块的系统可以分为B/S和C/S架构两类。
虽然这两类系统在实现统一认证的具体技术处理方法有所差别，但这两类系统认证过程都是一样的。
过程图如下：
首先修改统一认证客户端程序，使其支持基于AD域用户的认证过程。
用户已登录统一认证系统。
1、用户点击某个应用程序链接。
2、统一认证客户端捕捉到登录操作，把统一认证账号发送到统一认证服务器。
3、统一认证服务器搜索数据库，查找对应的登录该应用程序的账号和密码，发送给统一认证客户端。
4、统一认证客户端把账号和密码填写到应用客户端登录窗口中，应用程序客户端发送账号和密码到服务器。
5、应用服务器检查用户库，如合法则向应用客户端确认认证通过，并根据账号授予权限。
4.1.4.2基于B/S架构的系统认证
对于支持B/S架构的应用系统的认证，可以通过IFRAME或超连接方式集成目标系统。
如在URL中带上用户名和密码，为了安全起见，可采用HTTPS来传递用户名和密码。
在用户第一次进入被集成到SSO的系统时，让用户自己输入他在该系统中的用户名/密码等信息，并保存到表中或LDAP等其他数据源中。
该方式一般需要浏览器支持COOKIE。
通过IFRAME集成LotusNotes登录示例：
<
IFRAMEsrc=http:
//host1/names.nsf?
Login&
Username=admin&
Password=pass&
RedirectTo=/names.nsf>
/IFRAME>
这种集成方式的最大优点是对被集成的系统不需要做任何的改动。
4.1.4.3基于C/S架构的系统认证
对不能做任何改动的客户端认证模块程序可采用的办法如下
1）包装一层应用程序
2）利用WIN消息（给登录窗口发送用户名，密码等登录所需要的信息）
3）模拟键盘（java有模拟键盘输入的API）
有些系统的认证模块不能修改，但客户端登录程序可以做一定修改的，最好采用参数传递的方法，并让登录的EXE文件读取参数进行认证。
具体集成方式上，若希望客户端不安装程序，可以使用基于Web的Applet调用客户端程序，但这需要修改JRE安全设置，而且Applet启动和刷新比较慢，对固定业务并且界面操作比较频繁的系统不建议使用这种方式。
电信目前大多数C/S系统的客户端是采用Delphi或PowerBuilder开发，界面操作比较频繁，建议采用新的统一客户端程序来包装原客户度程序实现应用系统自动登录。
对有些应用程序客户端程序甚至可以通过修改资源文件使其隐藏登录界面而直接进入应用功能界面。
本类系统统一认证流程补充说明图如下：
4.1.5获取旧系统权限信息
对于不能修改认证模块，继续保留原用户权限、身份信息管理的系统，需要从原系统获得用户权限信息，作为统一权限视图的一部分。
原来的统一认证系统有获得旧系统用户账号、密码的接口，需要对之进行扩充，以获取用户权限信息。
4.1.6认证日志处
升级会员 