统一身份认证平台.docx
- 文档编号:2255751
- 上传时间:2022-10-28
- 格式:DOCX
- 页数:9
- 大小:52.40KB
统一身份认证平台.docx
《统一身份认证平台.docx》由会员分享,可在线阅读,更多相关《统一身份认证平台.docx(9页珍藏版)》请在冰豆网上搜索。
统一身份认证平台
统一身份认证平台
信息化建设是一个动态的、进展的进程,随着各类信息系统不断增加完善,对信息平安、权限治理、系统间交互的需求也将愈来愈强烈。
原有各独立的应用效劳系统各自为政的身份认证方式已经难以适应进展的应用环境。
学校需要有一个独立、平安、高效和靠得住的身份认证及权限治理系统,由此系统来完成对整个信息系通通一身份认证与权限治理。
身份认证系统将是数字校园建设的重要组成部份,该系统为数字校园的所有用户提供统一的身份确认与权限交付。
用户通过一次认证后,即可取得相应权限,并利用数字校园中所有应用效劳系统提供的效劳。
另一方面,必需要有一个比较稳固的动态口令和统一身份认证系统专门好地结合,如此每一个用户都具有一个静态口令和一个不断转变的动态口令,治理员能够设置用户静态口令和动态口令不同的可利用范围,如此从另一个角度提高了整个信息化的平安性;如此的一个动态口令系统必需能够和各应用系统的动态口令系统有专门好的接口,使得在纵向能够做到动态口令的一致性。
通过指定相应的集中认证技术标准,提供统一的应用系统用户治理接口,最终实现所有新建系统用户认证的统一集中化治理,做到真正意义的集中认证。
实现各应用系统的“集中认证”,能够完全改变各自为政、治理松散的用户治理模式,充分发挥学校内部网络治理保护部门的治理职责,标准用户操作行为,强化用户合理利用网络资源的意识。
本系统重点包括三个方面:
用户资料的集中存储和治理、用户身份集中的验证、访问权限的集中操纵和治理。
建设目标
随着应用建设的慢慢深切,已经建成的和将要建成的各类数字校园应用系统存在不同的身份认证方式,用户必需经历不同的密码和身份。
因此,要建设以目录效劳和认证效劳为基础的统一用户治理、授权治理和身份认证体系,将组织信息、用户信息统一存储,进行分级授权和集中身份认证,标准应用系统的用户认证方式。
提高应用系统的平安性和用户利用的方便性,实现全数应用的单点登录。
即用户经统一应用门户登录后,从一个功能进入到另一个功能时,系统平台依据用户的角色与权限,完成对用户的一次性身份认证,提供该用户相应的活动“场所”、信息资源和基于其权限的功能模块和工具。
在学校工作人员进行了调动、调级、调职等变更后,或学校体制改革、组织机构变更后,利用户的身份和权限在各系统之间和谐同步,减少应用系统的开发和保护本钱。
建设内容及功能要求
统一身份认证平台应能实现身份数据的统一存储、统一治理,实现全校各类应用的单点登岸,和各类访问与操作平安审计。
同时,还提供便利的工具,便于系统的保护和治理。
平台建设内容要紧包括以下方面:
目录效劳
目录效劳是统一身份认证平台的基础。
目录效劳要以面向对象的数据库和LDAP的方式集中治理用户信息,保证数据的一致性和完整性,为数字校园各类应用提供用户信息的共享。
LDAP(LightweightDirectoryAccessProtocol)是目录访问协议的一种,它基于标准,可是简化了实现方式,因此称为轻量级的目录效劳,相关于通经常使用于认证的关系数据库而言,LDAP目录效劳偏向于包括描述的基于属性的信息,并支持复杂的过滤器操作。
它的数据组织树型结构,在目录效劳中称之为目录信息树(DirectoryInformationTree,DIT),DIT的大体组成单元是条款(Entry),条款由多个属性组成,且可扩展协议规定了DN的命名方式、存取操纵方式、搜索格式、复制方式等,并提供了存取这些信息的效劳。
数据组织的树型结构能够限定在目录信息树的任一分枝上进行目录查找,这一特性使目录效劳相关于专门的关系型数据库的数据处置速度快一个数量级的散布式目录效劳通过度区(Partition)和复制(Replication)功能将目录信息树上的数据散布到多个物理效劳器上实现,为应用系统和效劳中的信息存储和治理提供了一个可扩展的结构支持普遍的应用编程语言,如C、Java、PHP、Perl等都有自己的LDAPAPI,用户能够轻松选择适合自己的编程语言进行相关应用的开发最新的协议版本是V3,其后续的开发已经纳入全世界互联网最具权威的技术标准化组织IETF。
目前,LDAP协议已经成为一个被普遍支持的用于统一身份认证跨平台和标准的协议,它的易于集成不同应用系统的特点,成为支持网络系统的重要底层基础技术之一,是进行统一身份认证的一个优选方案。
统一身份治理
统一身份治理要充分考虑学校业务中的需求,包括组织机构及用户治理、数据保护等功能。
提供职位变更的身份转换,组织机构的拆分和归并,支持组织机构的实体和虚体,支持多级治理等,为SSO提供一个方便的身份治理平台。
⏹组织机构及用户治理
✓要求支持治理创建多级组织机构、部门信息;
✓完成治理系统用户信息、机构治理员、机构负责人等配置;
✓投标方必需提供成熟的组织机构及用户治理模块,并提供相应的功能图片说明。
⏹数据保护
✓要求提供数据保护工具来支持门户内组织机构、用户等数据的批量保护、导入、导出等;
✓要求支持对导入的数据进行校验和审核;
✓要求提供相应的综合查询功能,能够完成批量用户密码初始化;
✓要求导入/导出工具提供给学校相应的模板,支持学校自主定制开发,并将免费提供相应开发平台。
✓投标方必需提供成熟的数据保护治理模块,并提供相应的功能图片说明。
统一认证治理
统一认证系统主若是为其它系统提供认证效劳,用户只需要登录一次,即通过一个应用中的平安验证后,再访问其他应用中的受爱惜资源时,再也不需要从头登录验证。
⏹身份认证效劳
✓要求基于LDAP和CAS认证方式设计,提供跨效劳器及业务应用的身份认证效劳及Agent,确保跨业务系统身份认证识别;
✓支持多种认证方式:
支持基于认证接口、认证代理和LDAP认证的多种认证集成模式,支持用户/密码、CA证书认证、动态口令认证、智能卡认证等认证方式;
✓要求支持LDAPv3标准。
⏹单点登录效劳
✓要求提供WEB-SSO(SingleSignOn)效劳,用户只需要登录一次就能够够访问所有彼此信任的WEB应用系统,投标方需详细描述单点登录机制。
⏹个人自助效劳
✓要求提供给所有效户修改密码、密码找回、修改昵称等个人自助效劳,给用户提供更方便快捷的效劳。
⏹群集效劳
✓要求在内存中存储登录用户权限、角色信息、组织机构信息登录信息,并通过集群广播向集群内效劳器发送,以实现认证效劳器集群扩展。
⏹身份审核
✓关于组织机构的变更、角色的变更和权限变更要求提供身份审核功能;
✓在设计中,要考虑到大部份业务系统的身份治理都是用WEB和数据库方式,因此,在这些系统中的用户认证方式应在身份认证效劳器中完成;
✓关于支持LDAP认证的系统,并通过缓存技术和同步技术保证身份信息的唯一性和一致性。
⏹日记治理
✓要求详细记录对用户的信息的操作情形。
✓要求用户登录应用系统后对系统资源的所有访问都记入日记,以便事后对用户操作进行审计,成立完善的事后追溯机制。
✓要求提供对所有的审核信息进行查询检索功能。
技术要求
(1)平台基于J2EE体系结构,所有功能模块概念效劳提供者接口(ServiceProviderInterface),能够支持第三方的效劳提供者;
(2)在身份认证系统设计中,为了适应当前和尔后系统的建设进展需要,建议采纳的技术实现手腕要紧包括LDAP、PKI、SSO、SSL等等;
(3)单点登录从实现技术上基于session、cookie、rewrite技术和采纳portal等几种方式,依照用户的情形能够选用其中的任何一种。
(4)平台的治理与保护采取分级模型支持多级的治理;
(5)采取分级授权,能够依照业务的需要灵活制定平安策略操纵授权;
(6)采纳灵活的基于角色的权限治理模型,集中的权限操纵的授权治理面向全局的用户和数据资源,覆盖了各类应用;
(7)支持用户/密码、校园卡/密码和数字证书等认证方式;
(8)灵活概念角色之间的继承、相容和互斥关系,授权简单、便利;在访问操纵策略上,用户能够定制不同粗细粒度的平安规那么;
产品选型
现有的单点登录解决方案超级多,而且各个J2EE容器厂商都有各自专有的SSO产品。
可是J2EE标准未包括SSO方面的内容。
尽管如此,大量的商业和开源集体都对SSO投入了庞大的资源,并取得了超级好的成绩。
CAS(CentralAuthenticationService,中央认证效劳)是成立在开放协议上的企业级SSO解决方案,它具有开源、平安、轻量、可扩展性强、容易部署的特点,并在高校和企业中取得普遍的应用。
(1)CAS的组成与工作原理从体系结构上看,CAS包括CAS效劳器端和CAS客户端代理两部份。
由于CAS2.0协议借助于XML数据结构与客户进行交互,因此开发者能够利用各类语言编写的CAS3客户与效劳器进行通信,比如PHP、C++、Java(JSP)、Per等。
CAS3效劳器采纳Java开发而成,它要求目标运行环境实现Servlet标准提供J2SE的支持。
CASServer负责完成对用户的认证工作,CASServer需要独立部署,它是一个简单的WEB应用,能够将其war文件直接部署的WEB容器中。
CASServer会处置用户名/密码等凭证(Credentials),它可能会到数据库检索一条用户帐号信息,也可能在XML文件中检索用户密码,对这种方式,CAS提供统一灵活接口/实现分离的方式。
CASClient负责部署在客户端(指WEB应用),CASClient的部署意味着当有对本地WEB应用的受爱惜资源的访问请求,需要对请求方进行身份认证,WEB应用再也不同意任何的用户名密码等类似的Credentials,而是重定向到CASServer进行认证。
TGT(Tickect-GrantingTicket)是用于成立SSO登录用户身份的重要证据。
一旦SSO用户成功登录到CAS效劳器后,CAS效劳器便会生成一个TGT,并保留在CAS效劳器中,CAS效劳器保护所有的TGT。
通常,除阅读器和CAS效劳器外,客户端可不能接触到TGT。
TGC(Ticket-GrantingCookie)是存储的TGT的Cookie。
一旦登录到CAS效劳器后,会在阅读器中存储它。
这是同CAS效劳器交互的Cookie,只有HTTPS借助于传输通道,TGC才会被传入到效劳器。
一旦阅读器关闭,便会被销毁掉。
能够看的出一个会同时出此刻效劳器和阅读器中,关于阅读器而言,TGT是以TGC的形式存在的。
ST(ServiceTicket)是CAS效劳器借助于各类阅读器发送给效劳的票根。
当阅读器的用户登录到CAS效劳器后,必需取得一个ST后,他们才能访问效劳。
每一个ST只能利用一次,而且它往往同特定的效劳绑定在一路,不然持有这一的用户也不能访问到想要的效劳,从而确保了效劳的平安性。
图4描述了应用CAS实现SSO的一个大体流程。
当用户请求WEB应历时,CASClient以Filter方式爱惜WEB应用的受爱惜资源,过滤从客户端过来的每一个WEB请求,通过Cookie检查当阅读器中是不是存在TGC,由于第一请求当前实例中还未存在TGC,CASClient的Filter就会把用户重定向到CASServer,CASServer会要求阅读器用户提供WEB登录凭证。
用户提供相应的凭证后,CASServer会再次检查当前的请求中是不是包括了有效的TGC,若是包括了,那么会从中抽取相应的TGT。
若是这一TGT有效,那么CAS会基于这一TGT创建新的ST,并将与需要访问的效劳的URL绑定在一路。
CAS会采取重定向机制让阅读器请求效劳URL,由于此URL是CASClient的Filter的过滤范围,因此Filter会从上述URL中掏出ST参数,并对ST进行校验,当确保了这一ST与当前用户访问的目标效劳吻合时,用户即能够访问到目标效劳,完成了SSO的整个流程。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 统一 身份 认证 平台
![提示](https://static.bdocx.com/images/bang_tan.gif)