共计 4001 个字符，预计需要花费 11 分钟才能阅读完成。
友户通做用友云的用户系统也一年多了，经常听实施、售前等说要私有化部署友户通，原因无非是企业的考虑到用户安全性和单一用户账号的需求。但由于用户管理的复杂性，友户通部署与维护并不容易，因此经常纠结在用户系统是用友户通云服务还是要私有化部署。企业私有化 IT 服务服务发展到几天已经很丰富，企业内部可能部署了几十上百的应用程序，企业对于这些应用的用户通常采取统一的用户中心来进行管理。针对这种情况，友户通特定开发了联邦用户中心来支持企业的自有用户中心。让我们一起来看看这个联邦用户中心是如何支持企业自有用户中心的。一、为什么要使用联邦身份认证未使用联邦身份认证时 o 企业自有用户中心的用户不能访问用友云各个应用企业应用有自己的用户中心（以下称为：自有 IdP），通过自有 IdP 认证的用户无法直接访问用友云。o 用户管理复杂管理员需要分别在两个系统中为用户创建账号。o 用户操作繁琐用户访问两个系统时需要使用两个系统的账号登录，需要记住两套密码。使用联邦身份认证后 o 自有 IdP 用户可以直接访问用友云用户在企业自有 IdP 认证通过后，可直接访问用友云应用，无需再次经过友户通认证。企业管理员也无需在友户通中重复创建用户。o 用户管理简单企业管理员只需要在企业自有 IdP 中为用户创建账号，用户即可同时访问两个系统，降低了管理复杂度。o 用户操作方便用户在本企业 IdP 中登录即可访问企业应用和用友云应用，使用方便，流畅。o 深度融合企业内部应用与用友云在用户系统上已经打通，在用户打通的基础上可根据场景进行进一步的融合。二、友户通支持哪些种类的企业 IdP 目前友户通已经支持了 LDAP、CAS、OAuth2 等标准协议的企业 IdP，还支持友户通自定义的 Token 机制的 IdP. 除了友户通自定义的 Token 机制支持的企业 IdP 需要一定的开发量，其他协议的企业 IdP 只需要在友户通进行配置就可以使用了，完全不需要进行开发。友户通的联邦用户身份认证未来还将继续扩展所支持的协议，很快就会增加对 SAML2 协议的支持。SAML2 协议将不需要友户通和企业 IdP 之间有直接网络连接就可以进行联邦用户身份认证。三、使用友户通的联邦身份认证有什么体验体验一：部署实施简单只需要三步甚至两步就可以部署实施完成企业 IdP 与友户通的集成步骤一：根据需要部署 yhtagent（企业 IdP 在内网，而友户通需要访问企业 IdP）步骤二：在友户通中配置联邦身份认证。步骤三：在访问用友云的链接里加上 thirducid 参数（参数值由第二步确定）。联邦身份认证中心配置界面体验二：用户使用方便步骤一：登录企业 IdP（LDAP 用户中心则可直接在友户通登录界面通过特殊用户名进行登录）。步骤二：在同一个浏览器里打开带 thirducid 参数的用友云链接地址，就可登录用友云。企业用户在内部应用和用友云应用之间的切换非常方便。对于企业客户来说，其员工信息可以得到保护，云服务的实施变得更加简单。四、技术挑战与实现挑战一：支持 LDAP 协议的企业 IdP 时，如何确定用户应该在哪里验证。企业内部的用户管理经常使用 AD 域来管理，其支持 LDAP 协议来进行用户查询，用户名密码验证等。友户通支持通过 LDAP 协议使用企业内部的支持 LDAP 协议的用户中心账号进行登录。LDAP 协议已经很成熟了，对接起来并不难，麻烦在于什么时候，去哪个 LDAP 用户中心验证用户。针对这个问题，我们使用了两种方式来解决。支持方式一：通过特殊用户名来确定企业 IdP 在配置 LDAP 用户中心时，为每个 LDAP 用户中心配置一个唯一标识符，在登录的用户名，加上一个“@”符号和唯一标识符，这样，友户通就能识别这个用户是需要使用哪个 LDAP 用户中心去验证了。这种方式适合主动打开用友云服务的应用，在登录主动输入域账号进行登录。支持方式二：通过 URL 里的参数来确定企业 IdP 在访问登录页面的 URL 里增加一个参数 thirdUCId，这样在友户通系统里，通过 thirdUCId 查询到的企业 IdP 是 LDAP 用户中心，就可以到相应的地方去验证用户了。这种方式适合在企业内部的系统里嵌入 URL 链接穿透到用友云服务的场景。挑战二：如何从企业 IdP 单点登录到用友云很多企业经过了很多轮的信息化，部署了很多应用，企业为了方便员工账号管理及登录管理，通常采用支持单点登录的用户系统来统一管理用户账号，及支持单点登录。这些企业如果也购买了用友云的应用，企业需要使用自己的用户账号进行登录，以方便进行用户管理。针对这种需求，友户通支持 CAS、OAuth、SAML 标准的单点登录用户中心，登录了企业自有用户中心后能够直接登录用友云，而不需要再次输入用户名和密码。支持方式一：使用 CAS 协议友户通和企业 IdP 之间，走标准 CAS 协议，即友户通到企业 IdP 申请发放 ticket，企业 IdP 发放 ticket 之后重定向到友户通，友户通到企业 IdP 验证 ticket，验证成功后即可登录友户通。企业 IdP 负责发放 ticket 和验证 ticket 并返回用户信息，友户通的负责向企业 IdP 申请发放 ticket，得到 ticket 后调用企业 IdP 验证验证 ticket 并得到用户信息，并让用户登录到友户通中。友户通在申请企业 IdP 发放 ticket 和验证 ticket 过程中，浏览器主页面处于等待状态，子页面 iframe 负责申请发放 ticket 和验证 ticket 的接口调用。该方式实现的难点 1、怎么确定去哪个企业 IdP 申请 ticket 从而登录呢？咋们来个故技重施，通过 URL 里的一个参数 thirducid 来决定去哪个企业 IdP 去申请发放 ticket.2、友户通登录页既要在已经登录了企业 IdP 时能够自动登录，又要在未登录企业 IdP 时显示友户通登录界面，两方又不在同一个域里，如何做到跨域呢？这里，我们使用了一个巧妙的方式，也是充分利用 CAS 标准。在 CAS 用户中心里，如果已经登录的话，将会发放 ticket，并且重定向到 service 参数指定的 url 上。前端登录界面开启一个 iframe 去企业 IdP 申请 ticket，同时 service 地址为友户通接口，这个接口验证企业 IdP 发放的 ticket，并发放一个友户通登录 token，返回一个页面将父页面（登录页面）导航到友户通自动登录 url，从而登录进入友户通。图 1 -2 友户通集成企业 IdP 协作图下面我们来看看具体是怎么实现的。（1）企业 IdP 配置。将企业 IdP 的信息配置到友户通中，包括企业 IdP 的 ticket 发放地址，验证地址，用户信息的格式，以及发放 ticket 和验证 ticket 时需要的一些参数的配置，以便在单点登录过程中使用。（2）登录服务申请企业 IdP 发放 ticket. 登录服务通过 url 里的参数 thirducid，查询到企业 IdP 的相关配置，将申请发放 ticket 的地址 ticketrequesturl 提供给前端 JavaScript，前端 JavaScript 打开一个隐藏的 iframe，将 iframe 的 src 设置为 ticketrequesturl，企业 IdP 将检测浏览器是否登录过且有效，如果登录过且有效，则发放 ticket，跳转到 ticketrequesturl 里的 service 参数的地址上，该地址为 IT 服务里的验证企业 IdP ticket 接口。（3）验证企业 IdP ticket 接口（第（2）条里用来作为 service 地址）。本接口接收企业 IdP 发放的 ticket，以及代表那个企业 IdP 的 thirducid，通过调用相应的企业 IdP 的验证 ticket 的接口，如果 ticket 合法，企业 IdP 会返回相应的用户信息，友户通将根据配置解析出用户信息，产生一个友户通单点登录 token（友户通的登录服务接口可通过此 token 单点登录到友户通中），并返回一个页面（运行在 iframe 中），此页面将会将父页面重定向到友户通的登录服务接口（包含友户通单点登录 token），走完标准友户通的单点登录流程后将登录进入到友户通。支持方式二：使用 OAuth2 协议使用 OAuth2 协议和 CAS 协议差别不大，只需要将 CAS 协议中申请 Ticket 替换成申请 code，验证 ticket 替换成通过 code 获取 accessToken 及用户信息即可。挑战三：如何从友户通单点登录到企业 IdP 先登录友户通，然后登录企业 IdP. 如果实现了企业 IdP 登录到友户通，那么自然会有需求从友户通登录到企业 IdP. 不过，这种方式需要企业 IdP 做一些定制开发。友户通目前支持 CAS、oauth2 标准协议以及友户通自定义协议可供企业 IdP 集成。未来将支持 SAML2 的协议供企业 IdP 集成。友户通提供前端登录状态检测 js（支持 jsonp），可检测友户通是否已经登录以及进行 CAS 发票。友户通还提供了 js 方法获取 oauth2 的 code（支持 jsonp），供 oauth2 方式进行单点登录实现。挑战四：企业用户中心外网无法访问企业自有用户中心通常是部署在企业内网的，外网访问不了。这种情况一般有几种解决方式。第一种：让企业开辟外网端口，让外网能访问，但这种方式会让企业的内部用户中心暴露在公网，企业可能会有一定的顾虑。第二种：将外网调用变成内网调用，在企业内部部署一个应用当做中介，只暴露这个新部署的应用。我们选择了第二种方式，这种方式不会暴露企业的用户中心到公网上，打消企业的顾虑。需要开发一个应用当做中介，我们称为代理（下称 yhtagent）。yhtagent 和友户通直接的通信采用 HTTPS 保密通信，如果企业还嫌不够安全，可以在消息内部在使用 AES 或者 RSA 等对称或者非对称加密算法进行加密，从而保证通信内容的绝对安全。使用 YhtAgent 时的联邦身份认证 LDAP 类型的用户中心，Yhtagent 实现友户通到企业单向代理；CAS 类型的用户中心，Yhtagent 实现友户通到企业双向代理。
