老哥学习网 - www.lg9.cn 2024年05月15日 16:39 星期三
当前位置 首页 >经典语句 >

[基于SAML与Web,Service的统一身份认证接口设计] 实名认证身份证号2018

发布时间:2019-05-20 06:46:51 浏览数:

  摘要:同一用户拥有多个账号使用单点登录技术已应运而生,如何更好地实现站点之间的资源共享与授权控制一直是提高网络应用性能所需考虑的重要问题。本文采用了SAML和Shibboleth技术为基础,结合了Web Service,设计出了跨域异构系统之间的统一身份认证与授权方案,既为不同系统之间搭建了一个桥梁,也保证了各自系统的安全性与稳定性。
  关键词:Shibboleth;Web Service;SAML;跨域访问;单点登录;统一身份认证
  中图分类号:TP311 文献标识码:B 文章编号:1673-8454(2012)19-0076-03
  一、概述
  随着网络技术的发展,网络资源日益丰富,各个领域行业都相继实现数字化。随着各种不同功用、不同结构的网络应用越来越多,系统之间的数据交互愈发频繁,系统之间需要不同程度的协作,用户的身份和权限管理就成为了异构系统进行交互与协作的关键点。不同的系统拥有自己的一套用户名和密码,在协作的情况下,一个用户需要登录多个系统进行数据的管理,需要记住多个用户名和密码并且多次登录。为了保证数据的安全性,各系统采取了屏蔽部分功能的做法。这样,系统必须同时考虑内部人员与外部人员的权限问题,工作十分繁重,同时也降低了信息化管理的效率。单点登录(Single Sign—On,简称SSO)理念应运而生,单点登录解决了系统协作时的统一身份认证问题,只需一次登录,就可以访问所有相互信任的系统。目前实现SSO的具体技术有很多种,也有很多不同的解决方案,下面选几个典型分析其优势与不足:
  1.ID开放URL的数字身份识别框架
  用户提供一个URL给外部站点,外部站点通过用户身份地址取得OpenID验证服务器地址,通过外部站点重定向到OpenID验证再重定向回外部站点,取得验证结果。这种方式的特点是把负担分散在用户端,防止服务器拥塞,但因为URL是用户提供的,由于验证服务器的性能限制,会使得验证效率变得很低。
  2.基于Session共享的跨域身份验证
  在一个站点内部,用户每次登录都会产生一个会话号(SessionID),在站点内部可以保持登录状态信息,但是一般情况下不可以跨域。利用了Session共享技术之后,通过XML在不同服务器之间传递Session有关参数,实现单点登录。但在传递参数的过程中,一旦数据被截取,那么这次会话的安全性就得不到保障了。
  3.基于Cookie令牌形式的身份认证
  Cookie是写在客户端的信息,并且有独立的全局唯一的编号,而且可以在客户端存储编号以外的其他字符信息,便于单点登录及其应用系统的利用。但是它也有一个重大的缺点,当单点登录系统与应用系统不在同一个域时,由于考虑系统安全的原因,应用系统服务程序是无法访问其它域的Cookie信息。[1]
  4.基于SAML(安全断言标记语言)的Subject和资源授权模型
  SAML是由结构化信息标准促进组织(OaSlS)建立的一套安全标准。是基于XML(可扩展标记语言)面向Web服务的架构,用于在网络间交换安全信息。SAML包含三种实体:Subject(参与信息交换的实体)、Relying Party(信任方既提供服务的一方)、Asserting Party(断言方既提供验证的一方)。这种方式兼有OpenID的灵活性和Cookie保持用户信息状态的稳定性,稍有欠缺的是这种状态是一个布尔值,无法将其信任程度量化,不能很好的实现跨域用户权限级别控制。
  综合比较上述方案,本文采用以SAML描述的Shibboleth框架作为基础技术平台。SAML是基于XML的标记语言,所以其具有很强的扩展性,结合目前分布式异构环境下构建复杂系统的重要技术Web Service,可以很好地弥补SAML的不足之处。据此,本文设计出一套SAML+Web Service的认证系统,解决了联盟机构统一身份认证及其权限级别控制问题。
  二、解决方案设计
  从SAML的三种实体进行分析,参与信息交换的实体是各个异构系统的用户,这些用户需要对相互信任的几个系统进行单点登录访问。信任方则是一个相对的概念,对于用户来说,非自身所在域的系统都属于信任方。身份验证服务由机构本身提供断言方,所以断言方在这里指用户所在的机构。下面先简单介绍本方案涉及的几种关键技术:
  SAML已经在前面提到,此处不再赘述。Shibboleth是一个针对SSO的开源项目,主要应用在校园内Web资源共享,以及校园间的应用系统的用户身份联合认证。Shibboleth的主要特点是将认证模块放在用户所属域的认证服务端,可以把不同机构的身份认证工作交给各个机构本身,这样就可以让认证工作分散而不是集中,进而解决了用户访问量大时认证工作的瓶颈问题。
  Web Service 是一种新的web应用程序分支,它们是自包含、自描述、模块化的应用,可以发布、定位、通过web调用。它有四个重要的组成部分:XML,可扩展置标语言,用来传输跨平台数据;WSDL,网络服务描述语言;SOPA,简单对象访问协议;UDDI,统一描述、发现和集成协议。Web Service技术具有松散耦合的特点,它没有复杂的消息传递、对象引用和垃圾回收机制,因此非常适合于分布式处理。
  Shibboleth框架需要一个Discovery Service为各个机构的用户服务,Discovery Service是一个连接多个异构系统的枢纽,也可以把它理解为整合资源,并把资源以目录或列表形式展现给用户的服务中心,但是Discovery Service本身允许没有具体的应用资源。它可以是某个机构,也可以是单独的服务中心。[2]
  首先考虑Discovery Service,该服务器需要汇集很多机构的资源列表,形成一个大的门户,也就是联盟门户。一般的解决方案是配置一台UPortal服务器,采用Windows Server系统或者Linux,搭载Tomcat容器,考虑到安全性的问题,服务器上须安装OpenSSL。UPortal提供用户两条访问通道,一条是先访问UPortal,通过UPortal进行选择要访问的服务提供方,直接跳转到相应的断言方验证;另一条是直接访问服务提供方,重定向到UPortal之后,再转发到断言方进行身份验证,最后跳转到服务方页面。   其次是Service Provide,如果采用Shibboleth框架,那么服务提供方须安装Shibboleth Service Provider,其他环境根据不同机构的实际情况采用不同的配置,具体取决于网络应用所要依赖什么样的平台。如果是Java或者php平台,那么Linux和Tomcat是比较好的选择。
  最后是如何进行身份认证。如图1所示,服务提供方把认证请求转发给断言方之后,断言方要对发送过来的信息进行验证。断言方能够判断请求的用户是否有权限的前提,就是它拥有该用户的详细信息,而用户的详细信息因为要保障安全的缘故不能对外泄露,包括相互信任的联盟机构。所以断言方的设定有三个原则:一是断言方分别设定在不同机构自身的服务器上,认证细节对外不公开;二是断言方只需具有最精简的身份验证机制,不具有得到额外信息的功能,以防信息泄露;三是断言结束后能够得出用户的权限级别状态值。
  三、应用案例介绍
  下面介绍一个校园门户网站之间跨域访问身份认证的案例。平台是运行在IPv6之上,为高校联盟师生服务的学习交流平台,为了营造一个积极向上、健康文明的学习环境,平台对访问的用户进行了限制,必须是本校用户和高校联盟用户当中,具有IPv6地址的用户才能登录平台。那么,如何实现各大高校之间的身份认证成为了平台建设的关键问题。
  系统入口有两个,一个是本校用户,一个是高校联盟用户,本校用户登录的大致过程如图2所示。
  本校用户登录时向CNS.csu.edu.cn服务器发出http请求,系统首先会在本地数据库中读取查找,如果存在该帐号并且密码正确,则登录成功。如果用户是第一次登录该系统,本地数据库中没有记录,系统就会调用本校的统一身份认证Web service,查看其返回值,为false则登录失败,为true则将此帐号和密码写入到本地数据库中,该用户下一次登录系统时登录信息就可以直接从本地数据库读取。
  而联盟用户的登录相对复杂,登录和认证过程如图3所示。
  联盟用户访问系统的方式及原理:
  直接输入CNS代理服务器域名进行访问。在系统首页上点击“联盟登录链接”跳转到UPortal联盟门户, 联盟登录链接在跳转的同时记录下了代理服务器的域名以便认证完成后跳转回来,联盟门户采用了MVC(model-view-control)的思想,将处理过程所需的类与视图分开操作,这样就降低了不同系统之间的耦合性。选择用户所在大学,又会重定向到用户所在学校的Identity Provide服务器的认证页面上,Identity Provide服务器上部署的是能够访问各个学校Web service的认证程序,输入帐号密码,认证之后在http headers上写入登录信息键值对。再根据上文提到的系统首页上 “联盟登录链接”记录下的代理服务器的域名跳转回本系统的代理服务器,最后代理服务器将请求交给本系统所在的服务器,检查是否有key为Identity-Provider 的http header,如果有则登录成功(再根据其它键值对读出登录者的登录信息:如用户名、所在院校等)。因为客户端带有Identity-Provider header,这时回到联盟门户,点击其它学校的资源将不再需要验证身份,权限则根据authoritystate来获得。
  另外一种访问的方式是直接输入UPortal联盟门户的域名,选择用户所在大学,重定向到用户所在学校的Identity Provide服务器的认证页面上,输入帐号密码,通过验证后跳回联盟门户页面,这时就在headers中写入了上文提到的登录信息键值对。因为所有其它的资源检验联盟用户是否登录成功就是依据这些headers,所以在联盟门户上点击所有学校(包括本系统)的链接访问资源将不再需要验证身份。?
  参考文献:
  [1]杨荣华.基于SOA的单点登录系统研究与设计[D].湖南:中南大学,2008.
  [2]符荣鑫,孔凡壬,杨善茜.基于Shibboleth的校园网统一身份认证系统研究[J].电脑知识与技术,2011(6).
  [3]ZHANG Yong-sheng. Research of Dynamic Authentication Mechanism Crossing Domains for Web Services Based on SAML[J].InternationalConferenceoff Future Computer and Communication,2010(2):398-398.
  (编辑:李晓萍)

推荐访问:身份认证 接口 设计 SAML

相关文章:

Top