1 SSO的概念
SSO全称为Single Sign On，及单点登录。是指在企业的多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。它是目前比较流行的企业业务整合的解决方案之一。
要真正实现SSO，需要基于以下主要功能：
1.1 统一认证系统
所有应用系统共享一个身份认证系统。统一的认证系统是SSO的前提之一，微软的活动目录（Active Directory）是一个常用的SSO认证工具。只要Windows客户端加入域并开机登录后，从活动目录服务器上获取登录凭证，然后在访问任何启用Windows集成验证的应用，由客户端出具凭证，应用服务器通过活动目录服务器验证凭证，这是一个完整的SSO验证过程。
上述过程中客户端必须加入域并且服务器端应用程序必须是支持Windows集成验证的应用；且客户端和应用服务器必须位于同一个活动目录森林。吉利汽车研究院（以下简称吉利研究院）的除了基于Windows身份验证的系统，比如Exchange、SharePoint、OCS等，还存在大量的非Windows验证的异构系统，如知识管理系统，Windchill，以及HR系统，SAP的ERP系统，以及可能的LAMP架构的WEB应用系统。以前也已经通过CAS的SSO解决方案实现了知识管理系统和AD之间的SSO。但是CAS存在版本更新比较慢、最新标准支持少，对NTLM支持不好、以及性能等问题。为了突破这些限制，让更多的第三方异构应用能够和Windows客户端之间实现单点登录，我们采用了微软一个架设在活动目录之上的SSO产品——ADFS，将基于Windows的SSO的扩展到了Internet以及非Windows系统，采用新的ADFS加上自己自定义开发的符合Web服务(WS)-*互操作性标准的SSO Filter。
1.2 统一组织架构：
吉利研究院通过微软的活动目录（以下简称AD）管控企业的统一组织架构，并通过整合各个系统的组织架构，通过读取用户的组织结构数据库来获取流程用户的组织机构信息，并通过AD的改造，使之包含组织机构基本信息管理、岗位基本信息管理、岗位认证管理、拥有岗位的用户管理等。
IT部门已经通过手工方式在现在的活动目录中创建了部分组织结构。SSO首先必须解决跨系统的统一身份验证和中央的组织结构来源。实现基于互动目录的统一身份管理。
组织结构将会通过OU和安全组的混合方式实现。其原因在于：
OU是管理员可见的一种分层方式，对应用和最终用户不可见。换言之，无法通过OU的分层快速实现用户的组织结构信息查询。但是OU支持管理权限的委派，方便管理员的维护。
安全组的组嵌套可以很容易实现组织结构到上下级导航关系。并且能够为其他应用方便使用。通过组实现组织结构和权限控制是一种比较流行的LDAP数据建模方式，比如，Windchill中也是通过组实现组织结构和权限控制。
综合上述原因，为了在活动目录中实现组织结构信息，我们采用OU和安全组混合的建模方式。下面是一个AD中的示意图。
图1 活动目录组织架构图
2 SSO的应用
在吉利研究院，用户的电脑都已经加入到AD域。 用户在登录他们的工作电脑后，在访问各种应用的时候，包括Outlook、Lync、OWA、Sharepoint，知识管理系统等，无需重新输入用户名和密码，这种单点登录（SSO）的功能既方便了用户的使用，也增强了系统安全性。
吉利研究院除了微软的产品，还存在其他的在几个大型的应用系统，包括在协作商务系统，PLM系统和SAP等，我们将通过导入ADFS的方式实现全面的可扩展的SSO。
2.1 协作商务系统的SSO应用
吉利协作商务系统本质上是一款C/S架构的应用系统，但是提供的登录界面却是一个HTML网页程序。对于实现SSO，还是基于ADFS SSO框架，为协作商务系统登录网站开发ADFS WEB AGENT。同时，在AD账号和CPC的中文登录名之间建立映射关系。比如，所有用户在AD中显示名必须是CPC系统中的中文登录名。该方案的特点是安全性高，而且借助于ADFS的灵活架构，可以一套应用系统对应多套AD系统（无论是否在同一个森林还是没有任何关系）。
2.2 知识管理系统的SSO应用
知识管理系统是研究院自主开发的知识管理平台，其基本架构是Apache +Tomcat+Java+Oracle。目前已经实现了CAS+KERBEROS AGENT的SSO。只要重新开放一个ADFS WEB AGENT即可实现SSO。
2.3 Windchill的SSO应用
Windchill是PTC的PLM产品生命周期管理系统，是制造研发型企业最重要的业务系统，其基本架构和知识管理系统比较相似，也是Apache+Tomcat。但是，有两个重要的差异导致目前没有实现SSO。Windchill部分页面上有Java Applet，这些Applet会通过RMI访问服务器上的Java服务。而其连接中使用的是基本验证方法。这导致Applet一定必须获取到一个明文的用户名和密码；Windchill的Tomcat层需要访问方法服务器，使用的也是RMI方式。所以，也必须使用明文的用户名和密码。
在典型的ADFS的SSO方案中，Application把用户身份验证的职责委托给了ADFS WEB AGENT插件，其本身不需要明文的密码。因此，如果要实现真正安全的SSO方案，需要解决两个难点：用户密码问题。一个用户在登录Windows后，然后访问ADFS兼容应用系统时，应用系统上安装的Web Agent插件会把用户请求重定向到ADFS服务器。ADFS服务器通过KERBEROS/NTLM验证过用户后，再重定向到应用系统。重定向的请求中包含用户信息的令牌（Token），插件解码令牌，把用户信息传递给Apache或者Tomcat。上述过程中，用户的密码没有在网络中传输过，所以无论是ADFS还是应用系统的Web Agent插件都没有用户的密码。如果我们要复制类似的过程到Windchill，那么RMI的调用就会出现问题。用户信息同步问题。AD中的用户和Windchill的用户是需要统一的。否则，AD验证过的用户在Windchill中不存在，显然是不能访问的。
针对上述难点，具体通过以下方案解决：Windchill上开发程序，将AD中的标注为Windchill用户的AD账号同步到Windchill系统。同步的目的地包括LDAP，也包括PLM内部的用户数据库。这个过程是批量运行。在Windchill系统中，开发密码重置模块。对于所有的非系统用户，把用户的密码改为一个计算的密码。计算的过程大致是根据一个唯一标识用户的信息（用户名，SID等）通过加密得到一个值，在编码成字符串后作为密码。开发Windchill的Web Agent，在用户通过AD的验证后，根据验证过的用户名计算得到密码。插件将用户名和密码传递给Tomcat。
2.4 SAP的SSO应用
吉利研究院的SAP系统，主要模块都将通过SAP的统一前端SAPgui登录，而SAP本身是基于IBM小型机和AIX平台。因为SAP是一个非常成熟的成品，从SAPgui到服务器端都已经有了大量的SSO成功案例，其ADFS SSO的架构类似，关键点在于开发一个安全验证模块，替换SAPgui默认的模块，同时在SAP服务器端实现AD身份验证。
3 总结
企业在经历信息系统从无到有后，会面临从单体应用到集成整合的问题，SSO给企业解决的是最基础的身份验证和系统登录的问题，在这一问题解决后，才能进行更深层次的系统应用集成，比如跨系统的数据交互、统一权限管理、统一业务流程等都是基于SSO进行的企业信息化应用。
企业的SOA使信息系统变得更加灵活，并适应业务带来的改变，信息系统既可以利用现有业务系统的功能，又可以准备在将来做一些变更来满足业务和系统之间交互的需要，企业要最终实现SOA，SSO是必经之路。
转载请注明出处：拓步ERP资讯网http://www.toberp.com/
本文标题：企业应用系统的SSO
相关文章
