本文记录了在2010年上海交通银行卡中心内网项目中，遇到的用户管理、身份认证、单点登录等与IDS相关的问题及解决方案。
关于内网门户建设的问题，本文不过多提及，可以参见王纯刚整理的《感受有战斗力的上分交行内网项目实施团队》一文。
上海交通银行信用卡中心（以下简称交行卡中心）于2004年成立，是交通银行下属的独立核算单位，负责全国交行信用卡业务。交行卡中心总部设在上海，其下设内设运营部、风险部、市场部、财务部、IT部、人力资源部、合规部、内审部、呼叫中心等部门，并在全国各大主要城市设有办事处。
交行卡中心于2010年与TRS合作，使用Portal+WCM +IDS建设内网门户。
2.1复杂的网络环境
交行卡中心总部共有一万多人，人员比较庞杂，有人员流动性较大的呼叫中心，还有各个相关厂商的外包和临时支持人员等。由于交行卡中心总部保存着非常重要的全国交行信用卡数据，因此他们的对信息系统的管理非常严格和规范。
在网络管理上，交行卡中心将网络划分为两个网段：
●生产网段：保存有全国信用卡数据，信用卡业务相关的生产系统都运行在这个网段之内，仅有必要的人员能够接入。
●办公网段：用于日常办公，所有员工和外包人员均可接入。
两个网段之间只能通过两个叫做IBM Data Power（以下简称IBM DP）的硬件设备相连接。IBM DP可以认为是一个可编程的、功能强大的安全网关，如果未经过IBM DP的授权，两个网段之内的设备无法进行通信。
两个网段内的工作站中，都由MicroSoft的AD域服务器进行控制。想要登录工作站，必须先在MicroSoft AD创建相应的账号。其中，生产网段的AD中的账号是办公网段AD的子集，两个AD之间会定期自动同步。
简要的网络结构，如下图所示：
图1网络结构
2.2 TRS产品的部署结构
由于交行卡中心的安全要求，以及绝大多数用户都在办公网段的实际情况，TRS的产品都部署在办公网段，其部署结构如下图所示：
图2 TRS产品的部署结构
2.3用户从何而来
AD是交行卡中心的唯一用户和组织的出处，所有的组织机构和人员（包括人员的密码）都由专门的部门在AD中进行维护。
针对这种情况，对于TRS产品，需要考虑两类问题的处理：
1）历史用户怎么办
由于交行卡中心的管理规定，不可能将用户的管理转到IDS当中，而AD中已有的历史用户必须要能够正常的登录WCM和Portal。
对于这种情况，如图2的部署结构所示，IDS采用外部源的方式，直接接到办公网段的AD中，这样AD中的已有用户可以直接使用原有用户名和密码登录与IDS集成的系统。关于IDS集成AD的介绍，请见内网中的这个帖子。
2）新增的用户和组织怎么办
除了已有历史用户以外，还需要考虑新增和删除用户的问题。新增的用户需要由IDS同步到WCM和Portal中进行预授权，删除的用户也要通知WCM和Portal进行处理。另外，AD中的组织结构也需要同步到WCM中，组织机构的
对于这个需求，IDS提供了一个可以单独部署的AD用户组织同步模块，这个模块的基本工作原理是每天对AD进行一次扫描，将当天新增/已删除的用户和组织通知给WCM和Portal进行处理。
2.4身份认证和单点登录怎么进行
交行卡中心的单点登录需求有一些特殊。客户希望不管是在生产网段还是办公网段，每个用户使用AD的账号登录工作站以后，打开浏览器访问内网门户时，即处于已登录状态，无需再次输入用户名和密码。并且处于安全上的考虑，不允许在工作站上部署任何客户端。
对于这个需求，我们给出了两个实现方案。
方案1：由IDS实现自动认证
IDS支持国际标准的Kerberos协议，通过Kerberos与工作站和AD交互，可以达到不在工作站部署任何客户端，就实现自动登录的效果（这个就是我们之前介绍过的“IDS与AD无缝集成”）。大致的认证过程如下：
①用户使用自己的AD账号登录工作站。
②用户打开浏览器，访问内网门户。
③进入IDS的SSO流程，浏览器从内网门户跳转到IDS。
④IDS要求浏览器出示已经认证过的Kerberos凭证。
⑤浏览器将Kerberos凭证提交给IDS，IDS进行解析。
⑥IDS与AD通讯，确认Kerberos凭证所代表的用户的有效性。
⑦用户有效，IDS执行登录。
⑧IDS让浏览器跳转回内网门户。
⑨由于内网门户已经和IDS实现集成，因此此时也处于登录状态。
（其中蓝色字体为IDS需要做的工作）
这个过程技术上已经实现了，但是由于IDS只部署在了办公网（见图2），因此只能实现办公网段内的自动登录。对于生产网段，由于IDS无法连接到其中的AD，因此就无法实现自动登录。因此最后采用了第二种方案。
方案2：由IBM DP实现自动认证
由于IBM DP同时部署在生产网段和办公网段，并且它同样支持Kerberos协议，因此自动登录由其来实现。其大致过程如下：
①用户使用自己的AD账号登录工作站。
②用户打开浏览器，访问内网门户：此时访问实际上是IBM DP的地址，DP在这一步的角色相当于一个反向代理。
③IBM DP进行自动登录：其过程实现得和IDS一模一样，此处不多介绍。
④IBM DP认为该用户有效，生成了一个IBM SSO规范的LTPAToken，同时进行反向代理操作，请求内网门户的实际地址。
⑤由于内网门户已经与IDS集成，因此请求会先被IDS拦截。
⑥IDS解析IBM SSO规范的LTPAToken，找到其对应的AD用户，执行登录。
⑦最终，浏览器看到的就是处于已登录状态的内网门户。
（其中蓝色字体为IDS需要做的工作）
实际上和方案1和方案2没有本质区别，最终都是采用Kerberos协议进行实现。只不过由于IBM DP能够跨网段进行这个操作，所以最终采用了方案2。
实际在这个方案里边，IDS需要做的工作更少，只需要解析IBM的LTPAToken即可。
另外需要说明的是，“在已登录的AD工作站上，访问与IDS集成的应用，无需再次输入用户名和密码就能处于已登录的状态”这个需求，不论是采用方案1还是方案2，对于IDS要集成的应用没有任何影响。换句话说，IDS为应用屏蔽掉了这个过程，应用只需要和IDS做标准集成就可以了，不需要做其他任何改动。
2.5已有大量用户的应用要集成到IDS和Portal怎么办
在交行卡中心中，还有其他一些特殊的应用要和IDS进行集成，以便在Portal中展现资源内容，比如说邮件系统和OA系统。
这类系统有一个特殊的问题，即用户各个系统中已经有了账号。对于这类系统，IDS采用“代理登录的方式”进行集成。
代理登录的方式其实很简单，主要有以下几点：
●应用不需要和IDS进行集成，也不需要进行任何改动。
●IDS提供统一的页面，用户自行绑定IDS账号与各个系统中的账号和密码的关系。
●用户需要登录应用时，点击IDS提供的链接，IDS会取出应用中对应的账号和密码，通过浏览器进行提交。
●IDS会将这些应用名和密码同步给Portal，Portal需要取应用资源时，可以根据用户名和密码自行执行一次登录，或者直接调用应用本身提供的API获取资源。
以下是IDS中配置一个代理登录应用的界面截图：
图3代理登录应用的配置
对于交行卡中心项目，我们有这么一些收获：
1）企业（尤其是规范的大企业）中，其IT环境通常比较复杂。网络结构复杂，各种历史遗留系统、异构系统也多。另外大企业的管理往往也比较规范和严格。
对于这类客户，TRS的应用产品要打进去，是一个不小的挑战。而交行项目证明了，IDS有能力屏蔽掉这种复杂性，为公司产品顺利进入提供了有效支撑。
2）对国际规范的支持是有价值的。在身份认证领域，有很多国际规范，比如Kerberos、SAML、IBM SSO规范等，这些国际规范都已经成熟，各个厂商的软件、硬件都对其进行了很好的支持。研究、支持这些规范，能够使我们和其他厂商的产品实现互联互通。在大企业中往往有很多这类基础设施，此时就会凸显我们支持国际规范的价值。
3）整合企业内部的身份，完全可以作为独立的咨询方案来卖。在交行这个项目中，整合身份这部分工作的难度，其实不亚于门户资源的开发。一开始我们没有估计到这部分的工作量，不然完全可以在商务谈判中增加一些砝码。
当时IBM DP这边的leader亲自来交行和我们确定方案、进行联调，最后他对整个方案也是比较满意的，表示回去以后会整理出来作为一个案例。
另外说句题外话，IBM的人一开始对我们能够通过Kerberos进行AD的认证是比较诧异的，因为国内做这块的公司还比较少。到了后来无论是客户、还是IBM的工程师对于我们公司的技术能力都比较服气，IBM的工程师一再打听我们公司的情况，临走还专门要了一份IDS的宣传资料。
当然，这个过程中也暴露了一些不足的地方：
1）产品不够易用，文档也不够清晰和详细。直接后果就是实施人员增加了麻烦和工作量，产品组后续会对这方面进行改进。
2）部分模块质量需要进一步改进。IDS在整个部署结构中处于核心地位，一旦出问题，会影响到所有的应用，因此我们对IDS产品质量的要求应该要更高。
这一点有赖于产品部门和质保部门的紧密配合。我们目前配合质保部门进行的“开发过程的灰盒测试“能够通过有效的软件过程和自动化测试来对软件质量进行保障。
