华为 AnyOffice移动办公解决方案 单点登录技术白皮书

作者: 点击次数:417 添加时间:2017-3-15 19:38:49

       摘 要:本文档介绍与单点登录相关的一些通用协议,然后分析 AnyOffice 的单点登录使用场景和 实现方式。 文档管理: 文档使用:技术白皮书的使用对象是AnyOffice内部开发人员和市场技术支撑人员,不适宜直接对 外部客户发布。 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 6 共 44 1 单点登录简介 单点登录(Single Sign On),简称为 SSO,是目前比较流行的企业业务整合的解决方案之一。 SSO 的定义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。 较大的企业内部,一般都有很多的业务支持系统为其提供相应的管理和 IT 服务。例如财务系统 为财务人员提供财务的管理、计算和报表服务;人事系统为人事部门提供全公司人员的维护服务; 各种业务系统为公司内部不同的业务提供不同的服务等等。这些不同的系统往往是在不同的时期建 设起来的,运行在不同的平台上;也许是由不同厂商开发,使用了各种不同的技术和标准。每一个 应用系统在运行了数年以后,都会成为不可替换的企业 IT 架构的一部分。 AnyOffice 移动办公系统部署到企业环境中后,主要解决各种业务系统在移动终端上安全地、 方便地使用,为了提高在移动终端上的用户使用体验,需要实现在移动终端上不同业务支持系统的 应用与 AnyOffice 移动应用之间的单点登录功能。 当前 SSO 技术已经比较流行,各种实现 SSO 功能的产品或者开源项目以及实现 SSO 功能的协 议和规范都已经比较多,本文将对几种与 SSO 相关并且实现的比较广泛的协议规范进行简单介绍, 让读者对 SSO 的原理和协议有一些基本了解,然后再介绍 AnyOffice 的单点登录实现方案。 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 7 共 44 2 现有单点登录协议介绍 2.1 CAS 协议 CAS(Central Authentication Service) 协议是由 Yale 大学提出的, 目前最新版本为 3.0。Yale 大 学同时提供了一个实现该协议的开源项目,名称也是 CAS,目前 CAS 开源项目最新版本为 4.0。CAS 4.0 开源项目除了支持 CAS 协议外,还支持 OpenID、OAuh、SAML 等协议。CAS 开源项目除了包 含持 CAS Server 组件外,还包含支持多种客户端的 CAS 客户端插件,这些客户端包括 Java、.Net、 PHP、Apache 等。CAS 开源项目以及 CAS 协议实现目前被广泛使用。 从结构体系看, CAS 协议包括两部分: CAS Server 和 CAS Client 。  CAS Server :CAS Server 负责完成对用户的认证工作 , 需要独立部署 , CAS Server 会处 理用户名 / 密码等凭证 (Credentials) ;  CAS Client :负责处理客户端对受保护资源的访问请求,需要对请求方进行身份认证时, 重定向到 CAS Server 进行认证。(原则上,客户端应用不再接受任何的用户名密码等 Credentials )。 CAS Client 与受保护的应用部署在一起,以 Filter 方式保护受保护的资 源。 基础模式 SSO 访问流程主要有以下步骤: AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 8 共 44 如上图:CAS Client 与受保护的客户端应用(web server)部署在一起,以 Filter 方式保护 Web 应用的受保护资源,过滤从客户端过来的每一个 Web 请求。同时,CAS Client 会分析 HTTP 请求 中是否包含请求 Service Ticket( ST 上图中的 Ticket) ,如果没有,则说明该用户是没有经过认证的; 于是 CAS Client 会重定向用户请求到 CAS Server ( Step 2 ),并传递 Service (要访问的目的 资源地址)。 Step 3 是用户认证过程,如果用户提供了正确的 Credentials , CAS Server 随机产生 一个相当长度、唯一、不可伪造的 Service Ticket ,并缓存以待将来验证,并且重定向用户到 Service 所在地址(附带刚才产生的 Service Ticket ) , 并为客户端浏览器设置一个 Ticket Granted Cookie ( TGC ) ; CAS Client 在拿到 Service 和新产生的 Ticket 过后,在 Step 5 和 Step6 中与 CAS Server 进行身份核实,以确保 Service Ticket 的合法性。 2.1.1 重要术语 service ticket:服务票据,服务的惟一标识码 , 由 CAS Server 产生并经 Http 传送给 web 客户 端浏览器,然后通过客户端浏览器到达 web 服务器端;一个特定的服务(web 服务器)只能有一个 惟一的 ST。ST 必须是一次性的,也就是一个合法的 ST 在 CAS Server 上首次验证之后,后续再次 使用这个 ST 再去验证将无法通过。CAS Server 对一个 ST 无法是否验证通过,后续对相同 ST 的验 证都返回失败的验证结果。ST 的推荐有效期不超过 5 分钟,要求 CAS Server 必须支持超过 32 字节 的 ST,推荐支持超过 256 字节的 ST。ST 必须具有随机性,防止被猜测。 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 9 共 44 login ticket:简写 lt,是 CAS Server 分配并在” 凭据请求者/login”报文中传递给客户端再由客 户端在” 凭据接收者 login”报文中回传给 CAS Server。CAS Server 对 lt 进行验证,以防止 login 报 文的重放攻击。lt 是一次有效的,当尝试在 CAS Server 验证一个 lt 之后,无论验证结果如何,该 lt 将失效,后续无法再在 CAS Server 上验证通过。” 凭据请求者/login”报文和” 凭据接收者 login”报 文请参见后续章节的描述。 ticket-grant cookie:这是一个 http 的 cookie,用于标识在浏览器和 CAS Server 之间建立的一个 单点登录会话。浏览器通过携带该cookie从而可以从CAS Server上为不同的service 申请不同ticket, 而不用用户每次都输入账号密码等凭据。ticket-grant cookie 的作用域应尽可能设置的严格,应包含 随机值避免在失效前被猜测破解。 2.1.2 CAS 协议介绍 CAS协议最新版本为3.0,主要是对CAS Server的实现方式进行定义,包括交互过程中的/login、 /logout、/validate、/servicevalidate 等。本文对 CAS 规范进行基本的介绍,对从 CAS2.0 开始支持的 代理模式不进行描述。 CAS Server 需要响应两种/login 请求,一种/login 请求报文是第三方要求 CAS Sever 提供认证请 求页面,以便用户输入认证信息-CAS 规范中称之为凭据请求者 login;另外一种/login 请求报文是 携带了用户认证信息,需要 CAS Server 处理认证请求并返回认证结果的报文—CAS 规范中称之为 凭据接收者 login。 1) 凭据请求者 login http 请求中需要携带以下参数:  service【可选】: client请求的应用,一般情况下是一个网站的URL。如果单点登录成功, 客户端将会被重定向到service URL。  renew【可选】:如果该参数被设置,那么无论客户端是否携带了单点登录参数,CAS Server 都会要求用户输入认证信息。该参数和“gateway”参数相互冲突,应该二选一。  gateway【可选】:如果该参数被设置,CAS Server不要求用户输入认证信息。如果该参数 被设置但无可用的单点登录信息,客户端将被重定向到service URL,但没有ticket。  method【可选,CAS3.0】:默认情况下,通过http redirect发送.login的响应报文,但通过 mothod参数可以指定POST响应方式。但最终的响应方式是由CAS Server来决定。 /login 举例: AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 10 共 44  一个简单的请求 https://cas.example.org/cas/login?service=http%3A%2F%2Fwww.example.org%2Fservice  明确要求不提示输入账号密码 https://cas.example.org/cas/login?service=http%3A%2F%2Fwww.example.org%2Fservice&gat eway=true  总是要求输入账号密码 https://cas.example.org/cas/login?service=http%3A%2F%2Fwww.example.org%2Fservice&ren ew=true  使用POST方式代替redirect方式 https://cas.example.org/cas/login?method=POST&service=http%3A%2F%2Fwww.example.org %2Fservice CAS Server 接收到/login 请求后,根据具体情况返回响应消息,可能要求用户输入账号密 码,如果 Client 之前已经和 CAS Server 建立了 SSO 会话,则可能直接返回认证结果。如果 CAS Server 要求客户端提供用户账号密码,则需要向客户端返回一个 form,必须包含“username”、“password”、 “lt”,可选包含“warn”。客户端必须要使用 POST 方法提交这个 form。 2) 凭据接收者 login http 请求报文中包含以下参数:  service【可选】:client请求的应用,一般情况下是一个网站的URL。如果单点登录成功, 客户端将会被重定向到Server URL。  warn【可选】:如果设置了该参数,在单点登录到其他service时,必须给用户弹出提醒信 息。  method【可选,CAS3.0】:默认情况下,通过http redirect发送.login的响应报文,但通过 mothod参数可以指定POST响应方式。但最终的响应方式是由CASServer来决定。 如果使用账号密码进行认证,则还需要以下参数:  username [必选] :用户名  password [必选] :t密码  lt [必选] :登录用的ticket,由CAS Server在凭据请求者login的响应报文中发送给客户端, 并由客户端在凭据接收者login请求报文中提交给CAS Server。 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 11 共 44  rememberMe [可选,CAS 3.0]:如果这个参数被设置,CAS Server可能会产生一个超长期 有效的TGC,但最终是否产生还需要根据CAS Server的配置来决定。 CAS Server 接收并处理凭据接收者login请求之后,如果认证通过,则向web 浏览器客户端返 回serviceTicket。 3) logout Logout 交互销毁客户端和 CAS Server 之间建立的单点登录会话,将 ticket-grant cookie 失效。 http 请求报文中包含以下参数:  service [可选,CAS 3.0]:如果填写了这个参数,在执行完logout操作之后,浏览器需要被 重定向到Service指定的URL上。 在CAS1.0和2.0 规范中,CAS Server在执行logout之后,显示一张页面提示用户已经完成logout。 如果请求报文中有“url“参数,还需要在页面上提供一个 URL 链接,指向 url。 在 CAS3.0 规范中,如果有 service 参数,则 CAS Server 将浏览器重定向到 service 指定的 web 页面,如果没有 service 参数,则显示一张页面提示用户已经完成 logout。 4) validate [CAS 1.0] /validate 验证 service ticket 是否合法。 /validate 是 CAS1.0 规范的一部分。这是早期版本的实 现,本文不详细描述。 5) serviceValidate [CAS 2.0] /serviceValidate 验证 service ticket 的合法性,并返回携带 XML 的响应。如果客户端请求获得 proxy-granting tickets,CAS Server 必须在/serviceValidate 报文中同时返回 proxy-granting tickets。如 果 CAS Server 收到一个 proxy ticket ,不允许返回认证成功的响应,而应该返回认证失败并携带合 适的错误码的响应。 请求报文中携带以下参数:  service [必选]:标识所验证的ticket是哪个service拥有的。  ticket [必选]:请求被验证的ticket  renew [可选]:如果这个参数被设置,那么只有对首次认证通过后所颁发的ticket才能够被 验证通过,其他通过TGC从CAS Server所申请到的ticket将无法通过验证。 一个简单的请求报文例子如下: https://cas.example.org/cas/serviceValidate?service=http%3A%2F%2Fwww.example.org%2Fservice&tick et=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 12 共 44 要求仅验证通过使用用户原始认证信息请求的 ticket 的例子如下: https://cas.example.org/cas/serviceValidate?service=http%3A%2F%2Fwww.example.org%2Fservice &ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7&renew=true 响应消息如下: /serviceValidate 的响应消息中会返回 xml 格式的内容,举例如下: 一个验证成功的例子 username PGTIOU-84678-8a9d... 一个验证失败的例子: Ticket ST-1856339-aA5Yuvrxzpv8Tau1cYQ7 not recognized` 在 CAS3.0 规范中,响应消息中还可以增加 attributes [CAS 3.0] 字段, attributes 用于返回用户 相关的属性。例如: username John Doe Mr. AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 13 共 44 jdoe@example.orgmailto:jdoe@example.org staff faculty PGTIOU-84678-8a9d... 6) samlValidate [CAS 3.0] CAS3.0 支持/samlvaldate,必须通过 HTTP POST 方式向 CAS Server 发送一个符合者 SAML1.1 规范的验证请求报文。CAS server 必须返回一个符合 SAML1.1 规范的响应报文。 SAML request 报文中必须包含以下参数:  RequestID [必选] – 请求报文的唯一标识ID  IssueInstant [必选] – 请求报文的时间戳  samlp:AssertionArtifact [必选] –请求对其进行验证的ticket 一个/samlValidate POST request 例子如下: POST /cas/samlValidate?ticket= Host: cas.example.com Content-Length: 491 Content-Type: text/xml AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 14 共 44 ST-1-u4hrm3td92cLxpCvrjylcas.example.com 一个 SAML response 例子如下: https://some-service.example.com/app/ AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 15 共 44 johnq urn:oasis:names:tc:SAML:1.0:cm:artifact 12345 uugid=middleware.staff,ou=Groups,dc=vt,dc=edu staff ACTIVE johnq AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 16 共 44 urn:oasis:names:tc:SAML:1.0:cm:artifact 一个实现 CAS 协议的实际交互过程可能如下图所示: AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 17 共 44 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 18 共 44 2.1.3 CAS 的安全性 CAS 规范中重要信息的传输安全性仅仅依赖于 SSL。 TGC 安全性 对于一个 CAS 用户来说,最重要是要保护它的 TGC ,如果 TGC 不慎被 CAS Server 以外 的实体获得, Hacker 能够找到该 TGC ,然后冒充 CAS 用户访问所有授权资源。TGC 是 CAS Server 通过 SSL 方式发送给终端用户,通过 SSL 协议保证 TGC 在网络传输过程中的安全性。 在 TGC 被保存到 web 浏览器中时,必须限定 TGC 的有效作用域,并且限定 TGC 的有效时间。 ST 安全性 ST ( Service Ticket )可能是通过 Http 传送的,因此网络中的其他人可以 Sniffer 到其他人 的 Ticket 。 CAS 通过以下几方面来使 ST 变得更加安全(事实上都是可以配置的): 1、 ST 只能使用一次 ST 必须是一次性的,也就是一个合法的 ST 在 CAS Server 上首次验证之后,后续再次使用这个 ST 再去验证将无法通过。CAS Server 对一个 ST 无法是否验证通过,后续对相同 ST 的验证都返回 失败的验证结果。。 2、 ST 在一段时间内失效 CAS 规定 ST 只能存活一定的时间,然后 CAS Server 会让它失效。默认有效时间为 5 分钟。 3、 ST 是基于随机数生成的 ST 必须足够随机,如果 ST 生成规则被猜出, Hacker 就等于绕过 CAS 认证,直接访问 对 应的 服务。 2.2 SAML 协议 SAML 即安全断言标记语言,英文全称是 Security Assertion Markup Language。它是一个基于 XML 的标准,用于在不同的安全域(security domain)之间交换认证和授权数据。在 SAML 标准定义 了身份提供者(identity provider)和服务提供者(service provider),这两者构成了前面所说的不同的安 全域。 SAML 是 OASIS 组织安全服务技术委员会(Security Services Technical Committee)的产品。 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 19 共 44 2.2.1 SAML 简介 SAML(Security Assertion Markup Language)是一个 XML 框架,可以用来传输安全声明。比 如,两台远程机器之间要通讯,为了保证安全,我们可以采用加密等措施,也可以采用 SAML 来传 输,传输的数据以 XML 形式,符合 SAML 规范,这样我们就可以不要求两台机器采用什么样的系 统,只要求能理解 SAML 规范即可,显然比传统的方式更好。SAML 规范是一组 Schema 定义。 SAML 主要包括三个方面: 1.认证申明。表明用户是否已经认证,通常用于单点登录。 2.属性申明。表明某个 Subject 的属性。 3.授权申明。表明某个资源的权限。 用最简单的话来描述 SAML 协议,SAML 就是客户端向服务器发送 SAML 请求,然后服务器 返回 SAML 响应,数据的传输方式符合 SAML 规范,传输的数据格式也要符合 SAML 规范的 XML 格式。 SAML 消息报文可以建立在 SOAP 上传输,也可以建立在其他协议上传输。 SAML 的规范由几个部分构成:SAML Assertion,SAML Prototol,SAML binding 等 SAML 定义了六类语句: 1) 认证(Authentication):主体已登录。例如,用于认证的 SAML 断言看起来可能象下面 这样: fcohen@pushtotest.com logged in at 2003-02-06T19:22:09Z 2) 属性(Attribute):标识主体的特性。例如,fcohen@pushtotest.com 拥有 Admin 角色。 3) 权限决定(Authorization decision):声明允许某个主体对某个资源执行操作。例如, fcohen@pushtotest.com 被授权 GET http://www.pushtotest.com/ptt/kits/index.html。 4) 断言属性(Assertion attribute):一个可选机制,使行业团体能够定义特定于其行业的属 性。 此外,SAML 定义了由某个断言中的语句共享的断言的属性,包括: 5) 版本属性(Version attribute):标识了断言所遵循的 SAML 规范的主版本和次版本。 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 20 共 44 SAML 还定义了可选的 条件元素以限制权限请求的有效性。例如,如果 SAML 标记 NotBefore 或 NotOnOrAfter 指定的以 UTC 编码的日期,那么它可能是有效的。 6) XML 签名(XML Signature):SAML 定义了一个 XML 签名(XML Signature)元素以 标识认证中心。该元素可以包含一个带有公钥、到期日和使用策略的 X509 证书。XML 签 名还包含签名值本身,签名值是由认证中心为元素内容生成的。可以使用 X509 证书中权 威机构的公钥信息来验证签名。通常,SAML 的复杂性在于部署基于 SAML 的软件,以 及设置公钥基础结构(PKI)环境和数字证书。 2.2.2 SAML 协议交互过程 根据 Service Provider( 以下简称 SP) 和 Identity Provider( 以下简称 IDP) 的交互方式, SAML 可以分为以下几种模式:一种是 SP 拉方式,一种是 IDP 推方式。 在 SAML 中,最重要的环节是 SP 如何获取对 Subject 的断言, SP 拉方式是 SP 主动到 IDP 去了解 Subject 的身份断言,而 IDP 推方式则是 IDP 主动把 Subject 的身份断言通过某种途 径告诉 SP。 SAML 的 POST/Artifact Bindings 方式(即 SP 拉方式) 该方式的主要特点是 SP 获得客户端的凭证 ( 是 IDP 对 Subject 的一种身份认可 ) 之后,主 动请求 IDP 对 Subject 的凭证的断言。如下图所示: Subject 是根据凭证去访问 SP 的。凭证代 表了 Subject 的身份。 Subject 访问 SP 的受保护资源, SP 发现 Subject 的请求中没有包含任何的授权信息,于是 它重定向用户访问 IDP. AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 21 共 44 协议执行: 1, Subject 向 IDP 请求凭证 ( 方式是提交用户名 / 密码 ) 2, IDP 通过验证 Subject 提供的信息,来确定是否提供凭证给 Subject 3, 假如 Subject 的验证信息正确,他将获取 IDP 的凭证以及将服务请求同时提交给 SP 。 4, SP 接受到 Subject 的凭证,它是提供服务之前必须验证次凭证,于是,它产生了一个 SAML 请求,要求 IDP 对凭证断言 5, 凭证是 IDP 产生的,它当然知道凭证的内容,于是它回应一个 SAML 断言给 SP 6, SP 信任 IDP 的 SAML 断言,它会根据断言结果确定是否为 Subject 提供服务。 SAML 的 Redirect/POST Bindings 方式 ( 即 IDP 推方式 ) 该方式的主要特点是, IDP 交给 Subject 的不是凭证,而是断言。 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 22 共 44 1 , Subject 访问 SP 的授权服务, SP 重定向 Subject 到 IDP 获取断言。 2 , IDP 会要求 Subject 提供能够证明它自己身份的手段 (Password , X.509 证书等 ) 3 , Subject 向 IDP 提供了自己的帐号密码。 4 , IDP 验证密码之后,会重订向 Subject 到原来的 SP 。 5 , SP 校验 IDP 的断言 ( 注意, IDP 会对自己的断言签名, SP 信任 IDP 的证书,因此,通过校验签名,能够确信从 Subject 过来的断言确实来自 IDP 的断言 ) 。 6 ,如果签名正确, SP 将向 Subject 提供该服务。 2.2.3 SAML 安全性 由于 SAML 在两个拥有共享用户的站点间建立了信任关系,所以安全性是需考虑的一个非常重 要的因素。SAML 中的安全弱点可能危及用户在目标站点的个人信息。SAML 依靠一批成熟完善的 安全标准,包括 SSL 和 X.509,来保护 SAML 源站点和目标站点之间通信的安全。源站点和目标站 点之间的所有通信都经过了加密。为确保参与 SAML 交互的双方站点都能验证对方的身份,还使用 了证书。 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 23 共 44 2.3 OAuth2.0 协议 OAuth 是一个关于授权(authorization)的开放网络标准,在全世界得到广泛应用,目前的版本 是 2.0 版(RFC6749)。OAuth2.0 不能兼容 OAuth1.0,目前普遍采用的是 OAuth2.0。 2.3.1 使用场景 假设有一个"云冲印"的网站,可以将用户储存在 Google 的照片,冲印出来。用户为了使用该服 务,必须让"云冲印"读取自己储存在 Google 上的照片。问题是只有得到用户的授权,Google 才会 同意"云冲印"读取这些照片。那么,"云冲印"怎样获得用户的授权呢? 传统方法是,用户将自己的 Google 用户名和密码,告诉"云冲印",后者就可以读取用户的照片 了。这样的做法有以下几个严重的缺点。 (1)"云冲印"为了后续的服务,会保存用户的密码,这样很不安全。 (2)Google 不得不部署密码登录,而我们知道,单纯的密码登录并不安全。 (3)"云冲印"拥有了获取用户储存在 Google 所有资料的权力,用户没法限制"云冲印"获得授权 的范围和有效期。 (4)用户只有修改密码,才能收回赋予"云冲印"的权力。但是这样做,会使得其他所有获得用 户授权的第三方应用程序全部失效。 (5)只要有一个第三方应用程序被破解,就会导致用户密码泄漏,以及所有被密码保护的数据 泄漏。 OAuth 就是为了解决上面这些问题而诞生的。 2.3.2 重要术语 在 OAuth2.0 中定义了以下四种 Role: 资源所有者(resource owner):能够对受保护资源进行授权的实体,当该实体是一个自然人时, 通常也被称为最终用户。 资源服务器( resource server):保存受保护资源的服务器,资源服务器对外提供对受保护资源的 请求响应。 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 24 共 44 客户端(client):代表资源所有者发起资源请求的应用。客户端有可能是一个 web 网站、一个运 行在终端上应用等。 授权服务器(authorization server):向客户端发放 access token 的服务器。 OAuth 2.0 规范范文不包含资源服务器和授权服务器之间的交互定义,实际应用中资源服务器 和授权服务器可能是同一个服务器。 2.3.3 OAuth2.0 协议交互过程 Client Resource Owner Authorization Server Resource Server A Authorization request B Authorization Grant C Authorisztion Grant & Client Credentials D Access Token E Access Token F Protected Resource 图中描述了 OAuth2.0 规范定义的交互框架,其他交互过程都是在此基础上进行的演变。 (A)用户打开客户端以后,客户端要求用户给予授权。 (B)用户同意给予客户端授权。 (C)客户端使用上一步获得的授权,向认证服务器申请令牌。 (D)认证服务器对客户端进行认证以后,确认无误,同意发放令牌。 (E)客户端使用令牌,向资源服务器申请获取资源。 (F)资源服务器确认令牌无误,同意向客户端开放资源。 OAuth2.0 规范在逻辑上是 Client 向 Resource Owner 申请资源访问授权,但实际实现时,一般 都是推荐使用授权服务器代替资源所有者发放访问授权(Authorization Grant),也就是说 Client 是 直接和授权服务器交互,由授权服务器代表资源所有者进行授权。 OAuth2.0 作为一个授权规范,重点在于如何获得用户的授权,规范定义了四种授权方式: 1. Authorization Code AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 25 共 44 2. Implicit 3. Resource Owner Password Credentials 4. Client Credentials Authorization Code 方式适合于有 server 端的应用授权。Client 引导资源所有者访问授权服务器, 由资源所有者通过授权服务器给 client 发放访问授权。只有授权服务器对资源所有者进行认证,因 此资源所有者的认证信息不会被 client 获取。授权码方式提高了一些安全性,例如实现了对 client 的认证、将 access token 直接传递给 client,而不通过资源所有者的 user-agent 中转。 Implicit 授权方式是针对 client 在浏览器中通过 js 脚本实现的一种简化授权码优化方式,这种 流程中,client 直接获得 access token 而省略掉中间的 authorization code 的发放过程。这种流程中, 授权服务器不对 client 进行认证,仅在某些情况下通过重定向 URI 对 client 进行另外一种形式的检 验。Access token 将被暴露给 user-agent 或者其他能够访问 user-agent 的其他应用。这种流程提高了 响应速度,但降低了安全性,在实现时需要权衡。对于在浏览器中通过 js 实现的 client 而言,适合 采用这种方式。 资源所有者密码凭据授权方式,要求 Client 获得资源所有者的账号密码等凭据,然后直接使用 所有者凭据从授权服务器获取 access token。只有在 client 和资源所有者之间具有高度信任关系并且 其他授权方式不可用时才能够使用这种方式。这种方式下,规范要求资源所有者的密码仅用于一次 请求,并在后续交互过程中更换为 access token,不能一直使用资源所有者的密码证书。通过将密 码证书替换为一种长期有效的 access token 或者 refresh token 而避免要求 client 保存资源所有者的 密码证书。 当要访问的授权资源受限于 client 控制范围内的受保护资源或者受限于授权服务器事先定义的 受保护资源时,可以使用 client 证书授权方式。典型情况下,client 同时作为资源所有者。这种方 式可以用于原有账号密码认证授权实现方式的升级。 四种授权方式中,Authorization Code 方式是功能最完整、流程最严密的授权模式。它的特点就 是通过客户端的后台服务器,与"服务提供商"的认证服务器进行互动。下面讲解这种授权流程。 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 26 共 44 resource owner user-agent client authorization server A redirect user-agant A client indentifier and redirect URI B User anthenticate C D authorization code and redirect URI E access token (opt refresh token) B user anthenticate C Anthorization code 流程步骤如下: A. 用户访问客户端,后者将前者导向认证服务器。 A 步骤中,客户端申请认证的 URI,包含以下参数:  response_type:表示授权类型,必选项,由于是Authorization code授权方式,此处的值固定 为"code"  client_id:表示客户端的ID,必选项  redirect_uri:表示重定向URI,可选项  scope:表示申请的权限范围,可选项 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 27 共 44  state:表示客户端的当前状态,可以指定任意值,认证服务器会原封不动地返回这个值。 下面是一个例子 GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com B. 用户选择是否给予客户端授权。 C. 假设用户给予授权,认证服务器将用户导向客户端事先指定的"重定向URI"(redirection URI),同时附上一个授权码。 C 步骤中,服务器回应客户端的 URI,包含以下参数:  code:表示授权码,必选项。该码的有效期应该很短,通常设为10分钟,客户端只能使用 该码一次,否则会被授权服务器拒绝。该码与客户端ID和重定向URI,是一一对应关系。  state:如果客户端的请求中包含这个参数,认证服务器的回应也必须一模一样包含这个参 数。 下面是一个例子。 HTTP/1.1 302 Found Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA &state=xyz D. 客户端收到授权码,附上早先的"重定向URI",向认证服务器申请令牌。这一步是在客户 端的后台的服务器上完成的,对用户不可见。 D 步骤中,客户端向认证服务器申请令牌的 HTTP 请求,包含以下参数:  grant_type:表示使用的授权模式,必选项,此处的值固定为"authorization_code"。  code:表示上一步获得的授权码,必选项。  redirect_uri:表示重定向URI,必选项,且必须与A步骤中的该参数值保持一致。  client_id:表示客户端ID,必选项。 下面是一个例子。 POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb E. 认证服务器核对了授权码和重定向URI,确认无误后,向客户端发送访问令牌(access token) AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 28 共 44 和更新令牌(refresh token)。 E 步骤中,认证服务器发送的 HTTP 回复,包含以下参数:  access_token:表示访问令牌,必选项。  token_type:表示令牌类型,该值大小写不敏感,必选项,可以是bearer类型或mac类型。  expires_in:表示过期时间,单位为秒。如果省略该参数,必须其他方式设置过期时间。  refresh_token:表示更新令牌,用来获取下一次的访问令牌,可选项。  scope:表示权限范围,如果与客户端申请的范围一致,此项可省略。 下面是一个例子。 HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" } Access token:是授权服务器发放给 client 用于访问资源的凭据,以一串字符串。这段字符串是 每个 client 唯一的。Token 代表了特定的授权范围、授权访问时间、资源所有者。Access token 提 供了一个抽象层,代替了各种不同授权结构,使得资源服务器不需要理解各种不同形式的认证方式, 仅需要理解 access token 即可。根据资源服务器的安全需求不同,access token 可以有不同的格式、 结构或者实现方法。 Refresh token:是获取 accesstoken 的凭据,由授权服务器颁发给 clien 。当 access token 失效或 者过期后,可使用 refresh token 重新获取 access token。授权服务器可选发放 refresh token,如果发 放 refesh token 则必须和 access token 一起发放。Refresh token 仅在授权服务器和 client 之间使用, 不需要被发送给资源服务器。 OAuth2.0 规范(RFC6749)还定义了其他三种授权方式先各自的交互流程,本文不再描述。 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 29 共 44 2.3.4 OAuth2.0 的安全性 Client authentication 规范定义只要有可能性,授权服务器必须对 Client 进行认证,可以采用密码方式认证,也可以 采用其他更高安全性的验证方式。授权服务器必须保证 client 密码和其他凭据的机密性。OAuth2.0 根据客户端的能力(保护客户端凭据的能力以及保护机密性的能力),定义两种客户端类型: 1 机密型客户端: 在这类客户端上,对客户端凭据的访问授权访问控制。例如一个 web 网站可以作为一个机密性 客户端,向授权服务器申请授权。 2 公共型客户端: 这类客户端上,无法对客户端的凭据进行安全保证,例如在 user-agent 中通过 js 实现的 client、 或者是 Native-application。 通常授权服务器可以向机密型 Client 发放一些客户端凭据用于和授权服务器之间的认证,例如 密码、公私钥对。而禁止向公共型客户端发放密码和其他凭据。 授权服务器可以与公共性 Client 之间建立一种 Client 认证方法,但授权服务器不能依赖于 Client 认证过程来识别和验证 Client。 Client 可以通过 http basic 认证方式和授权服务器之间建立认证。授权服务器必须支持 http basic 认证方式,以便认证那些发放了密码的 client。 当无法进行 Client 认证时,授权服务器应该通过其他手段验证 Client 的身份,例如要求 Client 注册,并比对注册的 redirect URI。 URI 比对不足以验证 Client 的身份,但有助于方式将资源所有 者的授权发送给一个伪造的 Client。授权服务器也可以提醒用户,由用户确认 Client 是否被假冒。 Client Impersonation 只要有可能,授权服务器必须对 Client 进行认证。如果因为 Client 的自身因素导致授权服务器 无法对 Client 进行认证,授权服务器必须要求 Client 将所有可能得 redirect URI 都进行注册。授权服 务器可以验证 Client 的 redirect URL 实现一定程度的检验。URI 比对不足以验证 Client 的身份,但 有助于方式将资源所有者的授权发送给一个伪造的 Client。 授权服务器还应该采用其他可以采用的 手段保护资源所有者,例如授权服务器可以让资源所有者协助确认 client 的身份。 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 30 共 44 授权服务器应该显示提醒资源所有者关于 client、强求授权的范围、授权时间等信息,然后由 资源所有者检查这些信息,并进行授权。授权服务器在没有对 client 进行认证后者使用其他手段保 证重复授权来自同一个 client 的情况下,不应该自动进行重复的授权(在不提醒资源所有者情况下) Access token Access token 在传输和保存时必须保证机密性,并且仅仅在授权服务器、Client、资源服务器(仅 限验证 access token 的服务器)之间共享。必须采用 TLS 传输,并且必须进行 tls server 验证。 当使用 implicti 授权方式是,access token 在 http fragment 中传输,这将可能暴露给未知的第三 方。Implicit 方式先,Access Token 在传输过程中安全仍然需要通过 TLS 来保证。 协议没有定义资源服务器如何验证 Client 提交的 accesstoken 是由授权服务器发布给 Client 的。 Refresh token 授权服务器需要维护 refresh token 和 client 的对应关系。Refresh token 必须通过 tls 传输。无论 client ID 是否被认证,授权服务器都要验证 refresh token 和 client id 之间的对应关系。 Authorization code 授权码应该用通过安全通道传输,由于通过 user-agent 的 redirections 传输,授权码可能被通过 user-agent 的历史记录或者 http referrer 头被暴露。 授权码的有效时间必须很短,并且一次有效。如果授权服务器发现重复使用相同的授权码申请 access token,则应该撤销根据此授权码发布的所有 access token。 实际上,OAuth2.0 规范放弃了许多安全特性从而获得实现上的简单性,例如 OAuth2.0 中非常 重要的 Access Token 和 Refresh Token 在传输过程中安全性依赖于 TLS,没有采用相对较为复杂点的 密钥交换过程,没有签名和签名验证机制等。OAuth2.0 的安全性还体现在最小授权原则(机密信 息知道的人越少越好)、及时失效原则(机密信息的生命周期越短越好,最好一次性有效)。但实际 上许多 OAuth2.0 的支持者在安全性和便利性之间往往被便利性主导,例如腾讯公共平台的 Access token 有效期为三个月,通过 Refresh token 可以最长延迟一年有效期。 2.3.5 OAuth2.0 分析 OAuth2.0 本质上是一个授权规范,它通过在资源请求者和资源服务器之间抽象出一个授权层, 将用户对资源访问的授权过程从资源请求过程中从逻辑上剥离出来,从而使得资源授权和资源请求 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 31 共 44 可以相互独立地实现。在实际实现过程中,这有助于那些拥有用户资源的知名网站(例如 google、 腾讯等)同时作为资源服务器和授权服务器向其他“Client”开放资源访问权限。 OAuth2.0 定义了一个逻辑框架,并且这个逻辑框架在 web 应用中极具普遍性,并且可以较为 简便地实现该规范,因此 OAuth2.0 的支持程度较高。OAuth2.0 规范还有许多没有定义的地方,这 些没有定义的部分可以采用其他一些协议或者规范来弥补。例如没有定义用户和授权服务器之间的 交互过程,授权服务器如何认证用户? 可以采用 OpenID 规范;没有定义授权服务器和资源服务器 之间的交互过程,资源服务器如何验证一个 Access Token 是一个合法的 Token?可以采用 SAML 规 范。 OAuth2.0 规范不能直接用来实现单点登录,但有些实现对授权服务器的处理流程进行修改,例 如不遵循 OAuth2.0 规范对客户端的授权流程,不进行用户授权过程,仅仅保留一些 OAuth2.0 规范 中定义的参数名称(Access Token、Refresh Token、Expire in、Authorization Type 等),可以实现用 户输入一次账号密码访问多个 web 网站或者多个应用服务器的效果,并因此而号称遵循 OAuth2.0 规范实现了单点登录。这种情况下,实现单点登录的主要因素实际并不是 OAuth2.0 规范而是其他 自定义的交互流程。 2.4 OpenID2 协议 OpenID 是一个以用户为中心的数字身份识别框架,是一个以 URL 为身份表示的分散式身 份验证解决方案,具有开放、分散、自由的特性。OpenID 的创建基于这样一个概念:可以通 过 URL 来认证一个网站的唯一身份,同理也可以使用 URL 作为用户的身份认证,通过一个 URL 在多个网站上进行登录认证。对于支持 OpenID 的网站,用户不需要记住像用户名和密码 这样的传统验证标记。取而代之的是,他们只需要预先在一个作为 OpenID 身份提供者(identity provider, IdP)的网站上注册。OpenID 是去中心化的,任何网站都可以使用 OpenID 来作为用户 登录的一种方式,任何网站也都可以作为 OpenID 身份提供者。OpenID 既解决了问题而又不需 要依赖于中心性的网站来确认数字身份。 OpenID 官方网站 http://openid.net.cn/、http://openid.net/ OpenID2.0 规范 http://openid.net.cn/specs/openid-authentication-2_0-zh_CN.html AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 32 共 44 2.4.1 重要术语 1. 标识: 一个 Identifier 可以是一个 “http” 或 “https” 的 URI,(本文档中一般称为 “URL”), 或者一个 XRI [XRI_Syntax_2.0]。 2. 用户代理(User-agent): 通常是指用户的浏览器软件。 3. 依赖方: RP。要证明用户对某个标识拥有控制权的 Web 应用程序。 4. OpenID 提供方: OP。 一个 OpenID 认证服务器,它能为依赖方提供断言,证实用户拥有某个标识。 5. OpenID 提供方终点 URL: 接受 OpenID 认证协议消息的 URL, 它是通过对用户提供的标识执行自动发现时找到的。 这个值必须是一个绝对的 HTTP 或 HTTPS URL。 6. OpenID 提供方标识: OpenID 提供方的标识。 7. User-Supplied 标识: 由用户出示给依赖方的标识,或者是用户在 OpenID 提供方那里选择的标识。 在协议开 始阶段,用户输入他们自己的标识或一个 OpenID 提供方标识。 如果是一个 OpenID 提 供方标识,OpenID 提供方将协助用户来选择一个标识给依赖方。 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 33 共 44 2.4.2 OpenID 协议交互过程 User-agent Relying Party OpenID Provider login requst (包含User-Supplied 标识) Normalization User-Supplied ID Discovery Association request Association handle redirect to OpenID Provider (authentication requst) user authentication request return authentication result. redirect to relying party authentication response verify authentication result login response 1. 用户通过他们的用户代理向依赖方提供一个 User-Supplied 标识 初始化认证 过程。 2. 在规格化了 User-Supplied 标识后,依赖方 执行自动发现来确定用户所使用 的 OpenID 提供方终点 URL。需要注意的是,User-Supplied 标识也可以是 一个 OpenID 提供方标识, 3. (可选的) 依赖方和 OpenID 提供方建立一个 association──使用 Diffie-Hellman Key Exchange 密钥交换协议协商一个共享密钥。OpenID 提 供方用 association 对消息签名, 同时依赖方验证这些消息; 这就可以省略每 次认证请求/响应的后续验证签名的直接请求。 4. 依赖方让用户的用户代理带着认证请求 参数重定向到 OpenID 提供方。 5. OpenID 提供方确定用户是否有权并愿意接受 OpenID 认证。 至于用户如何向 他们的 OpenID 提供方验证自己和其它的鉴别策略已超出本文档所描述的范围。 6. OpenID 提供方让用户的用户代理重定向回依赖方,参数中指明是认证通过还是 认证失败。 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 34 共 44 7. 依赖方校验从 OpenID 提供方接受到的信息,包括检查返回 URL(Return URL), 验证自动发现信息,检查 nonce, 并用在 association 阶段建立的共享密钥或 发送一个直接请求给 OpenID 提供方来验证签名。 2.4.3 OpenID 优缺点: 优点:  对用户,简化注册登录流程,一定程度上避免了重复注册、填写多份身份信息的麻烦  对用户,一处注册、多处同行“免去记忆多份账号的麻烦  用户拥有对账号信息的控制权:OpenID提供方在提供用户信息给依赖方时,允许用户 进行访问控制,用户可以基于对依赖方网站的信任程度,进行不同程度的授权。  对于依赖方:共享用户资源:可以直接使用OpenID提供方已经注册的大量用户。  对于依赖方:不需要重新建立、维护用户信息数据库,降低开发成本、硬件成本等。 缺点:  任何人都可以建立OpenID提供方网站,提供OpenID验证服务,而网站性能参差不齐, 导致用户体验不稳定  如果OpenID提供方网站故障,导致多个OpenID依赖方网站的服务无法应用。 2.4.4 OpenID 的安全性 作为 OpenID 依赖方,需要考虑的安全问题是如何保证接收到的 OpenID 提供方提供的认证结 果是真实的,而不是被伪造的。在 OpenID 规范中,可选地在依赖方和提供方之间建立 association, 在双方交换对称密钥,并定义了使用密码进行消息签名的方法(HMAC_SHA1,HMAC_SHA256)。 为了保证依赖方和提供方之间密钥协商的安全性,可以采用 TLS 进行传输加密或者采用 DH 算法。 为了防止重放攻击,OpenID 提供方在返回认证结果的报文中增加了 nonce 值。 作为用户,需要考虑的安全问题是账号密码等信息是否仅提供给 OpenID 提供方,而没有被泄 露给 OpenID 依赖方。OpenID 规范定义了提供方和依赖方之间的交互数据,可以依赖方不能通过 OpenID 报文获得用户的密码等原始身份信息。但 OpenID 规范没有定义用户和 OpenID 提供方之间 的认证交互协议,这个过程中的安全性保护不在 OpenID 规范的范围内。 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 35 共 44 作为 OpenID 提供方,需要考虑拒绝服务工具。由于在建立 association 过程中,提供方需要进 行 DH 密钥交换运算,因此有可能被进行 DDOS 攻击,此时可以使用通用的源 IP 地址速率检测技 术抵抗 DDOS 工具。 2.4.5 OpenID 分析 OpenID 实际是一个用户身份认证框架,主要用于对用户身份的认证,并不能直接提供单点登 录功能。OpenID 依赖方一般是用户所访问的 web 资源服务器,如果多个 OpenID 依赖方使用相同的 OpenID 提供方,则用户在访问各个不同的依赖方时,如果仅根据 OpenID 规范而不经过其他处理, 仍然需要进行多次用户认证过程。然而由于使用了相同的 OpenID 提供方,OpenID 提供方可以提供 一种方式,让用户在多次登录认证过程中,减少输入登录信息的次数,从而达到单点登录的效果。 但 OpenID 规范本身没有定义这种方式。 OpenID 规范可以在同一个企业内部实施,通过建立一个 OpenID 提供方,并让企业内多个 web 网站支持 OpenID,作为 OpenID 依赖方访问共同的 OpenID 提供方,同时在 OpenID 提供方上采取 一些额外的措施,可以实现企业内部多个 web 网站之间的单点登录。 由于 OpenID 规范定义了采用 http/https 传递各种参数,并利用 http 的重定向功能,因此 OpenID 比较适合 web 网站,但采用 http 协议进行数据传递的其他本地应用也可以使用 OpenID 进行用户认 证。 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 36 共 44 3 AnyOffice 单点登录方案介绍 3.1 单点登录场景 3.1.1 集成 SDK 的应用单点登录 同一个移动终端上安装了多个企业应用,并且每个企业应用都集成了 AnyOffice 安全 SDK。用 户登录首个企业应用时,要求输入账号密码进行认证。如果认证通过, 用户在一定时间段内,登 录另外的企业应用,此时应该不需要再次输入账号密码,可以直接按照前一个应用所输入的用户身 份信息登录第二个应用。 3.1.2 未集成 SDK 的应用单点登录 AnyOffice 工作台上会显示当前已经安装的企业应用的图标,用户点击 AnyOffice 工作台上的 应用图标,可以启动对应的企业应用。由于用户在登录 AnyOffice 时已经验证过用户的账号密码等 身份信息,那么在启动企业应用时,为提高易用性,此时不应该再次要求输入账号密码等身份信息。 3.1.3 Web app 单点登录 AnyOffice 工作台可以提供内网 web app 的图标,点击对应的图标可访问对应的 URL 网站。由 于用户在登录 AnyOffice 时已经验证过用户的账号密码等身份信息,那么在 web app 访问内网 WEB 网站时,为提高易用性,此时不应该再次要求输入账号密码等身份信息。 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 37 共 44 3.2 AnyOffice 单点登录方案 3.2.1 集成 SDK 的应用单点登录 1) 方案一:传递 token 当前版本流程说明: 1. 用户启动应用客户端; 2. 在启动应用客户端之前,如果已经登录过AnyOffice应用或者其他企业应用,则应用客户端 能够从安全共享区查询到单点登录参数(Token),此时直接跳转到步骤7;如果在启动应 用客户端之前,没有登录其他任何集成eSDK的企业应用,则此时应用客户端将无法从安全 共享区获取到单点登录参数(token),此时客户端会调用SDK 显示登录界面,并继续下面 的步骤三。 3. 用户在客户端界面输入账号密码登录 4. 应用客户端将账号密码传输到AnyOffice后台系统,AnyOffice后台系统到AD或者LDAP服 务器上认证;认证通过后,AnyOffice后台系统分配Token返回到移动终端的应用。 5. 应用客户端将token写入安全共享区 6. 应用客户端登录服务器,传递账号、密码和token进行验证 7. 应用服务器到AnyOffice后台系统验证token,或者应用服务器自身完成账号密码的验证; 至此完成应用客户端登录过程。 注意:流程中对安全共享区和 AnyOffice 接入服务器的交互已经被 AnyOffice 安全 SDK 封装, 可通过调用安全 SDK 的接口实现。 接口说明: AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 38 共 44 应用服务器到 AnyOffice 系统验证 token 的请求报文格式如下: https://IDP/SSOTokenCheck.html?WebAppToken=%s& AnyOffice 后台服务器响应报文格式: %s < checkresult >%d 其中,IDP 为 AnyOffice 后台服务器 URL;username 为用户名;checkresult 为校验结果(0: 校验失败;1:校验成功)。 更加详细和具体的接口请参见专门提供的接口文档。 安全性分析: token 传输安全: token 由AnyOffice服务器产生,并且通过SSL在anyoffice服务器和应用客户端之间传输; token 在应用客户端和应用服务器之间传输时,在内网传输部分可能是 http 明文传输,存 在安全风险; token 在应用服务器和 anyoffice 服务器之间传输时,可能是 http 明文传输,存在安全风险; token 存储安全: token 在移动终端中存储在安全共享区,其安全程度依赖于安全共享区的安全度。有关安 全共享区的介绍请参考 AnyOffice 安全沙箱技术白皮书 安全加固方案: 1 AnyOffice 服务器对每个移动应用生成各自独立的 ticket 移动应用上层业务代码调用SDK获取ticket时,SDK获取应用的包名传递到AnyOffice服务器。 AnyOffice 服务器在验证了 SDK 之后,为每个用户的每个应用产生一个 ticket,返回给 SDK; 移动应用的服务器到 AnyOffice 服务器上验证 ticket 时,需要携带移动应用的包名。AnyOffice 服务器验证包名和 ticket 是否匹配,只有两者匹配才可能验证通过。 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 39 共 44 2 ticket 一次有效 当 AnyOffice 服务器接收到对某个 ticket 的验证请求之后,无论本次验证结果如何,在服务器 上都将该 ticket 失效,后续再次请求对该 ticket 的验证时都将失败。 移动应用在对 ticket 验证失败后,可以调用 SDK 的接口从 AnyOffice 后台系统获取一个新的 ticket。如果此时网络不通,则此时 SDK 无法重新获取 tiket,此时移动应用应该做离线处理。 3 设置 ticket 的有效时间 AnyOffice 服务器产生 ticket 之后,需要记录产生时间,并设置过期时间,只有在过期失效前该 ticket 才有效。第三方应用服务器请求验证一个过期的 ticket,将得到验证失败的错误提示。 移动应用在对 ticket 验证失败后,可以调用 SDK 的接口从 AnyOffice 后台系统获取一个新的 ticket。如果此时网络不通,则此时 SDK 无法重新获取 tiket,此时移动应用应该做离线处理。 4 ticket 验证接口规范化 AnyOffice 服务器按照 CAS 规范提供 ticket 验证接口,参见 CAS serviceValidate 接口说明章节。 后续可考虑增加 CAS3.0 自定义用户字段或者支持 samlValidate 接口。 5 对接外部 CAS Server AnyOffice 安全 SDK 可以按照标准 CAS 规范对接第三方 CAS Server 首先完成认证,获得 ticket grant cookie,然后获得 ticket。如果企业用户的 IT 环境中已经部署了 CAS 系统,那么 AnyOffice 可以进行无缝集成。 2) 方案二:传递账号密码或者数字证书 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 40 共 44 流程说明: 1. 用户启动应用客户端A; 2. 应用客户端A读取移动终端系统的安全共享区,查询账号密码或者数字证书。 3. 如果从安全共享区获得密码或者数字证书,则直接到步骤7。否则应用客户端显示登录界 面; 4. 用户在登录界面中输入账号密码登录; 5. 客户端应用A使用用户输入的账号密码登录AnyOffice接入服务器; 6. 客户端应用A将账号密码写入安全共享区; 7. 应用客户端登录服务器,传递密码或者数字证书进行验证 8. 应用服务器到外部认证授权服务器进行用户认证授权过程; 注意:流程中对安全共享区和 AnyOffice 接入服务器的交互已经被 AnyOffice 安全 SDK 封装, 可通过调用安全 SDK 的接口实现。 安全性分析:  用户账号密码或者数字证书的传输安全: 第三方移动应用无法直接获得用户的账号密码或者数字证书,只能通过安全 SDK 获得。 而安全 SDK 在向上层返回用户账号密码或者数字证书前,必须完成对第三方移动应用的验证,只 有验证通过的移动应用才能够获得用户账号密码或者数字证书。第三方移动应用的验证是指在调用 SDK 的接口之前,先对移动应用进行校验,之后合法授权的移动应用才能调用 SDK 获取安全共享 存储区中的机密信息。 第三方移动应用获得用户密码或者数字证书之后,需要保证传输过程中账号密码或者数字 证书的安全,例如采用 https 或者 SSL 进行传输加密;  用户账号密码或者数字证书存储安全: 用户账号密码或者数字证书在移动终端中存储在安全共享区,其安全程度依赖于安全共享 区的安全度。 3) 方案对比 方案一(获取 token) 方案二(传递账号密码) AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 41 共 44 优点 1 安全度高 2 不要求第三方应用和 AnyOffice 使用相 同认证服务器 1 实现简单,应用客户端修改小,应用服 务器不需修改 缺点 需要应用服务器和应用客户端修改,实现 复杂度高 1 安全程度不高 2 要求第三方应用和AnyOffice使用相同 认证源 3.2.2 未集成 SDK 的应用单点登录 从工作台启动未集成 SDK 的应用的单点登录方案与集成 SDK 的应用单点登录方案的区别点在 于客户端应用如何获得单点登录凭据(token、ticket、账号密码、数字证书等)。如果应用没有集成 AnyOffice 的安全 SDK,那么显然无法调用SDK的接口获得单点登录凭据,必须采用其他方式获得。 如果从工作台上启动第三方应用,那么可以在启动过程中传递单点登录凭据到第三方应用,第三方 应用客户端获得单点登录凭据之后,可以交由第三方应用服务器去验证登录凭据是否有效。如果登 录凭据为 token/ticket,第三方应用服务器可以到产生该凭据的服务器(AnyOffice 服务器或者第三 方 CAS Server)去验证;如果登录凭据为账号密码,则第三方应用服务器直接到认证服务器上验证 (Radius、LDAP 等);如果第三方应用不是从 AnyOffice 工作台上启动,并且也没有集成安全 SDK, 当前没有成熟的单点登录方案。 安全性分析: 1) AnyOffice在移动终端的安全共享区保存用户单点登录凭据, 其安全程度依赖于安全共享 区的安全度; 2) AnyOffice 在将单点登录凭据传递给第三方应用时,需要保证第三方应用的合法性,否则 会导致登录凭据泄密。只有通过企业应用商店下载安装的企业应用才能够显示在AnyOffice 客户端的工作台中,通过这种方式保证AnyOffice客户端只会将登录凭据传递给合法的应用。 3) 单点登录凭据传递给第三方应用之后,其传输、保存过程中的安全问题需要由第三方应用 解决。 接口说明 AnyOffice 客户端工作台调用 Android 第三方应用时,通过 Intent 传递单点登录凭据; AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 42 共 44 AnyOffice 客户端工作台调用 iOS 第三方应用时,通过 URL Schema 传递单点登录凭据; 具体接口说明可参考单独的接口说明文档。 3.2.3 Web app 单点登录 AnyOffice 的 web app 功能是由安全 SDK 提供的,启动 web app 的应用必然是集成了安全 SDK 的,因此 web app 单点登录方案和“集成 SDK 的应用单点登录”方案基本类似,其差异点在于“集 成 SDK 的应用”的应用层代码是是第三方开发者开发的,AnyOffice 只要定义好安全 SDK 的接口, 而不用关心上层应用的开发。而 web app 的应用层实现是在安全 SDK 中实现的,因此可以在安全 SDK 中实现 WebApp 的单点登录功能。 1) 方案一:传递 token 当前方案流程说明: 1. 用户登录AnyOffice 2. AnyOffice网关认证用户并返回用户凭据信息(Token) 3. 从AnyOffice工作台启动web app,安全浏览器在访问web服务器的http报文中携带token以及 “AnyOffice后台系统”的URL地址 4. Web服务器获取“AnyOffice后台系统”的地址和token后,向AnyOffice接入服务器发起https 请求 验证token 5. “AnyOffice后台系统”验证token,并返回用户标识(UID) 接口说明: AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 43 共 44  WebApp 客户端向Web服务器发起的HTTP请求报文中携带单点登录参数,格式如下: GET /next/indexa.html HTTP/1.1 Accept: */* Accept-Language: zh-CN User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MALC; aff-kingsoft-ciba; .NET4.0C; .NET4.0E) Accept-Encoding: gzip, deflate If-Modified-Since: Mon, 25 Nov 2013 10:40:38 GMT If-None-Match: "2cbe33-794-4ebfdfea01580" Host: w3.huawei.com Connection: Keep-Alive IDP:www.anyoffice.com/checkToken.html Cookie: _token= DbQBaxAi8KnTxTuKbOdKLXSy8Q Web app 通过 http 报文中的 cookie,字段为“_token”,向 web app 服务器传递 Token 值,需要 web 服务器能够解析出 cookie 里面包含的 token 值; Web app 通过 http 报文头中增加的 IDP 向 webapp 传递 AnyOffice 后台系统的 URL,用于 web app 服务器验证 Token; Web 服务器需要按照上述规范定义,从 http 报文中解析得到 IDP 和_token,然后到 AnyOffice 后台系统完成 token 验证,验证通过后即可完成 WebApp 的单点登录。  AnyOffice后台服务器对外提供的token验证接口参照“集成SDK的应用单点登录”章节的 说明。 2) 方案二:自动完成认证 Web app 和 web 服务器进行 http 协议交互时,安全 SDK 中的 web app 实现可以解析 web 服务 器返回的 http 401 Unauthorized 报文,根据 http 报文中的 WWW-Authenticate 所指定的认证类型,使 用登录 AnyOffice 客户端的账号密码自动进行 http basic、NTLM、Keberos 认证交互。这种实现方 式不需要对 Web 服务器进行适配修改。 AnyOffice V200R005C00 单点登录技术白皮书 OFFE00016521_PMD281ZH A 内 部 公 开 文档版本 V1.0(2015-11-10) 第 44 共 44 3) 方案对比 方案一 要求 web 服务器进行修改,将 AnyOffice 接入服务器或者第三方 CAS Server 作为单点 登录凭据验证服务器。如果 web 服务器和 AnyOffice 系统所使用的认证源不同,则比较适合采用方 案一。 方案二不需要 web 服务器进行修改,因此易于与原有 web 系统集成。方案二所采用的 NTLM、 Keberos 认证方式是标准的 http 规范,认证过程的安全性也有保证。