BOS_V6.3_BOS实施指南_单点登录(V2.0版)

前  言
　　　本指南共分为六个章节，第一章介绍了单点登录的概念和作用，以及EAS支持的单点登录集成方案；第二章分析了单点登录的需求分析和实施过程；第三章分析了EAS单点登录各集成方案的具体实施和配置步骤；第四章介绍了EAS与其他第三方单点登录方案的集成方法；第五章介绍了单点登录的相关知识；第六章是FAQ

 

适用对象
　　　本指南适用于EAS单点登录设计和开发人员，需要进行EAS单点登录集成的实施及二次开发人员，以及想了解BOS单点登录的开发者。
　　　通过本指南的学习可以使实施或开发人员掌握将EAS与其它第三方系统快速进行单点登录集成的方法和技巧。

 

目  录

前  言 2
适用对象 3
目  录 4
第一章  概述 6
1.1 什么是单点登录 6
1.2 单点登录的作用 6
1.3  EAS的单点登录 6
1.3.1 EAS支持的单点登录集成方案 6
1.3.2 EAS的单点登录技术服务组件 7
第二章  单点登录需求分析及实施 9
2.1 用户单点登录集成需求调研 9
2.2 确定单点登录集成实现方案 9
2.3 制订单点登录集成实现计划 9
2.4 开发配置实现单点登录集成 9
第三章  单点登录认证服务的集成与实现 11
3.1 用户认证校验处理器 11
3.1.1 EAS标准产品支持的认证处理器 11
3.1.2 注册和配置认证处理器实现类 11
3.1.3 扩展第三方用户认证的认证处理器 13
3.1.4 扩展认证处理器参考实现EAS 用户认证登录配置 15
3.1.5 EAS用户认证登录类及相关配置 15
3.2 LDAP域认证方案的配置与实现 16
3.2.1 LDAP服务器连接参数配置 16
3.2.2 配置LDAP域用户认证处理器 17
3.3 微软AD域认证方案的配置与实现 17
3.3.1 AD域服务器连接参数配置 18
3.3.2 配置EAS用户认证登录类 19
3.2.3 配置微软AD域用户认证处理器 19
3.3 LTPA认证方案的配置与实现 19
3.3.1 配置密钥文件 20
3.3.2 LTPA Token加密和校验接口介绍 20
3.3.3 第三方应用集成EAS portal的实现步骤 21
3.3.4 EAS portal集成第三方应用的实现步骤 23
3.4 用户集成组件 24
3.4.1 用户数据导入 24
3.4.2 用户映射管理 28
3.4.3 用户集成参数配置 29
3.4.4 定义用户数据周期同步后台事务 30
3.4 CAS集成组件 32
3.4.1 CAS服务器参数配置 32
3.4.2 新增EAS登录所需要参数的配置文件 33
3.4.3 安装EAS支持第三方CAS服务器的相关补丁 34
第四章  EAS其它单点登录集成方案 35
4.1 EAS portal与WebSphere全局安全性单点登录方案的集成 35
4.1.1 EAS企业应用程序 (eas.ear) 的配置 35
4.1.2 EAS Portal Web应用程序 (cp_web.war) 的配置 36
4.1.3 基于FORM认证登录页面的开发 38
4.1.4 使用管理控制台部署EAS 41
4.2 基于IBM JDK的EAS集成微软AD域认证的方案 43
4.2.1 AD认证服务器和EAS服务器独立部署方案介绍 43
4.2.2 搭建和配置AD域认证服务器 43
4.2.3 搭建和配置EAS服务器 43
4.3 EAS portal与Domino 7.0的集成 44
4.3.1 Domino Web SSO 配置步骤 44
4.3.2 密钥文件生成步骤 63
4.3.3 DOMINO应用集成配置步骤 66
第五章  单点登录的相关知识介绍 68
5.1 域相关概念和术语介绍 68
5.1.1 目录 68
5.1.2 目录服务 70
5.1.3 专有名称（DN） 70
5.1.4 DN 转义规则 71
5.1.5 增强的 DN 处理 72
5.1.6 后缀(Suffix) 72
5.1.7参照(Referrals) 72
5.1.8 模式(Schema) 73
5.1.9 对象类(objectClass) 73
第六章  FAQ 76
6.1 独立部署后web框架需要重新登录问题 76
术  语 77
附  录 78
附录1：JAAS 78
附录2：Kerberos 78
附录3：LTPA 79

 

 

第一章  概述

1.1 什么是单点登录
　　　单点登录(Single Sign On)，简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的一个通用的定义是：在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统，而无需进行多次登录。

1.2 单点登录的作用
　　　通过单点登录技术可以对企业各异构应用系统的登录流程及用户管理进行集成，使企业可以采用统一的认证方式，使企业用户只需要登录一次即可访问各应用系统，从而提高企业各应用系统的易用性。

1.3  EAS的单点登录

1.3.1 EAS支持的单点登录集成方案
　　　EAS的标准产品中支持以下几种单点登录集成及认证方案：
　　　(1) LDAP ( 轻量目录访问协议：Lightweight Directory Access Protocol ) 域认证方案
　　　(2) 微软AD ( 活动目录：Active Directory ) 域认证方案
　　　(3) LTPA ( 轻量级第三方认证：Lightweight Third Party Authentication ) 认证方案
　　　(4) CAS ( 中央认证服务：Central Authentication Service ) 集成认证方案
　　　(5) 基于WebSphere全局安全性认证方案
　　　其中，LDAP域认证方案可以使EAS支持登录时通过LDAP服务器对用户进行认证和校验；微软AD域认证方案可以使EAS支持登录时通过微软AD域服务器对用户进行认证和校验；LTPA认证方案可以使EAS和其它第三方Web应用系统进行单点登录集成；CAS集成认证方案可以使EAS portal支持使用其它标准的CAS服务器进行单点登录；基于WebSphere全局安全性认证方案可以使EAS与WebSphere全局安全性进行单点登录集成。

1.3.2 EAS的单点登录技术服务组件
　　　EAS的单点登录技术主要提供以下三个服务组件：
　　　(1) 用户认证校验处理器
　　　(2) 用户集成管理器
　　　(3) CAS单点登录集成组件

1.3.2.1 用户认证校验处理器
　　　用户认证校验处理器主要用于定义认证接口，实现EAS支持的单点登录用户认证的不同方案，在用户进行EAS系统登录时采用用户所配置的认证方案进行认证。
　　　用户认证校验处理器支持对其它第三方认证进行扩展，通过二次开发实现认证接口，调用第三方认证逻辑，实现第三方用户认证。
　　　EAS标准产品支持提供以下处理器：
　　　(1) EAS 传统认证处理器，即：用户名密码认证
　　　(2) LDAP域认证处理器
　　　(3) 微软AD域认证处理器
　　　(4) LTPA认证处理器

1.3.2.2 用户集成组件
　　　用户集成组件主要用于将第三方数据源的用户账号信息集成导入同步到EAS系统中，并且与EAS系统中的用户建立起对应的映射关系；其主要包括用户数据导入和用户映射两个管理模块。
　　　目前EAS支持的导入数据源的类型主要是LDAP服务器 (包括微软AD域服务器)。(注：集成数据库类型的数据源可通过EAI平台来完成)

1.3.2.3 CAS单点登录集成组件
　　　CAS是一套开源的基于Java语言的单点登录服务框架，它以 Filter (过滤器) 的方式保护 Web 应用的受保护资源。
　　　过滤器过滤从客户端过来的每一个 Web 请求，同时 CAS Client 会分析 HTTP 请求中是否包请求 Ticket ( 即：图1.1中的凭证)。
　　　如果没有，则说明该用户是没有经过认证的，于是，Filter 会重定向用户请求到认证服务。
　　　用户认证成功后， 认证服务会产生一个随机的 Ticket，然后缓存该 Ticket并且重定向用户到访问应用。
　　　部署应用与认证服务间通过ticket完成了一个对用户的身份核实。

图1.1  CAS单点登录集成访问应用跳转流程图

 

第二章  单点登录需求分析及实施

　　　分析和实现客户单点登录集成需求主要有以下几个步骤：
2.1 用户单点登录集成需求调研
　　　需求调研阶段需要详细对客户现有的业务系统进行调研，了解清楚客户期望的单点登录集成的效果和目标。
　　　调研参考内容有如下几点：
　　　(1) 各业务系统使用状况；包括业务系统的运行环境、用户数据库和应用规模、用户数量等信息。
　　　(2) 各业务系统的用户登录过程说明；包括各业务系统在登录时需要进行的验证过程和验证所需信息等。
　　　(3) 单点登录集成需求目标；包括用户期望达到的单点登录集成目标，界面流展现其单点登录过程和要求，以及基准用户库( 原有业务系统数据库、新数据库或者LDAP服务器)等
　　　
2.2 确定单点登录集成实现方案
　　　确定实现方案阶段主要做以下几个工作：
　　　(1) 首先确定基准用户库及用户管理工具
　　　(2) 然后制订各系统与基准用户库的映射和同步策略
　　　(3) 最后确定单点登录集成实现方案

2.3 制订单点登录集成实现计划
　　　制订计划阶段因各业务系统的运行环境可能差异比较大，可能是异构平台，用户的统一和同步映射处理也需要时间，已有系统也在线使用中，因此，需要制订好详细的实现计划，以规避和降低风险。

2.4 开发配置实现单点登录集成
　　　开发集成阶段主要做以下几个工作：
　　　(1) 根据各业务系统实际情况，进行相应接口的开发(包括用户同步/映射)
　　　(2) 完成开发后进行相关配置
　　　(3) 部署单点登录集成实现方案并在测试环境进行测试

第三章  单点登录认证服务的集成与实现

3.1 用户认证校验处理器

　　　用户认证校验处理器是单点登录集成过程中，某一种认证方式具体的认证逻辑的实现，EAS标准产品中支持几种常用的认证处理器，同时也支持二次开发扩展自己的认证处理器。

3.1.1 EAS标准产品支持的认证处理器
　　　EAS标准产品支持的认证处理器信息如表3.1所示：
　　表3.1  EAS支持的认证处理器
认证处理器 名称 认证处理器实现类 说明
EAS 传统(用户名密码)认证 BaseDB com.kingdee.eas.cp.eip.sso.EasDefaultAuthHandler EAS传统认证，基于EAS数据库中的用户名密码进行认证校验
LDAP域认证 BaseLDAP com.kingdee.eas.cp.eip.sso.ldap.LdapAuthHandler 基于LDAP协议的目录用户认证
微软AD域认证 BaseAD com.kingdee.eas.cp.eip.sso.ad.ActiveDirAuthHandler 基于微软活动目录(AD)进行用户管理，采用kerberors LoginModule进行认证校验
LTPA认证 BaseTrdLtpaToken com.kingdee.eas.cp.eip.sso.ltpa.LtpaTokenAuthHandler LTPA Token认证

3.1.2 注册和配置认证处理器实现类
　　　在确定了单点登录集成的认证方案后，需要通过配置来切换不同的认证处理器，从而实现不同的单点登录认证方案。其配置方法如下：
　　　首先，在服务器server\deploy\portalConfig目录下打开认证处理器的配置文件easAuthPatterns.xml，其配置内容及格式如下：
　　　<authPatterns>
　　　   <authPattern>
　　　  <name>BaseDB</name>
　　　  <displayName>BaseDB</displayName>
　　　  <authHandler>com.kingdee.eas.cp.eip.sso.EasDefaultAuthHandler</authHandler>
　　　  <description> Base Eas user table authentication,is Eas default Authentication</description>
　　　 </authPattern>
　　　 <default>BaseDB</default>
　　　 <scope>session</scope>
　　　</authPatterns>
节点及参数说明：
　　　(1) authPattern节点：表示某种认证处理器，包括：name、displayName、authHandler和description四个属性；
a)  name：认证处理器名称，请使用英文字母命名，且需在整个文档中命名唯一
b)  displayName：认证处理器显示名称；
c)  authHandler：认证处理器实现类的全路径类名；
d)  description：认证处理器的描述信息。
　　　(2) default节点：表示EAS缺省使用的认证处理器，该值为配置文件中已定义authPattern节点的name值
　　　(3) scope节点：表示EAS认证处理器的作用域，scope 仅能取以下值：
a)  application：EAS统一采用一种认证处理器，即由 default节点指定的认证处理器
b)  session：EAS允许用户根据工作场所，选择不同的认证处理器；如：外网可使用EAS传统认证、内网则使用AD认证(即域用户认证)
　　　注意：EAS Portal标准产品的登录窗口未提供认证模式选择项，即此方式是为了与第三方系统集成预留的，以便可通过URL参数authPattern或进行登录页个性化开发来指定用户登录认证模式。
　　　如：以下URL为指定AD域用户自动登录
　　　http://portalServer:port/easportal/autoLogin.jsp?authPattern=BaseADWithAutoLogin
　　　然后，加入新的认证处理器 (即：authPattern节点) 并且将EAS缺省使用的认证处理器修改成该节点名称 (即：修改default节点) ，例如，现在需要将EAS的认证方式改成LTPA认证，则增加及修改的配置信息如下：
　　　<authPatterns>
　　　   <authPattern>
　　　  <authPattern>
　　　        <name>BaseTrdLtpaToken</name>
　　　        <displayName>BaseTrdLtpaToken</displayName>
　　　        <authHandler>com.kingdee.eas.cp.eip.sso.ltpa.LtpaTokenAuthHandler</authHandler>
　　　        <description>Base third system's Lightweight Third Party Authentication</description>
　　　    </authPattern>
　　　 <default>BaseTrdLtpaToken</default>
　　　 <scope>session</scope>
　　　</authPatterns>
　　　另外，EAS标准产品中默认配置用户名密码认证处理器，即上面举例的第一段配置信息。

3.1.3 扩展第三方用户认证的认证处理器
　　　如果EAS提供的认证处理器并不能满足客户的需求，则EAS也支持二次开发对用户认证处理器进行扩展，以实现其它的认证方案。其实现步骤如下：
　　　(1) 实现EAS用户认证处理器统一接口，接口定义如下：
　　　/*  EAS SSO认证处理器接口 */
　　　public interface IEasAuthHandler
　　　 /**
　　　  * 获取外部系统所映射的EAS USER名称
　　　  */
　　　 public String getEasUserNumber(Context ctx, String externalUserNumber)
　　　 throws BOSLoginException;
　　　 
　　　 /**
　　　  * 是否进行EAS 用户密码校验
　　　  */
　　　 public boolean isVerifyEasUserPwd();
　　　 
　　　 /**
　　　  * 用户认证校验接口
　　　  */
　　　 public boolean authenticate(UserContextCallback userCtxCallback, String userNumber, String password) throws BOSLoginException;
　　　 
　　　}
接口说明：
　　　a) public String getEasUserNumber(Context ctx, String externalUserNumber)
　　　外部系统用户转换为EAS 用户的接口，如：AD用户名转为EAS用户名
　　　b) public boolean isVerifyEasUserPwd()
　　　此接口定义是否需要进行EAS传统用户名和密码的校验
　　　c) public boolean authenticate(UserContextCallback userCtxCallback, String userNumber, String password)
　　　此接口为用户认证校验接口，若用户认证通过，则返回true，若不通过则返回false
　　　(2) 将新开发的用户认证处理器部署到EAS服务器环境中，并采用3.1.2节中的方法将该用户认证处理器注册成EAS缺省使用的认证处理器。

3.1.4 扩展认证处理器参考实现EAS 用户认证登录配置
　　　EAS提供的微软AD域认证处理器实现用户认证处理器接口的代码如下：
/* AbstractEasAuthHandler类实现了IEasAuthHandler接口*/
public class ActiveDirAuthHandler extends AbstractEasAuthHandler {
 public boolean authenticate(UserContextCallback userCtxCallback,
   String userNumber, String password) throws BOSLoginException {
  boolean result = false ;
  LoginContext lc = null ;
  try {
   /* Set up the Callback handler, and initialise the userid and password fields */
   UserPwdCallbackHandler ch = new UserPwdCallbackHandler();
   ch.setUserId(userNumber);
      ch.setPasswords(password);
   /* Initialise the login context */
        /* set to use Krb5LoginModule. */
   /* 实际用户认证由com.sun.security.auth.module.Krb5LoginModulele类处理 */
   lc = new LoginContext(ActiveDirAuthHandler.class.getName(), ch);
　　　　　　　/* Perform the authentication */
　　　　　　lc.login();
   result = true ;
  } catch (LoginException le) {
  }
  return result;
 }
}

3.1.5 EAS用户认证登录类及相关配置
　　　EAS 用户认证采用了标准的JAAS (JAVA认证和授权服务：Java Authentication and Authorization Service) 的服务，JAAS的详细信息请参见附录1用户认证的LoginModule类可很方便的插拨或堆叠，其配置是通过服务端\server\properties目录下的login.config文件来实现的，login.config文件配置了EAS 默认使用的LoginModule，通常情况下，该配置文件无须更改，该配置文件内容如下：
eas {
    com.kingdee.eas.cp.eip.sso.EasMultiAuthLoginModule required debug=true;
};

com.kingdee.eas.cp.eip.sso.web.auth.EASAuthHandler {
    com.kingdee.eas.cp.eip.sso.EasMultiAuthLoginModule required debug=true;
};

com.kingdee.eas.cp.eip.sso.ad.ActiveDirAuthHandler
{
 com.sun.security.auth.module.Krb5LoginModule required client=TRUE debug=true useTicketCache=FALSE;
};
说明：
(1) eas为EAS GUI客户端登录时所用LoginModule
(2) com.kingdee.eas.cp.eip.sso.web.auth.EASAuthHandler 为 EAS portal登录时所用LoginModule (注：实际上与eas的配置内容是相同的)
(3) com.kingdee.eas.cp.eip.sso.ad.ActiveDirAuthHandler 则用于与微软AD域认证集成，即在AD认证模式 (BaseAD) 下，此配置才起作用；

3.2 LDAP域认证方案的配置与实现
　　　LDAP域认证方案可以通过配置实现EAS GUI客户端和portal登录时用户在LDAP服务器上进行认证，其配置步骤如下：

3.2.1 LDAP服务器连接参数配置
　　　在服务端server\profiles\server1\config\portalConfig目录下的ldapConfig.properties文件用于配置连接LDAP服务器的参数，文件内容如下：

contextFactory=com.sun.jndi.ldap.LdapCtxFactory
ldapHost=192.168.16.2
ldapPort=389
authentication=simple
principal=username
credentials=password

参数说明：
(1) contextFactory：LDAP连接默认工厂类，
如果服务器使用的是Sun的JDK则应配置为：com.sun.jndi.ldap.LdapCtxFactory 如果服务器使用的是IBM的JDK则应配置为：com.ibm.jndi.ldap.LdapCtxFactory
(2) ldapHost：LDAP目录服务器IP地址
(3) ldapPort：LDAP目录服务器端口号，通常情况下缺省是389
(4) authentication：LDAP连接认证模式，通常情况下配置为simple
(5) principal：LDAP证书的名称，通常情况下配置为username
(6) credentials：principal的密码，通常情况下配置为password
　　　将实际采用的LDAP目录服务器IP地址和端口号配置到该文件中。

3.2.2 配置LDAP域用户认证处理器
　　　按照3.1.2节所述方法将LDAP域用户认证处理器配置到easAuthPatterns.xml文件中，LDAP域用户认证处理器的authPattern节点定义如下：
<authPattern>
 <name>BaseLDAP</name>
 <displayName>BaseLDAP</displayName>
 <authHandler>com.kingdee.eas.cp.eip.sso.ldap.LdapAuthHandler</authHandler>
 <description> Base LDAP Authentication</description>
</authPattern>

3.3 微软AD域认证方案的配置与实现
　　　微软AD域认证方案可以通过配置实现EAS GUI客户端和portal登录时用户在微软AD域服务器上进行认证，其配置步骤如下：
　　　(注意：由于AD域认证的实现需要使用Sun JDK 中的com.sun.security.auth.module.Krb5LoginModule类，而IBM JDK中的该类的实现和Sun JDK的实现完全不同，所以EAS 的微软AD域认证处理器只支持Sun JDK而不支持IBM JDK，如果EAS服务器环境中使用IBM JDK 则需要采取其它解决方案，请参见4.2节内容)

3.3.1 AD域服务器连接参数配置
　　　EAS采用基于Kerberos认证的配置文件与AD域服务器进行连接，Kerberos的详细信息请参见附录2，在服务端server\properties目录下的krb5.conf文件用于配置连接AD域服务器的参数，文件内容如下：

[libdefaults]
        default_realm = KINGDEE.COM
        default_checksum = rsa-md5
　　　　　clockskew  = 360
[realms]
        KINGDEE.COM= {
                kdc = 192.168.16.2
        }
[domain_realm]
 .kingdee.com = KINGDEE.COM
[logging]
        default = FILE:E:/EAS4.1/apusic/logs/default.log
        kdc = FILE:E:/EAS4.1/apusic/logs/kdc.log
        admin_server = FILE:E:/EAS4.1/apusic/logs/kadmin.log
      kdc_rotate = {
        period = 1d
        versions = 10
      }

参数说明：
(1) default_realm：为AD域控制全限定域名 (例如：KINGDEE.COM)，注意：此参数值中的字母必须大写，如上配置参数所示。
(2) kdc ：为AD域服务器IP地址，注意：该参数外层的参数必须同default_realm定义的域名相同，如上配置参数所示。
(3) domain_realm：该段中定义了应用实际域名或主机名和AD域名的映射关系，其定义格式和规范如上配置参数所示，一般为：.域名称(小写，最前面有个点) = 域名称(大写)。
　　　实际使用中，用户只需要配置上面红色字体标注的部分，将实际采用的AD域服务器的域名和IP地址配置到该文件中。

3.3.2 配置EAS用户认证登录类
在服务端\server\properties目录下的login.config文件中加入以下配置参数：com.kingdee.eas.cp.eip.sso.ad.ActiveDirAuthHandler
{
 com.sun.security.auth.module.Krb5LoginModule required client=TRUE debug=true useTicketCache=FALSE;
};

3.2.3 配置微软AD域用户认证处理器
　　　按照3.1.2节所述方法将微软AD域用户认证处理器配置到easAuthPatterns.xml文件中，AD域用户认证处理器的authPattern节点定义如下：
<authPattern>
　<name>BaseAD</name>
　<displayName>BaseAD</displayName>
　<authHandler>com.kingdee.eas.cp.eip.sso.ad.ActiveDirAuthHandler</authHandler>
　<description> Base Microsoft AD Authentication</description>
</authPattern>

3.4 LTPA认证方案的配置与实现
　　　LTPA是一个基于web的认证框架，LTPA的详细信息请参见附录3，EAS的LTPA认证方案是一种基于web的加密认证机制，通过EAS portal与第三方web应用系统进行集成，可以实现只需登录一次即可相互进行访问，其配置步骤如下：

3.4.1 配置密钥文件
　　　服务端server\profiles\server1\config\portalConfig目录下的LtpaToken.properties文件即为LTPA Token 加密串的密钥，文件内容如下：

cookie.domain=.vanke.com
token.expiration=30
domino.secret=BTfa8F+HwNejYEGtuZSJTWOZ/t8\=

参数说明：
(1) cookie.domain：与Domino集成时才有用的参数，通常无需关注
(2) token.expiration：token串的有效时间，这里以分钟为单位，用于校验token串时检查其是否过期，其有效时间从生成token串时Web应用的系统时间开始算起，因此，LTPA认证集成机制要求被集成的各Web应用服务器的系统时间需要保持一致
(3) domino.secret：加密生成token串的密钥，该参数可以是任意指定的一个字符串，没有长度限制，而且建议定期更换该密钥以增加安全性。
　　　该文件需要在EAS服务器环境和要集成Web应用系统的环境中各保存一份，且密钥必须相同，注意：在EAS服务器环境中该文件的存放路径不用改变，即上述缺省路径即可，在第三方Web应用系统中该文件的存放路径可任意指定 (例如：D:\TrdWebApp\security)。

3.4.2 LTPA Token加密和校验接口介绍
　　　在服务端server\lib\server\bos目录下的cp_sso-server.jar包包含了LTPA Token的生成和校验工具类com.kingdee.eas.cp.eip.sso.ltpa.LtpaTokenManager类，该类主要接口定义如下：

public static LtpaToken generate(String canonicalUser,String configFile);
public static boolean verifyToken(String path, String token, String userNumber);

接口说明如下：
(1) public static LtpaToken generate(String canonicalUser,String configFile);
　　　该接口主要用于使用密钥文件LtpaToken.properties生成LTPA Token加密串。
　　　参数说明：
　　　a) canonicalUser：登录用户账号
　　　b) configFile：LtpaToken.properties文件全路径 (例如：D:\TrdWebApp\security\LtpaToken.properties)
　　　
(2) public static boolean verifyToken(String path, String token, String userNumber);
　　　该接口主要用于校验LTPA Token串的合法性。
　　　参数说明：
　　　a) path：LtpaToken.properties文件全路径 (例如：D:\TrdWebApp\security\LtpaToken.properties)
　　　b) token：使用generate接口生成的LTPA Token加密串
　　　c) userNumber：使用generate接口生成的LTPA Token加密串时传入的登录用户账号

3.4.3 第三方应用集成EAS portal（即：在第三方应用中打开EAS portal）的实现步骤
　　　在第三方Web应用系统中集成EAS portal通常指，在第三方系统中增加一个EAS portal的访问地址，然后在再登录到第三方系统后，通过该访问地址可以直接进入到EAS portal中，该方案需要EAS portal和第三方系统都要做一些配置或开发工作，其集成步骤如下：
　　　EAS系统需要做的配置工作：
　　　(1) EAS 6.0 及sp1版本需要安装补丁PTM037265，EAS 7.0 sp1及以后版本则缺省包含该补丁内容；
　　　(2) 将服务端server\profiles\server1\config\portalConfig目录下的ssoClient.properties文件中的sso.easIsSSOClient参数项的值修改为true；
　　　(3) 将服务端server\profiles\server1\config\portalConfig目录下的autoLoginConfig.properties文件中的datacenter参数修改为EAS portal要登录的数据中心代码 (即：数据中心id)，并且将authPattern参数修改为BaseTrdLtpaToken；
　　　(4) 重新启动EAS 服务器；
　　　
　　　第三方系统需要做的开发工作：
　　　(5) 将LTPATokenManager.jar包（该包请联系金蝶的工程师获取）部署到第三方系统中；(注意：此方式只针对于第三方系统基于java语言实现，如果是基于.net 语言实现的系统则无法直接使用Token加密和校验java接口，需要以web service的方式调用Token加密和校验服务)
　　　(6) 在第三方系统中增加如下代码逻辑：
　　　a) 获取登录用户账号
　　　b) 使用LtpaTokenManager的generate方法生成LTPA Token加密串
　　　c) 访问EAS portal的单点登录请求地址：
　　　http://<ip>:<port>/easportal/index2sso.jsp?username="+username+"&password="+password+"&redirectTo="+redirectTo
　　　其中，参数username为登录用户账号；参数password为Token加密串；参数redirectTo为登录后跳转的portal应用的地址。
　　　注：通常情况下如果只需要直接登录到portal的主页，则可以删除红色部分redirectTo参数

示例jsp代码如下：
<%@ page contentType="text/html;charset=UTF-8" %>
<%@ page import="com.kingdee.eas.cp.eip.sso.ltpa.LtpaTokenManager,com.kingdee.eas.cp.eip.sso.ltpa.LtpaToken"%>
<%@ page import = "java.net.URLEncoder" %>
<%
String username = "user";
String password = LtpaTokenManager.generate(username, LtpaTokenManager.getDefaultLtpaConfig()).toString();
/* 处理中文字符串 */
username = URLEncoder.encode(username, "UTF-8");
password = URLEncoder.encode(password, "UTF-8");
String url = "http://192.168.33.243:6888/easportal/index2sso.jsp?username="+username+"&password="+password;
%>
<a href=<%=url%> target="_blank">EAS Portal</a>
　　　完成以上工作后即实现了在第三方应用中集成EAS portal。
　　　另外，如果第三方系统能够提供其它方案获取登录后的用户账号，则上述代码逻辑或jsp页面也可由EAS系统这边进行二次开发，使用第三方系统的方法获取用户账号并进行验证，然后按照上述实现步骤生成Token加密串，访问EAS portal的单点登录请求地址。

3.4.4 EAS portal集成第三方应用（即：在EAS portal中打开第三方应用）的实现步骤
　　　通常情况下如果要在EAS portal中集成第三方应用系统应采用第三方应用系统的单点登录集成方式，如果第三方应用没有单点登录集成方式，则也可以通过进行二次开发来采用EAS的LTPA认证方案，其实现步骤如下：
　　　第三方系统需要做的开发工作：
　　　(1) 将3.3.1 所述LtpaToken.properties文件拷贝到第三方系统的任意目录中；
　　　(2) 开发出支持传入用户名和LTPA Token加密串，校验通过后即可登录到第三方系统中的接口；
　　　(3) 在该接口中调用LtpaTokenManager的verifyToken接口进行Token加密串合法性的校验
　　　EAS系统需要做的开发工作：
　　　(4) 在登录到portal后，获取到用户账号并且调用LtpaTokenManager的generate方法生成Token加密串，然后调用第三方系统开发的接口登录到第三方系统中。

3.5 用户集成组件
　　　用户集成组件，主要解决EAS系统和其他各应用系统间用户信息的差异问题。可以使其他各应用系统的用户能够与EAS系统中的用户相对应，从而顺利单点登录到EAS系统中。
　　　EAS系统同第三方应用系统的单点登录集成过程中，在配置和实现了一个具体的单点登录认证方案后，需要将第三方应用系统或者域服务器上的用户信息集成到EAS系统中，这样才能实现使用一个统一的用户访问单点登录集成的各个应用系统。

3.5.1 用户数据导入
　　　用户数据导入可以实现将外部系统或服务器的用户信息集成到EAS系统中，是用户集成的第一步工作。
　　　通过EAS系统中的【系统平台】－>【外部数据管理】－>【外部用户管理】－>【用户数据导入】菜单可以打开用户数据导入的功能界面，如图3.1所示。

图3.1  用户数据导入功能界面

3.5.1.1 EAS 5.9.0–EAS 7.0.0用户数据导入功能及参数说明
　　　打开用户数据导入的功能界面后点击“新建”按钮，新增一条外部用户数据导入数据源，该数据源的配置界面如图3.2所示：

图3.2  用户导入数据源配置界面
该界面参数说明：
(1) 用户数据源：为数据源的名称，可以是任意一个字符串
(2) 资源连接类型：该参数表明数据源的类型，由于通常情况下企业业务系统存储用户信息一般采用LDAP服务器或者数据库数据表两种方式，所以该参数有两个选项：一个是LDAP服务器 (注：微软AD域服务器是LDAP服务器的一种)，另一个是数据库 (注：该功能已废弃，由EAI平台来完成)。
(3) 资源项连接地址：为LDAP服务器的ip地址
(4) 端口：为LDAP服务器的端口号，通常情况下缺省是389
(5) 资源专有名称DN：该参数通过后面的“获取BaseDN”按钮获得域中的namingContext (命名空间)
(6) 资源项登录用户名：为LDAP服务器中已定义的一个用户名
(7) 资源项登录密码：资源项登录用户名的登录密码
(8) 用户表用户名：LDAP服务器中代表EAS系统中用户登录账号的条目名称
(9) 用户表用户姓名：LDAP服务器中代表EAS系统中用户实名的条目名称
(10) 搜索返回值：该项不能编辑，由用户表用户名和用户表用户姓名自动生成
(11) 数据过滤条件：LDAP服务器中过滤出同步用户的过滤条件
(12) 同步用户初始化密码：使用外部用户登录时的初始密码
(13) 同步实现类：该参数有两个缺省选项，一个是“EAS默认用户同步”，另一个是“同步用户与职员匹配，并设置默认的组织和角色”，通常情况下选择“EAS默认用户同步”进行同步，另外，该参数也支持二次开发扩展的同步实现类。
(14) 引入实现：使用xml文件存储用户信息得引入引出实现类，通常情况下为空值

3.5.1.1 EAS 5.1.3 – EAS 5.4.0用户数据导入功能及参数说明
　　　EAS早期版本的数据源的配置界面如图3.3所示：

图3.3  EAS早期版本用户导入数据源配置界面
该界面参数说明：
(1) 编码：该数据源的编码，可以是任意一个字符串
(2) 用户数据源：同步配置项唯一标识
(3) 资源项连接地址：LDAP服务器地址 (格式：ldap://192.168.16.2:389/ )
(4) 资源项登录用户名：域中任意用户名
(5) 集成清单-编码：分录唯一标识
(6) 集成清单-用户名：EAS系统用户 (将以此用户为用户数据的创建者，即所同步用户数据将以此用户的CU为默认CU)
(7) 集成清单-密码：同步用户的预设密码
(8) 集成清单-用户名后缀：当同步的用户和EAS系统用户出现重名的时 使用同步用户加用户后缀名 录入EAS用户中
(9) 集成清单-Basedn：cn=users (域服务器的用户根目录)，DC为域根
(10) 集成清单-数据过滤条件：查找的为person人员和user用户
(11) 集成清单-目录搜索范围：LDAP目录搜索范围Base、OneLevel、Subtree三种 一般默认为2
(12) BASE表示只查找本条目数据 (即baseDN，值为0)，oneLevel表示只查找baseDN的子条目 (值为1)，Subtree则表示查找包括baseDN在内所有子树数据(值为2)，另外，设置该值时，建议显示和实际存储转换一下，即显示Base/oneLevel/subtree，实际保存为0/1/2，以保持LDAP通常习惯。
(13) 集成清单-目的用户表的用户名：LDAP服务器的用户帐号 title (用户帐号);集成清单-目的用户表的用户姓名：LDAP用户的显示名称 title(用户实名);集成清单-搜索返回属性值：需要返回的属性字段
(14) 集成清单-LDAP源提供的信息类型为简体或者繁体
　　　配置好数据源后即可点击“同步数据”按钮，将外部用户同步到EAS系统中。

3.5.2 用户映射管理
　　　用户映射管理的功能是在外部用户数据导入到EAS系统后，建立外部用户与EAS系统中用户的映射关系，使外部用户可以登录到EAS系统中，该功能是用户集成的第二步工作。
　　　通过EAS系统中的【系统平台】－>【外部数据管理】－>【外部用户管理】－>【用户映射管理】菜单可以打开用户映射管理的功能界面，如图3.4所示。

图3.4  用户映射管理功能界面
　　　该界面有一个“自动映射”的功能，该功能是指系统自动将用户账号相同外部用户和EAS系统用户建立映射关系。

3.5.3 用户集成参数配置
　　　在把外部用户集成到EAS系统中，并且与EAS系统中的用户建立映射关系后，需要修改一些配置参数，即可实现采用 LTPA认证方案使用外部用户登录到EAS系统中。
　　　打开服务器端的server\profiles\server1\config\portalConfig目录下的ssoClient.properties文件，在其中增加以下两个参数：
　　　(1) sso.user.mapping=true
　　　参数说明：是否将外部用户账号同EAS用户账号进行了映射，若想使用外部用户账号进行登录则需要将该参数设置为true，否则设置为false
　　　(2) sso.user.useExternalUser=true
　　　参数说明：是否优先使用外部用户账号登录系统，参数设置为true则优先使用外部用户账号登录系统，参数设置为false则优先使用EAS用户账号登录系统

3.5.4 定义用户数据周期同步后台事务
　　　为了方便外部用户数据周期自动进行同步，也可以通过EAS的后台事务来定义用户数据的周期同步功能，该功能可以做为实现用户集成的可选功能，其定义步骤如下：
　　　(1) 通过EAS系统中的【系统平台】－>【后台事务】－>【后台事务定义】菜单可以打开后台事务定义的功能界面，如图3.5所示。

图3.5  后台事务定义功能界面
　　　(2) 录入事务名称、设置生效、失效时间、以及选择用户同步任务，如图3.6所示。

图3.6  选择用户同步任务界面
　　　(3) 设置资源名称，如：“dbc/mykingdee”或“dap/ad”，即：服务端server\profiles\server1\config\portalConfig目录下userSyncConfig.xml文件中的resource元素name属性值，并且设置事务调度计划，如图3.7所示。

图3.7  设置事务调度计划界面
　　　(4) 保存并发布该后台事务。

3.6 CAS集成组件
　　　由于EAS portal的单点登录对标准的CAS进行扩展，所以EAS portal也支持与其它标准的CAS服务器进行集成，通过其它CAS服务器进行用户认证和校验，其配置步骤如下：

3.6.1 CAS服务器参数配置
　　　打开服务端server\profiles\server1\config\portalConfig\目录下的ssoclient.properties文件，该文件内容如下：
cas.server.renew=false
cas.server.proxyCallbackUrl=
sso.client.serverNameByRequestMap=true
cas.client.proxyCallbackUrl=
sso.client.redirectTo=/index_sso.jsp
sso.client.loginUrl=/ssoWelcome
sso.server.loginUrlByRequestMap=true
cas.server.gateway=false
cas.client.serverName=127.0.0.1:6888
cas.server.url=http://127.0.0.1:6888/eassso/
sso.easIsSSOClient=true

常用参数说明如下：
(1) sso.client.serverNameByRequestMap：SSO client service参数的URL是否动态取自客户端请求URL，包括端口，该参数缺省为true
(2) sso.server.loginUrlByRequestMap：SSO client 和server是否相同主机地址，
若为true，且sso.client.serverNameByRequestMap=true，则主机将动态取自客户端请求URL(但保留静态配置参数的端口和URL)，该参数缺省为true
(3) cas.client.serverName：CAS客户端受保护应用的ip地址和端口号
(4) cas.server.url：CAS服务器URL
(5) sso.easIsSSOClient：EAS portal是否启用CAS单点登录认证，参数缺省为true
(6) sso.client.redirectTo：单点登录认证通过后转向的应用主页(同一个应用SERVER同一个JVM下，只能有一个)，相对路径
(7) sso.client.loginUrl：单点登录认证入口地址，相对路径
(8) cas.server.IsIndependentDeployment：是否采用第三方CAS服务器，该参数缺省没有，如果集成第三方CAS服务器则需要新增该参数
　　　其中，集成第三方CAS服务器需要修改如下参数：
　　　(1) 将cas.server.url参数修改为第三方CAS服务器的地址 (例如：https://localhost:8443/cas/)
　　　(2) 将sso.server.loginUrlByRequestMap参数设置为false
　　　(3) 将sso.easIsSSOClient参数设置为true
　　　(4) 新增cas.server.IsIndependentDeployment参数并将其值设置为true

3.6.2 新增EAS登录所需要参数的配置文件
　　　在服务端server\profiles\server1\config\portalConfig\目录下新建CASLoginConfig.properties文件，其中文件内容如下：
solutionName = eas
dataCenter = eas600_nanche
locale = L2
DBType = 0
userAuthPattern = BaseDB
isPureWeb = true
redirectTo  = null
userDomain  =
loginFlow  = true
sso.user.mapping=false
sso.user.useExternalUser=false
　　　其中，将dataCenter参数修改为EAS登录的数据中心代码：

3.6.3 安装EAS支持第三方CAS服务器的相关补丁
　　　EAS 6.0 及sp1版本需要安装单点登录和Web框架领域相关补丁支持CAS独立部署：
　　　(1) 单点登录领域补丁PT032072
　　　(2) Web框架领域补丁PT032543
　　　或者安装PTM037265补丁。
　　　EAS 7.0 sp1及以后版本则缺省包含该补丁内容
　　　
　　　另：如果想了解如何搭建标准的CAS服务器请参考《EAS支持CAS服务器独立部署配置指南》文档。

第四章  EAS其它单点登录集成方案

4.1 EAS portal与WebSphere全局安全性单点登录方案的集成

　　　对于已经应用了WebSphere全局安全性单点登录方案的应用系统，EAS portal也支持集成到WebSphere全局安全性单点登录方案中，其配置步骤如下：
　　　注意：进行该配置前首先要确认已完成以下几点工作：
　　　(1) 配置WebSphere，启用全局安全性和配置单点登录：
　　　(2) 启用LTPA认证
　　　(3) 启用LDAP用户注册表
　　　(4) 各应用系统已经配置了域名

4.1.1 EAS企业应用程序 (eas.ear) 的配置

4.1.1.1 修改application.xml文件
　　　打开EAS服务器端server\deploy\websphere6.0\eas.ear\META-INF目录下的application.xml 文件：
　　　(1) 在<application>节点上加一个id属性：即将<application>改成<application id="Application_ID">
　　　(2) 在<application>节点里面增加一个<security-role>子节点，代码如下：
　　　<security-role id="SecurityRole_1279089752812">
　　　    <description>EAS Security</description>
　　　    <role-name>EAS Security Role</role-name>
　　　  </security-role>

4.1.1.2 新增ibm-application-bnd.xmi文件
　　　在EAS服务器端server\deploy\websphere6.0\eas.ear\META-INF目录下新增一个名字为ibm-application-bnd.xmi的文本文件(注意：后缀名为xmi)，文件内容如下：
<?xml version="1.0" encoding="UTF-8"?>
<applicationbnd:ApplicationBinding xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:applicationbnd="applicationbnd.xmi" xmi:id="ApplicationBinding_1162891364227">
  <authorizationTable xmi:id="AuthorizationTable_1162891364227">
    <authorizations xmi:id="RoleAssignment_1279089752812">
      <specialSubjects xmi:type="applicationbnd:AllAuthenticatedUsers" xmi:id="AllAuthenticatedUsers_1279089752812" name="AllAuthenticatedUsers"/>
      <role href="META-INF/application.xml#SecurityRole_1279089752812"/>
    </authorizations>
  </authorizationTable>
  <application href="META-INF/application.xml#Application_ID"/>
</applicationbnd:ApplicationBinding>

4.1.2 EAS Portal Web应用程序 (cp_web.war) 的配置

4.1.2.1 修改web.xml文件
　　　打开EAS服务器端server\deploy\eas.ear\cp_web.war\WEB-INF目录下的web.xml 文件：
　　　(1) 在<web-app>节点上加一个id属性：即将<web-app …>改成<web-app id="WebApp_ID" …>
　　　(2) 在<web-app>节点里面增加<security-constraint>、<login-config>以及<security-role>子节点，代码如下：
　　　<security-constraint>
　　　      <display-name>EAS Security Constraint</display-name>
　　　      <web-resource-collection>
　　　         <web-resource-name>Protected Area</web-resource-name>
　　　  <!-- Define the context-relative URL(s) to be protected -->
　　　  <url-pattern>*.jsp</url-pattern>
　　　  <url-pattern>/</url-pattern>
　　　  <!-- If you list http methods, only those methods are protected -->
　　　  <http-method>GET</http-method>
　　　  <http-method>POST</http-method>
　　　      </web-resource-collection>
　　　      <auth-constraint>
　　　         <!-- Anyone with one of the listed roles may access this area -->
　　　         <role-name>EAS Security Role</role-name>
　　　      </auth-constraint>
　　　      <user-data-constraint>
　　　   <transport-guarantee>NONE</transport-guarantee>
　　　    </user-data-constraint>
　　　</security-constraint>
　　　
　　　<!-- Default login configuration uses form-based authentication -->
　　　<login-config>
　　　 <auth-method>FORM</auth-method>
　　　 <realm-name>EAS Authentication Area</realm-name>
　　　 <form-login-config>
　　　  <form-login-page>/security/securityLogin.jsp</form-login-page>
　　　  <form-error-page>/security/securityLogin.jsp</form-error-page>
　　　 </form-login-config>
　　　</login-config>
　　　
　　　<!-- Security roles referenced by this web application -->
　　　
　　　<security-role>
　　　         <description>EAS Security</description>
　　　         <role-name>EAS Security Role</role-name>
　　　</security-role>
　　　
　　　其中<login-config>节点中的<form-login-page>和<form-error-page>节点中的值分别代表基于WAS安全性的登录页面以及登录失败的跳转页面的访问路径，这两个页面的开发请参考4.1.13节内容

4.1.2.2 新增ibm-web-bnd.xmi和ibm-web-ext.xmi文件
　　　在EAS服务器端server\deploy\eas.ear\cp_web.war\WEB-INF目录下新增ibm-web-bnd.xmi和ibm-web-ext.xmi文件，文件内容分别如下：
　　　(1) ibm-web-bnd.xmi：
　　　<?xml version="1.0" encoding="UTF-8"?>
　　　<webappbnd:WebAppBinding xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:webappbnd="webappbnd.xmi" xmi:id="WebAppBinding_1160540582396" virtualHostName="default_host">
　　　  <webapp href="WEB-INF/web.xml#WebApp_ID"/>
　　　</webappbnd:WebAppBinding>
　　　(2) ibm-web-ext.xmi：
　　　<?xml version="1.0" encoding="UTF-8"?>
　　　<webappext:WebAppExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:webappext="webappext.xmi" xmi:id="WebAppExtension_1160540582396" reloadInterval="3" reloadingEnabled="true" fileServingEnabled="true">
　　　  <webApp href="WEB-INF/web.xml#WebApp_ID"/>
　　　</webappext:WebAppExtension>

4.1.3 基于FORM认证登录页面的开发

4.1.3.1 开发登录页面
　　　在服务器端server\deploy\eas.ear\cp_web.war的任意目录下目录下新增一个jsp文件 (此例中为：server\deploy\eas.ear\cp_web.war\security\securityLogin.jsp) 。也可以改造系统已有的登录页面。
　　　在该文件中定义登录页面需要遵循以下几点规范：
(1) 登录页面Form表单的action定义为j_security_check，例如：
　　　<form method="POST" action="j_security_check" >
(2) 登录页面Form表单中输入用户名的文本框的name定义为j_username，例如：
　　　<input type="text" name="j_username">
(3) 登录页面Form表单中输入密码的文本框的name定义为j_password，例如：
　　　<input type="password" name="j_password">
　　　注意：该登录页面定义好后需要将访问路径(此例中为： security\securityLogin.jsp) 配置到web.xml的<login-config>中的<form-login-page> 节点中。
　　　另外，也可以定义一个登录出错的跳转页面然后配置到<form-error-page>节点中，通过request.getParameter("msg") 来获取登录失败的信息。
　　　
示例代码如下：
<%@ page contentType="text/html;charset=UTF-8" %>
<html>
<head>
<title>EAS Login Page</title>
<body bgcolor="white">
<form method="POST" action="j_security_check" >
  <table border="0" cellspacing="5">
    <tr>
      <th align="right">用户名：</th>
      <td align="left"><input type="text" name="j_username"></td>
    </tr>
    <tr>
      <th align="right">密&nbsp; 码：</th>
      <td align="left"><input type="password" name="j_password"></td>
    </tr>
    <tr>
      <td align="right"><input type="submit" value="Log In"></td>
      <td align="left"><input type="reset"></td>
    </tr>
  </table>
</form>
</body>
</html>
<%
 String msg = request.getParameter("msg");
 if (msg == null) {
  msg =
　　　　try{
  out.write("<script>alert(\""+msg+"\")</script>");
  }catch(Exception ex){
   System.out.println("login.jsp err: "+ex);
  }
 }
%>

4.1.3.2 开发EAS单点登录跳转页面
　　　(1) 在登录认证成功后需要开发一个另外一个跳转页面，在此页面中获取登录用户名，并且采用LTPA Token的方式登录到EAS的Portal中，此例中该页面在server\deploy\eas.ear\cp_web.war\目录下的loginByToken.jsp。
　　　示例代码如下：
<%@ page contentType="text/html;charset=UTF-8" %>
<%@ page import="com.kingdee.eas.cp.eip.sso.ltpa.LtpaTokenManager,com.kingdee.eas.cp.eip.sso.ltpa.LtpaToken"%>
<%@ page import = "java.net.URLEncoder" %>
<%
     String username =  request.getRemoteUser() ;
     System.out.println(username);
     String password = LtpaTokenManager.generate(username,LtpaTokenManager.getDefaultLtpaConfig()).toString();
     username = URLEncoder.encode(username,"UTF-8");
     password = URLEncoder.encode(password,"UTF-8");
     response.sendRedirect("/easportal/index2sso.jsp?username="+username+"&password="+password);
 %>
　　　(2) 修改server\deploy\eas.ear\cp_web.war\WEB-INF目录下的web.xml 文件，在<welcome-file-list>节点中将认证成功后跳转页面指定成该页面，配置代码如下：
　　<welcome-file-list>
  <welcome-file>loginByToken.jsp</welcome-file>
 </welcome-file-list>
　　　(3) 修改server\profiles\server1\config\portalConfig目录下的autoLoginConfig.properties文件中的参数支持LTPA Token方式的登录：
　　　(a) 将datacenter参数项的值修改为登录的数据中心代码
　　　(b) 将authPattern参数项的值修改为BaseTrdLtpaToke

4.1.4 使用管理控制台部署EAS
　　　首先，需要打管理控制台补丁PT035624，使管理控制台支持启用了全局安全性的WAS的部署。
　　　然后，在部署EAS应用时选择“应用服务器启用了安全性”选项，并输入登录WAS管理控制台的用户名和密码，如下图所示：

　　　最后，在EAS应用部署完成后输入portal地址测试，弹出如下登录页面：

　　　在输入WAS安全性设置的认证用户和密码后如果能登录到EAS的portal中，则说明已经实现了EAS支持WAS全局安全性方式的单点登录集成。

4.2 基于IBM JDK的EAS集成微软AD域认证的方案

　　　由于Sun JDK 和IBM JDK对于Krb5LoginModule类的实现完全不同，所以EAS 的微软AD域认证处理器只支持Sun JDK而不支持IBM JDK，如果EAS服务器环境中使用IBM JDK则需要采用AD域认证服务器和EAS服务器独立部署的方式来解决使用IBM JDK的EAS中集成微软AD域认证的问题。

4.2.1 AD认证服务器和EAS服务器独立部署方案介绍
　　　该方案需要部署两台服务器，一台服务器做为EAS运行的服务器，该服务器安装和部署EAS服务器端，并且使用IBM JDK，另一台服务器做为AD域认证服务器，该服务器要求使用windows系列的操作系统，同样安装和部署EAS服务器端，并且使用Sun JDK (注意：该服务器只用来做AD域认证，所以对机器硬件要求不高) ，然后，通过一些配置，可以做到EAS运行服务器到 AD认证服务器上进行用户认证和校验，从而实现基于IBM JDK的EAS集成微软AD域认证的单点登录集成方案，该方案的具体实现步骤如下。

4.2.2 搭建和配置AD域认证服务器
　　　在一台使用windows系列操作系统的机器上安装和部署EAS服务器端，并且该EAS服务器使用Sun JDK做为虚拟机环境，然后按照3.3节所述配置方法将该服务器集成微软AD域认证。
　　　
4.2.3 搭建和配置EAS服务器
　　　在另一台机器上安装和部署EAS服务器端，并且该EAS服务器使用IBM JDK做为虚拟机环境，该服务器做为运行EAS的服务器。
　　　打开EAS服务器端server\profiles\server1\config\portalConfig\目录下的ssoclient.properties文件：
　　　(1) 将cas.server.url参数修改为http://<AD域认证服务器的ip和端口>/eassso/
　　　(2) 将cas.client.serverName参数修改为EAS运行服务器的ip和端口
　　　(3) 将sso.server.loginUrlByRequestMap参数修改为false
　　　重新启动EAS运行服务器，进行测试。

第五章  单点登录的相关知识介绍

5.1 域相关概念和术语介绍

5.1.1 目录
　　　目录是按分层结构排列（树结构）的关于对象的信息集合。它是一个专门的数据库，使用户或应用程序可以查找有特定任务所需特征的资源。
　　　如果对象的名称已知，就可检索它的特征。如果特定个别对象的名称未知，可以搜索目录找到符合某一要求的对象列表。通常可以按特定标准搜索目录，而不仅仅按预定义的一组类别。
　　　目录是一个专门的数据库，但有着使其有别于通用关系数据库的特征。目录的特征之一是它受访问（读取或搜索）的次数要比更新（写入）次数多得多。因为目录必须能支持大量读取请求，所以它们通常为读访问作了优化。因为目录不打算提供与通用数据库一样多的功能，所以可优化它们以在大型分布式环境中向目录数据经济地提供更多应用程序与快速访问。
　　　目录可以是集中式或分布式的。如果目录是集中式的，则在一个位置有一个目录服务器（或服务器群集）提供对目录的访问。如果目录是分布式的，则有多于一个且通常分布于不同地理位置的服务器提供对目录的访问。
　　　当目录是分布式的，则可对目录中存储的信息进行分区或复制。
　　　当信息分区后，每个目录服务器都存储一个唯一的且非重叠的信息子集，也就是说，每个目录条目都由一台也仅由一台服务器存储。分区对目录客户端是透明的，目录客户端是通过LDAP 参照来访问各分区数据的，LDAP参照允许用户将LDAP请求指引到不同的（或相同的）服务器中存储的相同或不同名称空间。
　　　当复制信息时，多台服务器存储同一个目录条目。
　　　在分布式目录中，也可以混合使用这种技术，有些信息可以分区，有些信息可以复制。
　　　
　　　目录对于存储这样的信息最为有用：也就是数据需要从不同的地点读取，但是不需要经常更新。例如，这些信息存储在目录中是十分有效的：
(1) 公司员工的电话号码簿和组织结构图
(2) 客户的联系信息
(3) 计算机管理需要的信息，包括NIS映射、email假名，等等
(4) 软件包的配置信息
(5) 公用证书和安全密匙
　　　大多数人熟悉各种各样的目录，像电话簿、黄页，电视指南、购物目录和图书馆卡片目录。我们把这一类目录归为日常目录。在计算机中的目录被称为在线目录。

 

 

5.1.2 目录服务
　　　目录服务是软件、硬件、策论以及管理的集合体。目录服务至少包括以下几个方面：
　　　(1) 包含在目录中的信息
　　　(2) 保存信息的软件服务端
　　　(3) 扮演存取信息的软件客户端
　　　(4) 运行服务端，客户端软件的硬件
　　　(5) 支撑系统，像操作系统、设备驱动等
　　　(6) 连接客户端到服务端以及各个服务端之间的网络基础设施
　　　(7) 策略。规定谁能访问，谁能更新，谁能存取等
　　　(8) 维护和监视目录服务的软件
　　　术语目录和目录服务经常被等同、换用。

5.1.3 专有名称（DN）
　　　目录中的每个条目都有一个专有名称（distinguished name）。
　　　DN是在目录中唯一地标识条目的名称。
　　　DN由“属性=值”对组成，各对之间以逗号分隔，例如：
　　　cn=wangwu,ou=eas,cn=orgs,o=kingdee,c=cn
　　　cn=lishi,ou=k3,cn=orgs,o=kingdee,c=cn
　　　目录模式中定义的任何属性都可用于组成 DN。
　　　组件属性值对的顺序很重要。从目录层次结构的根向下到条目驻留的级别，每个级别都有一个对应的组件包含在 DN 中。LDAP DN 以最特定的属性（通常是某种名称）开头，继之以越来越广泛的属性，通常以国家或地区属性结束。DN 的第一个组件称作相对专有名称（RDN）。它使某一条目明确地区别于有相同父代的其它条目。在上例中，RDN“cn= wangwu”使第一个条目有别于第二个条目（带有 RDN“cn=lishi）。否则，这两个示例 DN 就是等价的。组成条目 RDN 的“属性:值”对也必须存在于条目中。（DN 的其它组件则并非如此，如：后缀）

5.1.4 DN 转义规则
　　　DN 可包含特殊字符。这些字符为 ,（逗号）、=（等于号）、+（加号）、<（小于号）、>（大于号）、#（数字标记）、;（分号）、\（反斜杠）和 『』（引号）。
　　　要在 DN 字符串的属性值中转义这些特殊字符或其它字符，请使用以下任意方法：
　　　(1) 如果要转义的字符是特殊字符之一，可以在它前面加反斜杠（“\”ASCII 92）。此示例显示了在组织名称中转义逗号的方法：
　　　 CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
　　　这是首选方法。
　　　(2) 否则就用一个反斜杠和两个十六进制数字（它们在字符代码中构成单个字节）替换要转义的字符。字符的代码必须在 UTF-8 代码集中。
　　　 CN=L. Eagle,O=Sue\2C Grabbit and Runn,C=GB
　　　(3) 整个属性值用 ""（引号）（ASCII 34）括住，引号不是值的一部分。在前后引号中间，除了 \（反斜杠）之外，所有字符都照原样处理。在方法 2 中 \（反斜杠）可用于转义反斜杠（ASCII 92）或引号（ASCII 34）、前面提到的任何特殊字符或十六进制对。例如，要转义 cn=xyz"qrs"abc 中的引号，它可成为 cn=xyz\"qrs\"abc 或转义 \：
　　　 "you need to escape a single backslash this way \\"
　　　另一个示例，"\Zoo" 是非法的，因为在此上下文中无法转义“Z”。
　　　在服务器端上，当接收到此格式的 DN 时，服务器使用转义机制 1 号和 2 号重新格式化 DN 以进行内部处理。

5.1.5 增强的 DN 处理
　　　DN 的组合 RDN 可能包含多个由“+”运算符连接的组件。对于具有此类 DN 的条目，服务器增强了在其上执行搜索的支持。可以按任何顺序指定组合 RDN 作为搜索操作的基础。
　　　ldapsearch cn=mike+ou=austin,o=ibm,c=us
　　　服务器接受 DN 标准化扩展操作。DN 标准化扩展操作使用服务器模式来使 DN 标准化。此扩展操作对于使用 DN 的应用程序可能非常有用。有关更多信息，请参阅 IBM Tivoli Directory Server Version 5.2 C-client Programming Reference。

5.1.6 后缀(Suffix)
　　　后缀是在本地保留的目录层次结构中标识顶部条目的 DN。也被称为命名上下文（naming context）
　　　因为 LDAP 中使用的相对命名方案的缘故，此 DN 也是该目录层次结构中每个其它条目的后缀。一个目录服务器可以有多个后缀，每个后缀标识一个本地保留的目录层次结构，例如 o=ibm,c=us。
　　　要添加到目录中的条目必须有与 DN 值匹配的后缀，如“ou=Marketing,o=ibm,c=us”。如果查询包含的后缀不匹配为本地数据库配置的任何后缀，则查询会被指引到缺省参照标识的 LDAP 服务器。如果没有指定 LDAP 缺省参照，则所返回的结果指示对象不存在。

5.1.7参照(Referrals)
　　　参照为服务器提供将客户机指引到附加目录服务器的方法。参照指定备用 LDAP 服务器的 URL。此备用服务器处理对在当前 LDAP 服务器的子树中未找到的任何对象的请求。通过参照，您可以：
　　　(1) 台服务器中分发名称空间信息
　　　(2) 提供在一组相关服务器中数据所在位置的信息
　　　(3) 将客户机请求路由到相应的服务器
　　　使用参照的一些优点是有能力：
　　　(1) 分布处理开销，从而提供基本的负载平衡
　　　(2) 将数据管理分布到整个组织范围内
　　　(3) 提供超出组织自身范围的更广泛的互连潜力

5.1.8 模式(Schema)
　　　模式是控制数据能够存储在目录中的方式的一组规则。模式定义允许的条目类型、它们的属性结构和属性的语法。

5.1.9 对象类(objectClass)
　　　

　　　对象类指定用于描述对象的一组属性。例如，如果您创建对象类 tempEmployee，则它可能包含与临时雇员关联的属性，如 idNumber、dateOfHire 或 assignmentLength。您可以添加定制对象类以适合您的机构的需求。IBM Tivoli Directory Server 模式提供某些基本类型的对象类，包括：
　　　(1) 组
　　　(2) 位置
　　　(3) 组织
　　　(4) 人员

5.1.9.1 对象类类型
　　　对象类可以是下列三种类型之一：
　　　(1) 结构(Structural)：
　　　每个条目都必须属于且只能属于一个结构对象类，这就定义了条目的基本内容。此对象类表示一个实际的对象。由于所有条目都必须属于结构对象类，所以这是最常用的对象类类型。
　　　(2) 抽象(abstract)：
　　　此类型用作其它（结构）对象类的超类或模板。它定义一组结构对象类共有的一组属性。这些对象类（如果定义为抽象类的子类的话）继承已定义属性。不需要对每个下级对象类定义这些属性。
　　　(3) 辅助(Auxiliary)：
　　　此类型指示可与属于特定结构对象类的条目相关联的附加属性。虽然一个条目只能属于一个结构对象类，但它可以属于多个辅助对象类。

5.1.9.2 对象类继承
　　　IBM Tivoli Directory Server 5.2+支持对对象类和属性定义的对象继承。新的对象类可以用父类（多重继承）以及附加或更改的属性进行定义。
　　　每个条目指定给一个结构对象类。所有对象类都继承自抽象对象类顶层（top）。它们还可以继承自其它对象类。对象类结构确定特定条目的必需的和允许的属性列表。对象类继承取决于一系列对象类定义。对象类只能继承在它之前的对象类。例如，在 LDIF 文件中，人员（person）条目的对象类结构可能定义为：
　　　objectClass: top
　　　objectClass: person
　　　objectClass: organizationalPerson
　　　在此结构中，organizationalPerson 继承自人员（person）和顶层（top）对象类，而人员（person）对象类仅继承自顶层（top）对象类。因此，当您将 organizationalPerson 对象类指定给条目时，它自动继承上级对象类的必需的和允许的属性。在本例中为人员（person）对象类。
　　　在处理和提交之前，将根据模式类层次结构来检查模式更新操作，以确保一致性。

5.1.9.3 属性
　　　每个对象类都包括一组必需的属性和可选的属性。必需的属性是必须存在于使用该对象类的条目中的属性。可选属性是可能存在于使用该对象类的条目中的属性。

 

第六章  FAQ

6.1 独立部署后web框架需要重新登录问题

　　　问题描述：使用独立部署CAS服务器后在打开portal后不能直接打开web框架的页面(例如：协同平台)，而跳转到CAS登录页面，需要重新进行登录
　　　解决方法：(1) 配置CAS服务器支持https的访问，
　　　(2) 修改CAS服务器端配置文件，在cas server的cas-servlet.xml里加入以下配置代码：
　　　<bean id="ticketGrantingTicketCookieGenerator"
　　　class="org.jasig.cas.web.support.CookieRetrievingCookieGenerator">
　　　  <property name="cookieSecure" value="false" />
　　　  <property name="cookieMaxAge" value="-1" />
　　　  <property name="cookieName" value="CASTGC" />
　　　  <property name="cookiePath" value="/cas" />
　　　</bean>

6.2 微软AD域用户无法同步用户数据问题

　　　问题描述：微软AD域用户导入EAS时在LDAP同步配置界面能够正常连接域服务器并且选择导入用户，但保存后点“同步数据”后同步用户为0
　　　解决方法：LDAP同步配置界面中“搜索返回值”一项的值必须为“displayName,sAMAccountName”才能同步成功。

 

术  语

EAS：企业应用套件 (Enterprise Application Suite)
SSO：单点登录 (Single Sign On)
LDAP：轻量目录访问协议 (Lightweight Directory Access Protocol )
AD：活动目录 ( Active Directory )
LTPA：轻量级第三方认证 ( Lightweight Third Party Authentication )
CAS：中央认证服务 ( Central Authentication Service )
JAAS：JAVA认证和授权服务 ( Java Authentication and Authorization Service)

 

附  录

附录1：JAAS
　　　JAAS：JAAS全名是JAVA认证和授权服务(Java Authentication and Authorization Service)，它是一组java包，为提供基于用户的认证和访问控制提供支持，它是标准可嵌入式认证模型(PAM)的java版本实现，支持基于用户的身份认证。
　　　JAAS是J2SE1.3中的可选包，但是J2SE1.4中已经集成了JAAS.
　　　JAAS的具体规范可以到http://java.sun.com/products/jaas/查看。

附录2：Kerberos
　　　Kerberos是麻省理工学院 (MIT) 所开发的网络鉴别协议，是用于网络安全的一个事实上的工业标准，曾经受到美国出口管制。而Heimdal Kerberos 是另一种KerberosV5实现， 并且明确地在美国之外的地区开发，以避免出口管制。
　　　Kerberos 是网络验证协议名字，同时也是用以表达实现了它的程序的形容词。例如 Kerberos telnet。目前最新的协议版本是V5，在 RFC 1510 中有所描述。
　　　Kerberos 是一种基于称为Tickets的认证协议，通过密钥加密技术，为client/Server应用提供强认证。Kerberos tickets是鉴别ID的一种凭证，有两种类型的tickets : ticket-granting ticket (TGT) and service ticket (ST)。当你登录一个受控系统的时候你需要密码或token来验证你的身份，若验证通过，将获得TGT。通过TGT你能向认证服务器请求ST，以便访问特定的服务。通过这两种tickets的方法被叫作kerberos的可信任的third-party或中介物，该中介物被称为KDC(Key Distribution Center密钥分发中心)，该中心负责分发所有的Kerberos tickets到客户端。
　　　Kerberos 数据库记录了每个用户凭证的信息，包括名字、私有密钥、有效期等等。主KDC存有Kderberos数据库的主拷贝，并负责把它分发给各从KDCs。
　　　JAAS已实现了Kerberos Login Module。
　　参考资源：http://web.mit.edu/Kerberos/www

附录3：LTPA
　　　LTPA：轻量级第三方认证(Lightweight Third Party Authentication)，IBM的产品广泛采用的认证方案。LTPA机制运用一个LTPA令牌(TOKEN)，这个令牌包含了用户信息、网络域和要求用户重新认证的令牌终结时间。Domino服务器作必要配置即可支持LTPA TOKEN认证方式。