网关的授权验证

网关的授权验证 版本 1.0 历史记录 作者 日期 版本 原因 郭振 2010-08-12 1.0 创建文档 41简介 41.1目的 41.2范围 41.3定义和缩写 41.4依赖文档 41.5参考文献 42 SSO基本原理 52.1 SSO的架构 52.2 系统交互角色 62.3 sso组件包 73 邮件网关的授权验证 73.1 原理 83.2 邮件网关的sso服务端组件 93.3 邮件网关的sso客户端组件 103.4 邮件网关的sso组件对IE客户端的支持 113.5 对js跨域的支持 114 总结 1简介 1.1目的 本文档介绍网关的授权验证模块，主要涵盖SSO的实现原理，网关与SSO服务器的交互流程。 1.2范围 软件开发，系统运营等相关人员 1.3定义和缩写 SSO： Single Sign On, 单点登录。 1.4依赖文档 SSO的相关文档，可以向SSO组咨询 1.5参考文献 2 SSO基本原理 在多系统的应用中，各个系统单独维护用户登录模块，这造成用重复开发，并且难于集成。因此SSO应运而生，它主要将各个系统的验证授权模块分离出来，集中到一点进行验证和授权。这样不仅便于系统集成和维护，而且增强了用户体验， 用户只需登陆一次，便可在多个系统间进行访问。 2.1 SSO的架构 1．客户端通过sso客户端，向sso服务器提交用户名和密码，并提交要访问的目标服务的地址，sso服务器根据用户名密码进行登录认证。 2．如果Sso服务器登录认证成功，返回给客户端两个票据：TGT和ST。TGT代表用户，相当于这个用户的身份证。 ST代表服务门票，它是针对访问特定目标服务产生的票据。 3．客户单在url中带着ST（即这个目标服务的门票），访问目标服务。 4．在进入目标服务前，请求被sso服务端组件过滤，它提取ST发给sso服务器进行ST的验证。 5．Sso服务器验证ST票据，如果验证成功，返回给目标服务器用户的信息（包括用户名），然后sso服务端组件将用户信息存入session。 2.2 系统交互角色 如架构图所示，系统共分为3个角色，2个组件。绿色表示角色，蓝色表示sso组件。 1． 客户端： 目标服务的访问者和数据消费者者。 它可以是浏览器，js程序，java程序，php程序，甚至是一个应用服务（它在访问别的服务时，本身又是客户端）。 当客户端为浏览器时，无需sso客户端组件，浏览器通过url和cookie存储tgt和st票据。 当客户端为程序时(这里以java为例)需要sso客户端组件。Java程序无需关心sso的相关流程直接访问目标服务，sso客户端组件负责和sso服务器的通讯并保存tgt和st票据。 2． 目标服务器：目标服务器向外提供服务。在进入目标服务前，请求被sso服务端组件拦截，它负责和sso服务器通讯进行st的验证，并将用户信息和验证成功信息保存到session。当客户单第二次请求到来时，sso服务端组件优先进行session比对，如果session存有验证通过信息，就不再进行验证，直接放行通过。 3． Sso服务器：负责针对用户名密码认证，认证成功后发给身份信息tgt。 并对该tgt是否有权访问目标服务进行认证，通过分发能够访问目标服务的票据st。 2.3 sso组件包 1. 目前sso组提供了服务端组件包，casclient.jar。 它以Servlet Filter的方式集成到应用服务中。Web.xml配置如下： CASFilter edu.yale.its.tp.cas.client.filter.CASFilter edu.yale.its.tp.cas.client.filter.loginUrl http://172.20.30.173:8080/sso/login edu.yale.its.tp.cas.client.filter.validateUrl http://172.20.30.173:8080/sso/proxyValidate edu.yale.its.tp.cas.client.filter.gateway true edu.yale.its.tp.cas.client.filter.serverName 172.20.30.156:8080 2. sso客户端组件：目前没有统一的sso客户端组件，需要项目开发人员遵循sso相关流程自行开发，主要的关键步骤包括，拿tgt用户身份票据和目标服务地址向sso索取应用票据ST； 首次访问目标服务附带ST票据，响应返回后保存sessionid。后续访问访问附带sessionid。 3． casclient.jar的升级包casclient_ex.jar。 使用casclient.jar，如果在web.xml 配置目标服务地址为具体IP：172.20.30.173。那么当为客户端以域名访问（例如www.ceopen.cn 指向172.20.30.173）时会出现ticket invalid，原因是验证是service地址是IP形式，而请求票据时地址是域名，导致两次的service地址不一致。 采用casclient_ex.jar扩展包后边解决了这一问，而且可以有多个域名指向同一个IP。 3 邮件网关的授权验证 邮件网关同样采用SSO登录认证授权模式。根据邮件网关的特点，我们没有采用casfilter.jar组件包，而是自行从新开发了sso 服务端和客户端相关组件。 邮件网关采用REST风格的架构，应用restlet开源框架包，因此sso服务端和客户端组件是以restlet为基础开发，主要采用了org.restlet.Filter 和 org.restlet.Client两个类。 3.1 原理 通过Http的头信息进行验证信息的传输。在sso体系中，核心的是进行ST的传输，例如客户端向服务端发送ST，服务端向sso 服务器验证ST。在sso组提供的组件中，都是将st信息放入URL进行传输的，没有充分利用http协议本身的特性。 在网关自己开发的sso组件中，完全按照http协议进行用户认证的实现。 主要利用Authorization这个头信息，实现票据在个系统之间的传输，这样不仅符合http，而且是URL规格化，符合REST的要求。验证信息的具体格式如下： · CE_SSO 认证名称 · ST-dsopi23802834023034是从目标服务票据 · http://172.20.30.173:8080/sso：表明该票据是从哪台sso服务器获得的。 ST是一次性的，即ST验证过一次后，sso 服务器便删除该票据。在第一次请求时，sso 服务器会对ST进行验证，成功后存入session。 后续请求，客户端还是在Authorization中带着原ST，这是sso服务端组件会优先从session中查找ST，如果存在则通过。因此在后续的请求中，ST是作为一个sessionId来使用的。 3.2 邮件网关的sso服务端组件 服务端组件采用Filter，在请求进入最终服务前进行过滤操作，完成和sso服务器的相关通讯，实现票据的验证和用户信息的存储。该模块以配置的方式集成到服务器。以网挂应用为例，配置如下： 1． 将组件 加入restlet路由链中 在被保护的资源前加入ssoguard。例如上例，userOwnerRouter为被保护的资源。 2. 配置组件url地址参数 组件验证需要和sso服务器通讯，因此需要设置sso服务器的登录，验证地址。以网关为例，配置文件wssso.properties。 edu.yale.its.tp.cas.client.filter.loginUrl=http://172.20.30.173:8080/sso/login edu.yale.its.tp.cas.client.filter.validateUrl=http://172.20.30.173:8080/sso/proxyValidate edu.yale.its.tp.cas.client.filter.serviceUrl=172.20.30.173:8090 2． 将组件包加入classpath wsrest_sso_server.jar 3.3 邮件网关的sso客户端组件 邮件网关向外提供webservice服务，它的客户主要是webmail邮件应用服务，这里为方便应用服务访问网关开发了sso客户端组件。 该组件主要继承了org.restlet.Client类，主要加入了和sso通讯以及维护票据等逻辑。 使得webmail开发人员在访问网关服务时，想直接使用Client发送http请求一样简单，做到了sso相关细节的透明。使用方法如下： 1． 将sso客户端组件加入classpath wsrest_sso_client.jar ssowsclient.jar 2． 配置sso服务器地址 组件在获取票据时需要和sso服务器通讯。 需要两处配置 在web.xml中加入servlet。 WebServiceSSOServlet com.sitechasia.wssso.client.WebServiceSSOServlet WebServiceSSOConfig /WEB-INF/wsssoclientconfig.xml 1 在/WEB-INF/目录中加入配置文件wsssoclientconfig.xml： http://localhost:8080/sso/UserAuthAndGrantTgt http://localhost:8080/sso/STValidateAuthentication com.sitechasia.wssso.client.common.DefaultUserInfoGetterImpl http://localhost:8080/sso/UserAuthAndGrantTgtSt 3． 访问网关的程序片段 这段代码是在webmail应用的servlet里写的。因为webmail邮件应用本身也被sso保护，当以个用户请求能够进入webmail应用内部，到达业务逻辑的servlet时，说明已经通过sso认证，并且在session中存有了用户信息（即tgt）。在这种情况下，进行如上编码。 第一步，获取HttpServletRequest，通过它可以获得session中的tgt用户身份。 第二步，构造客户端 SSOClientHelper，它即sso客户端组件。在用该客户端组件向网关发送请求时，会自动先拿tgt与sso服务器进行交互，获取ST，并且对后续请求的标志维护。 第三步，用SSOClientHelper发送request。 开发人员无需关心sso通讯，票据维护等细节，用SSOClientHelper可以透明的实现外部系统的http请求。 3.4 邮件网关的sso组件对IE客户端的支持 大部分情况下，网关的客户是其他应用服务中的程序。一种情况例外，最终用户下载附件的时候是直接从网关下载，因此邮件网关的sso组件还要提供对IE浏览器的支持。因为浏览器不受程员控制，无法Authorization中写入ST，它仍是在URL中传输的，这就造成格式的不匹配。 网关采用了filter的原理来解决这一问题。 在进入ssoguard前，首先将请求送入cookieFilter过滤器。改过滤器起到适配的作用，负责将浏览器请求模拟成程序发来的请求（即，将ST规格化到http头信息中，并做一些状态记录），再传递给ssoguard，然后将响应转换成浏览器格式（即将ST的值进行Base64编码放入cookie）。 3.5 对js跨域的支持 目前js跨域采用jquery框架，具有如下限制： · 只能发送GET请求 · 不能够带http 头信息，不能接收http头信息 · 只能处理响应体，而且必须符合格式: jsoncallbakc2398{…….}; 同样采用filter的方法，在sso 服务端组件实现对js跨域的支持。在JsFitler中对js跨域请求进行格式转换。 Js跨域访问，所有提交数据以参数方式放入URL中，主要参数有： · _Token: 经过Base64编码后的ST值。 · _Json: 提交的数据体 · _Method: 提交的请求方法 · Jsoncallback：jsoncallback值 在jsFilter中按照jsoncallbakc2398{…….}格式，将响应状态，媒体类型，消息体数据进行拼装，主要的json key如下： · Status：响应状态 · ContentType: 媒体类型：若果是xml媒体，则内容是经过base64编码，如果是json媒体，不编码 目前在js跨域实现中，_Token的维护由js客户单负责。如果_Token访问有效，js客户端保存_Token,并在下次请求时，如果无效js负责重新获取_Token。 3.6 多sso认证支持 在但sso服务器的情况下，客户端和服务端的sso地址的保持一致即可。但实际应用中会有多sso的情况，这就要保证获取ST和验证ST是同一台服务器。邮件网关采用以下两种方式实现多sso认证。 1． 在ST后附带sso 服务器地址信息，格式如下： ST-lsdk234234023984;http://172.20.30.173:8080/sso 客户端将ST和获取ST的sso地址以分号间隔拼成整体，作为Authorization的值发送给服务端，sso服务端组件会提取ST值和sso 地址值，按照客户端制定的sso地址进行验证。 2 使用openId区分sso 服务器。客户端发送ST的时候，会在Url中附带openId参数。例如， http://172.20.30.173:8090/mailgateway/1.0?ticket=ST-dslkj234234?openId=sso.kaopu.com. 在服务器端维护一张openId映射表，位于classpath:/conf/sso_id_map.properties。服务器端组件会根据sso.kaopu.com查找具体sso服务器地址。 具体配置值由客户单提供。 4 总结 网关sso验证的核心是使用http头信息Authorization进行验证信息ST的交互。 在这个过程中，sso服务端组件主要负责两件事，根据ST到session中查询，如果存在表明已经通过；如果不存在则进行ST验证。验证通过返回状态200.；失败返回401。Sso客户端负责：获取并发送ST。若果响应时200，则保存ST用于下次请求；如果失败，则清除ST，并重新获取ST。而且客户端要控制重新申请ST的时间间隔。 程序访问和js跨域访问中，两种情况原理是完全一样的，即服务器端和客户端只针对一种票据ST来交互。 服务端根据ST查询session或验证，客户端根据状态值进行ST的维护。这个过程ST既是验证票据也是session票据。 而浏览器则不同，ST的维护时放由服务器端负责的，主要通过cookie值的设定来控制浏览器的ST的获取，重发。 SSO服务器 (验证和授权中心) 客户端 目标服务器 Sso客户端 Sso服务端 1 2 33 43 53 63 � HYPERLINK "http://172.20.30.173:8080/sso/login" ��http://172.20.30.173:8080/sso/login�：sso服务器登录地址 � HYPERLINK "http://172.20.30.173:8080/sso/proxyValidate" ��http://172.20.30.173:8080/sso/proxyValidate�：sso服务器ST票据验证地址 172.20.30.156:8080：目标服务本身的地址 edu.yale.its.tp.cas.client.filter.loginUrl ：sso服务器的登录地址 edu.yale.its.tp.cas.client.filter.validateUrl：sso服务器的验证地址 edu.yale.its.tp.cas.client.filter.serviceUrl：本服务器的地址 HttpServletRequest httpRequest =this.getRequest(); SSOClientHelper clientHelper = new SSOClientHelper(httpRequest); String urlTo = destinationUrl; Request request = new Request(Method.POST, urlTo); Representation rep = new StringRepresentaion("hello world"); Request.setEntity(rep); ClientHelper.handle(request); Authentication：CE_SSO ST-dsopi23802834023034;http://172.20.30.173:8080/sso