友户通做用友云的用户系统也一年多了，经常听实施、售前等说要私有化部署友户通，原因无非是企业的考虑到用户安全性和单一用户账号的需求。但由于用户管理的复杂性，友户通部署与维护并不容易，因此经常纠结在用户系统是用友户通云服务还是要私有化部署。
企业私有化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实现友户通到企业双向代理。