1 引言
2 随着因特网的飞速发展,基于B/ S(浏览器/ 服务器) 结构的企业应用软件也得到了快速发展,各种应用系统已经应用到很多企业的生产管理活动中去,为企业提高工作效率和管理水平做出了巨大的贡献。
3 但是,由于企业受业务、自身条件和当时软件技术的影响,这些不同的系统往往是在不同的时期建设起来的,运行在不同的平台上。各系统也许是由不同厂商开发的,使用了各种不同的技术和标准。
4 每个应用系统都有自己独立的一套身份验证机制,采取分散登录、分散管理。又由于针对企业应用各系统的联系十分紧密,各用户需要使用大多数的系统。如果不使用单点登录(Single Sign On ,简称SSO) ,
5 势必造成企业的工作人员在实际工作中要频繁地在各个系统登录和注销,严重影响了生产效率;同时,很多系统都要维持一个用户身份信息是很麻烦的。因此,信息系统急需建立一个统一的身份认证系统,以保证用户操作的方便和应用系统的安全。
6 所谓统一身份认证,就是用户基于最初访问的一次身份认证,就能对其被授权的资源进行无缝访问。单点登录是目前比较流行的企业业务整合的解决方案之一。SSO 的定义是:在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。
7 本系统是对一个企业进行统一身份认证改造,该企业的应用系统均采用B2S(浏览器2服务器) 结构构建。系统进行统一身份认证改造后,需要能够实现较为灵活的、基于SAML 协议和RBAC 协议原理的单点登录模型,并且需要有灵活的访问控制,保证和原有系统的紧
密结合,实现用户的统一身份认证。
8 2 SAML 、RBAC简介和工作原理
9 2. 1 SAML 简介
10 SAML ( Security Assertion Markup Language , 简称SAL) 标准定义了一个
在线商业伙伴之间交换安全信息的框架。更准确地说,SAML 定义了一个基于XML 标准的框架,用于实体之间交换安全信息。
11 SAML 1. 1 是由OA2SIS ( The Organization for the Advancement of St
ructuredInformation Standards ,简称OASIS) 标准组织的安全服务技术委员会SSTC(Security Services Technical Committee ,简称SSTC) 制定的。
12 SAML 可以实现不同安全服务系统之间的互操作,SSTC 通过了很多用例( 需求)
来推动SAML 的需求。SAML 1. X 中解决的最重要问题就是单点登录问题,用户使用用户名和口令登录源站点,然后希望无需再次验证即可访问目标站点。
13 用户通过在认证站点进行认证登录,认证站点和目的站点通过交换用户认证信息,
从而到达认证的目的。在这里,认证站点即为一个认证区域的中心认证服务站,一个认证区域一般只有一个这样的认证站点,全面担任用户身份认证的责任。
14 而目的站点就是需要认证站点提供服务的应用系统,一个区域一般都有多个这样
的目的站点。由于把认证的工作都交给了认证中心,所以目的站点一般不会考虑身份验证的问题。
15 2. 2 RBAC工作原理
16 由于该项目是基于SAML 1. 1 标准构造的,所以下面介绍的主要是SAML 1. 1
协议的内容。SAML 规范体系主要由三个部分构成: 断言(Assertion) 、请求/ 响应协议(Request and Response Protocol) 、绑定和配置(Bindings/Profiles) ,各个部分紧密地联合在一起,构成了整个SAML协议的实现。
17 2. 3 RBAC的简介
18 基于角色的访问控制(RBAC) 的概念在20 年前第一次提出,它是从传统的随意
访问控制(Discretionary AccessCont rol ,简称DAC) 和强制访问控制(Mandatory AccessCont rol ,简称MAC) 发展起来的。
19 它可以实现企业的权限机制到企业组织结构的自然映射,提高了访问控制的水平,
大大提高了安全管理员的效率。RBAC 模型由四个部件模型组成,分别是基本模型RBAC0 (Core RBAC) 、角色分级模型RBAC1 ( HierarchalRBAC) 、角色限制模型RBAC2 (Const raint RBAC) 和统一模型RBAC3 (Combines RBAC)。
20 RBAC0 定义了能构成一个RBAC 控制系统的最小的元素集合。在RBAC 之中,
包含用户( Users ) 、角色(Roles) 、对象(Object s) 、操作(Operations) 、许可权( Per2missions) 五个基本数据元素。
21 权限被赋予角色,而不是用户,当一个角色被指定给一个用户时,此用户就拥有了
该角色所包含的权限。会话Sessions 是用户与激活的角色集合之间的映射。RBAC0 与传统访问控制的差别在于增加一层,间接性地带来了灵活性,RBAC1 、RBAC2 、RBAC3 都是
先后在RBAC0 基础上的扩展。
22 3 统一身份认证设计和实现
23 3. 1 总体构架
24 该系统采用B2S 结构,整个统一身份认证体系由一个认证服务器和应用系统服
务器(该系统主要用于实验目的,因此这里的应用服务器只有一个,在实际应用中应用系统应该有多个) 构成。认证服务器负责对用户进行身份验证,并把认证结果返回给应用服务器;
25 应用服务器根据认证的结果,结合其自身的RBAC 访问控制系统,对用户访问系
统进行授权。认证服务端由SAML 响应器、身份验证服务和认证服务数据库构成。SAML 响应器用于与应用服务端进行SAML 协议信息,用于完成认证服务器和应用系统的身份信息处理和通信;
26 身份验证服务主要用于对登录用户进行验证;认证服务数据库用于保存与用户的
身份相关的信息。应用服务端由SAML 响应器、RBAC 访问控制和应用系统数据库组成。SAML 响应器用于与认证服务端进行SAML 协议信息,用于完成认证服务器和应用系统的身份信息处理和通信;
27 RBAC 访问控制组件用于根据用户在该系统中的角色对用户访问系统的权限进
行有效的控制;应用系统端数据库主要包括应用系统的账户和对应权限信息,当然还应包括用于保存应用系统业务数据的信息。由于本文的关注点主要在认证方面,故在本系统中不会表达。
28 3. 2 数据库设计
29 按照模型设计的要求,统一认证系统包括两部分数据库:一部分属于认证服务器的
IdentityInformation 数据库,另一部分是应用系统的ServiceInformation 数据库(因为只为了表示统一身份认证,在该系统设计中只有访问控制部分的设计) 。
30 首先介绍IdentityInformation 数据库的设计。设计该数据库的目的主要是为
了表达同一用户管理模型中的映射关系,把各应用系统的账户和统一的用户ID 联系起来。该数据库由Application、user 、User_Account _Application 三个表构成,各表之间通过外键相关联。
31 根据现在分别对各表的设计进行介绍:表User 的主要作用是为了表达统一身份
认证的统一用户的目的。这里,把有应用系统的各个账号由User 表中的user_ ID 表示。这样,用户的身份就被统一起来了,用户的验证主要根据这张表的user_ID 和password 判断,它由用户唯一标志(user_ID) 、密码(password) 和用户名(user_name) 构成。
32 表User_Account_Application 的主要作用是建立用户到各应用系统中的账号,
和账号对应访问的系统建立对应关系。根据登录模型设计的要求,访问控制由系统自行决定。所以,建立这样的关联后,用户访问各系统就可以根据系统自身的访问控制表进行用户系统授权。
33 它由用户唯一标志(user_ID) 、账号标志(account _ ID) 和应用系统唯一标志
(application_ID) 构成,这三个字段联合构成一个主键,用于表示三者的唯一关系。表Application 的主要作用是描述应用系统的信息,包括应用系统唯一标志(application_ ID) 、应用系统名称(application_ name) 和应用系统的访问地址(application_url) 。
由于应用系统都采用B2S 结构,所以可以用URL 地址表示应用系统资源的位置。下面介绍应用系统的数据库ServiceInformation。设计该数据库的目的是表达设计的访问控制模型,设计的表只包含完成访问控制的部分。
该数据库包括四个基本信息表,即User (用户表) 、Role (角色表) 、Privilege (权限表) 、Object (操作对象) ,它们分别定义了用户、角色、权限、操作对象各个实体的基本信息;
另外有五个关系表,即User_ ToRole (用户2角色关系表) 、User_ To_SubPrivilege (用户2附加权限关系表) 、User_ To_SubPrivi1ege (用户2限制权限关系表) 、Priviliege_ To _Object (权限2操作对象关系表) 。数据库中各表的关系设计。
它对应于认证端的账户概念; Role 表用于定义角色,一个角色代表享有系统相似权限的一部分人; Privilege表用于定义系统的权限;Object 表用于表达系统的功能实体,它和权限通过Privilege_ To _Object (权限2操作对象关系表) 关联起来,用于表达访问控制的结果。
User _ To _Role (用户2角色关系表) 主要用于描述用户到角色的对应,而Role_To_ Privilege (角色2权限关系表) 用于表达角色拥有的权限。
这样,通过用户就能够找到用户到权限的一个对应。同样,User_ To _AddPrivilege (用户2附加权限关系表) 、User_ To_SubPrivilege (用户- 限制权限关系表) 也可以分别得到一个用户到权限的对应。
通过上述对应关系,可以根据模型设计的要求找到一个用户到权限的映射,从而达到访
问控制的目的。笔者通过SQL 语言中各表的连接查询可以表达出模型设计的要求。
3. 3 SAML 组件介绍
该系统中采用了ComponentSpace 公司的SAML 组件,该组件很好地实现了SAMlL 1. 1 协议中所要求的功能。该组件按SAML 的协议层次把组件分成了Asser2tions、Protocol 、Binding、Profile 四部分(名称空间) 。
3. 4 系统实现
3. 4. 1 系统详细模块结构
该系统基于B2S 结构创建,将采用微软的ASP. NET技术作为实现基础,数据库则采用了微软的SQL2000 数据库,消息的传递主要采用网页传值的方式实现。
根据模型设计的要求,系统由认证服务器端( Identity Provider) 网站和应用服务器端( Service Provider) 网站构成。每个页面(aspx 文件) 实现模块中的部分功能,通过各个页面之间的身份信息的传递,最终达到实现模型设计的需求。
为满足统一身份认证的要求,现针对各个页面的功能作一个简要的功能介绍:
(1) 认证端( Identity Provider) 网页。认证端网站中包含页面和其对应的功能描述:CheckImage. aspx (验证码页面) 主要用于随机生成图片码,用户每次登录必须输入不同的图片验证码,防止攻击者采用自动攻击工具不断地尝试用户名和密码,增加了系统的安全性。
增加攻击者尝试猜测密码的难度,也是目前网站比较常用的安全方式之一。Login. aspx (登录页面) 主要是通过访问认证中心数据库中的用户名和密码信息来判断用户的身份是否合法。如果认证成功, 则转到ApplicationInfo. aspx ( 应用系统信息页面) 。
ApplicationInfo. aspx (应用系统信息页面) 主要根据已经通过验证的登录用户,依据数据库中该用户对应的可访问的应用系统信息,在页面上显示,供用户选择登录。用户选择登录后,将生成用户认证断言和票据并保存在应用中,然后把票据传递给应用服务器的Artifact receiver. aspx(票据接受处理页面) ,由应用系统端作进一步处理。
Saml2responder. aspx (断言查询) 的功能主要是根据应用系统端传递过来的请求信息找到对应该请求的断言,并根据该断言把断言结果返回给应用系统端,应用系统端作进一步处理; IdentityInformation (认证端数据库) 的主要功能是保存用户的身份验证数据和应用系统信息的相关信息。
(2) 应用系统端( Service Provider) 。应用系统端网站中包含的页面和其对应的功能:Artifact receiver. aspx (票据接收页面) 根据认证服务器端的票据构造SAML 请求对象,并把查询断言传递到认证服务器;认证服务器根据其保存的断言信息返回查询结果( SAML 返回对象) 给该页面,
应用系统端根据该结果决定是否给用户访问。Defalut . as2px (系统默认页面) 是该页面为应用系统的总控制台,在这里可以访问应用系统的具体功能。如果用户认证成功,则表示用户有权进入该应用系统,该页面将根据对用户的访问控制权利,对用户访问系统的功能作限定。
IdentityIn2formation (应用系统端数据库) 主要功能是保存原有系统的用户身份(账
户) 信息和对应访问控制信息。
3. 4. 2 统一验证流程
该系统通过SAML 协议的Browser/ Artifact 方式进行实现。登录流程大体为:用户在验证服务器端验证通过后,生成断言和票据(Artifact) ,把断言和Artifact 绑定在一起保存到认证服务器端的全局变量(在该系统的实现中为ASP. NET 的Application 全局变量) 。
认证服务器把票据传递给应用服务器,应用服务器根据票据(Artifact) 查询认证服务器所对应的断言,并把查询结果(认证结果) 返回给认证服务器。认证服务器判断结果的有效性和真伪性:如果真实有效,则对用户访问系统授权。
根据登录流程的时间序列图,对各部分的功能和实现给出一个详细的描述:
(1) 用户输入用户名、密码、验证码到认证服务器进行验证,本系统采用传统的用户名和密码方式进行验证。首先,系统验证图片码,如果成功,对输入的密码加密(由于数据库保存的密码是一个MD5 的Hash 值,所以需要对用户输入密码进行MD5 加密) ;
然后,再和数据库中的记录进行比对:如果用户验证成功,系统把通过验证的用户ID 写入Session (会话) ,页面将跳转到ApplicationInfo 页面作进一步处理。
(2) 在ApplicationInfo 页面,系统将根据系统中用户ID 的Session 值对数据库进行查询,找出关联到该用户ID的用户相关系统信息,并展示到页面上供用户选择。
(3) 当用户选择了需要进入的应用系统并确认进入后,系统将根据用户ID 对应于该应用系统的用户帐户产生断言和票据,并把它保存在全局的Application 变量中。
(4) 生成断言后,系统将把票据(Aritfact ) 以URL 传值的方式传到ArtifactReceiver 页面。
(5～8) 由于第( 5) 步到第( 8) 步联系比较紧密, 是SAML 的主要身份信息交换机制,所以在这里把它们放在一起进行说明。首先,ArtifactReceiver 页面在装载时,根据传回来的票据值创建SAML 的Request 对象,
并通过它向应用服务器页面(在这里是SamlResponder 页面) 查询断言;amlresoponder 页面负责处理SAML 请求,并根据票据( Artifact ) 查找Application 中相应的断言, 并构造SAML 的Response 对象,通过认证服务器的私钥进行加密,并返回;
ArtifactReceiver 页面处理SAML 的Response对象,并根据断言的结果,其中断言中包含了统一认证用户的ID 对应到应用系统的账号,给用户访问系统授权(这里采用了ASP. NET 的窗口认证方式,该方式可以保留用户的登录信息到Cookie 中) ;
根据返回的断言结果,赋予访问用户访问应用系统的权利,页面跳转到应用系统页面。这里采用了. NET 的窗口认证方式,可以通过Cookie 保存用户的登录信息,用户在信息有效期内不需要再登录就能进入系统。
(9) 在应用系统端Default 页面,根据认证用户对应的账号和应用系统数据库中关于该账号的访问控制信息,对用户进行授权。在这里,通过从程序中调用SQL 2000 数据库中的存储过程来完成这一复杂的SEL ECT 查询。
3. 4. 3 系统安全性的保证
(1) 由于认证服务器采用用户名2密码的方式对系统进行认证,用户和密码等信息在传输过程中可能被窃听,所以笔者采用SSL 对通信信道加密的方式来保证数据传输的安全性。通过Windows 2003 操作系统,可以很方便地通过对IIS 服务器的配置实现SSL 。
(2) 对于篡改断言的问题。笔者通过认证服务器对发送到应用系统端的断言,用自己数字证书中的私钥签名后再发出。应用服务器端通过公钥验证签名,可以确保断言的真实性和不可抵赖性。
(3) 重发和中间人攻击。笔者采用Browser/ Artifact方式时,每次生成的Artifact 均不相同;而且,在使用过Ar2tifact 后会删除与断言之间的映射,从而使重播无效。
(4) 为了保护用户密码的私隐性, 所有的密码都用MD5 算法进行了Hash。这样,数据库管理员就无法看到用户的明文密码。
(5) 采用了图片验证码,防止攻击者对密码进行试探性攻击,使攻击者猜测用户密码的难度加大。
4 结束语
通过对目前流行的统一认证机制原理进行分析和比较,设计了比较适合企业应用、具有较高灵活性的身份认证机制模型。本文根据模型设计的要求,结合现有技术手段对模型进行了实现。该系统充分满足了企业的实际要求。
因篇幅问题不能全部显示，请点此查看更多更全内容