在对企业应用进行整合时，存在着各种既有自己开发的系统，又有移植，购买来的系统，还有众多旧系统的情形，
这些系统，一般都有自己独立的用户模块，而整合这些不同系统的用户登录，避免让账号飞，则是企业应用整合的一个最基本的要求
要整合企业应用，首先就是要整合账号
整合账号的原则就是，如果用户已经有一个账号，那么尽量地使用它
这个账号，可以是web系统账号，也可以是ERP的账号，还可以是邮件账号，甚至集团内其它子公司过来出差的同事，他们在他们自己的网站已有账号，现在可以让它直接登录出差地的网站
对于web系统，要使用一个账号登录，可以使用以下两种方法：
第一种
是能够直接使用提供方的资源，如可以访问ERP的用户资料库，可以调用B网站的登录web service，可以访问LDAP
并且提供方信任登录网站，允许其直接使用其资源，并且他的用户也不用担心在该网站登录后，会泄漏其密码
满足这两个条件，过程就很简单了
用户只要打开内部网站
输入账号，密码，并且选择用户类别(普通用户，A公司用户，ERP用户)
登录程式根据不同的用户类别，调用不同的登录方式来验证用户，即可完成登录
一般内部各系统，如果各自都有其独立的用户模块，其整合都可以使用这种方法来进行
接下来就是第二种
如集团老总在总公司已经有一个账号，那么当他访问子公司的网站时，可以直接使用其总公司的账号登录子公司网站的订单系统查看报表
这种情况下，网站与网站之间都是各自独立或平等的，如163和sohu，总公司网站和子公司网站，子公司A的网站和子公司B的网站
每个网站有自己独立的用户，只是在某些时候，其中一个网站的用户需要使用另一个网站的程式时，为了避免多账号，因而进行的整合
假设网站A的用户需要访问网站B的程式，则其登录过程可以描述如下：
1.用户在网站A登录，登录成功后，产生token，并暂存token在cache中，然后引导用户转向网站B的地址
如 http://网站B/ssologin.aspx?token=XXXX&source=网站A
2.网站B的ssologin.aspx提取token，并以其作为参数调用网站A的web service
ValidToken(token)
3.网站A验证成功，删除暂存的token，并返回用户ID，告诉网站B，该用户确实在网站A登录过，其用户ID是XXX。远程登录成功
第二种方式和openID相似，只不过后者是专门用来登录，而这里则主要是为了独立网站之间的账号重用和整合
到这里，主要原理已OK，
但是如果没有对登录系统的完整认识，很多时候并不能做好这种借用第三方账号登录的功能
大部分系统在设计登录系统时，往往把账号当作具体应用系统中的用户
虽然账号的确代表一个系统中的用户，但账号与用户必须明确分离其功能
账号是用来登录和让系统授予权限的，而用户则是以某种方式具体地参与系统
例如请假申请系统，用户需要有工号，部门等人事考勤信息，以便在请假成功后，可以与考勤资料相关联
因此系统设计者往往将用户账号，密码和工号，部门等信息设计在一起，以便用户登录后，直接关联其人事资料，为请假申请程式提供基础
但请假系统中的账号，可能根本不需要这些资料
如作为审核者的公司高层或总裁，他可能只要登录系统审核请假单，但是并不需要填写请假单，因此他的用户资料中的工号，部门栏位是无意义的
另一方面，如生产线上的员工，他们可能并不是由自己填写请假单，而是由部门助理代他们填写请假单，因此这些人的资料应该只有工号，部门等人事资料，而不需要使用系统的账号，密码，因为他们并不使用账号密码使用这个系统
以上例子，是为了说明登录系统和应用系统是各自独立的，登录系统并不需要知道其用来检验登录和权限管控外的其它任何信息
因此这些账号可能是代表自己公司的一个员工，也可能是某一家使用其B2B系统的供应商，还可能是提供给第三方专属服务时需要验证的账号，密码，他们之间唯一的相同点就是账号，密码，登录，以及各种登录规则和权限管控。
除此之外，设计在登录系统中的其它任何信息都是多余的
不同地方的账号登录后，在系统中都表现为一个用户唯一标识，如：
850.00
（@后面表示是什么类型的用户，如果没有，则是网站自己的用户）
具体系统对于这些唯一标识，一般都一视同仁，不再因其是不同来源的用户而有所区别，这样这个系统的被整合性将更强
未提及问题：如果一个用户有很多账号，如何合并？ 可以建立map档，在其中任何一个账号登录后，map到主账号然后再进行各种操作
未完待续：企业应用整合(2)--一次登录
