级别: 初级 王 宇 (wangyyu@cn.ibm.com), 高级软件工程师, IBM 申 毅 (shenyyi@cn.ibm.com), 软件工程师, IBM
2009 年 2 月 19 日 本文将向您介绍如何在不同的场景下,为 WebSphere Portal V6.1 配置不同的用户注册表(联合用户注册表,单个孤立的注册表)以及多用户域和虚拟门户来满足业务需求。
引言
通过给 WebSphere Portal 配置用户注册表,可以防止未经授权的用户访问您的WebSphere Portal Server。在 WebSphere Portal V6.1 中支持多种类型的用户注册表,配置任意一种均可达到防止未授权用户访问的目的。本文将向您介绍在不同的场景下,如何为 WebSphere Portal V6.1 配置不同的用户注册表(联合用户注册表,单个孤立的注册表)来满足此需求。
我们知道,WebSphere Application Server V6.1 引入了联合用户注册表功能,能够将多个存储库中的用户映射到一个虚拟存储库中,这使得我们对存储库的管理更为灵活。而基于它之上的 WebSphere Portal Server V6.1 也因此获得了同样的功能并做了相应的扩展。让我们先来看一下 WebSphere Portal Server 所支持的注册表类型发生了什么变化吧(表 1)。 表 1 WebSphere Portal Server 所支持的注册表
|
注册表类型
|
6.1版之前
|
6.1版
| |
单个孤立的轻量级目录访问协议 (LDAP) 注册表
|
√
|
√
| |
单个孤立的数据库注册表
|
√
|
--
| |
自定义用户注册表接口的单一实现
|
√
|
√
| |
联合用户注册表(文件存储库)
|
--
|
√
| |
联合用户注册表(LDAP 存储库)
|
--
|
√
| |
联合用户注册表(数据库存储库)
|
--
|
√
|
从表中可以看出,WebSphere Portal Server V6.1 提供了对联合用户组注册表的支持,并且去掉了对单个孤立的数据库注册表的支持。
我们可以从下图 1 中看出 WebSphere Portal Server V6.1 所支持的注册表类型以及如何通过 ConfigEngine 的相应任务在不同的注册表类型之间切换。
 | |
ConfigEngine
在 WebSphere Portal Server V6.1 版中,引入了新的配置框架 (ConfigEngine) 来替换以前的配置命令 (WPSconfig)。ConfigEngine 对 Portal 提供了组件化管理的功能,使其能够对新的组件即插即用,并且由每个组件来管理自己的相关配置任务,由 ConfigEngine 来处理组件之间的依赖关系。在 <wp_profile>/ConfigEngine 目录中可以找到 ConfigEngine 相关命令。我们将在以后的文章中再来详细介绍 ConfigEngine。
|
|
图 1. WebSphere Portal Server V6.1 注册表类型和关系图
从上图可以看出,我们可以通过 ConfigEngine 提供的相应任务(上图中的 A,B,C)来实现
不同的注册表类型之间切换。同时,ConfigEngine 也为联合用户注册表提供了额外的任务来添加多个 LDAP 存储库(wp-create-ldap)和数据库存储库(wp-create-db),我们将在后面的章节中详细介绍这些任务。
联合用户注册表
联合用户注册表是一个通过配置 VMM (虚拟用户管理)来将多个存储库中的用户映射到一个虚拟存储库的方法。联合注册表是一个树型结构,由一个或多个域 (Realm) 组成,每个域由一个或多个基本项 (Base Entry) 组成,每个基本项对应一个独立的存储库 (Repository)。综上所述,联合用户注册表可以看作由一个或者几个域组成的一个虚拟存储库。关于联合用户注册表的详细介绍,请参看参考资料。
图 2. 域/基本项/存储库之间的关系
上图 2 通过实例显示了域、基本项和存储库之间的关系。在实例中,一个域含有三个基本项,分别对应于两个存储库中的三棵子树。
从以上的介绍可以看出,使用了联合用户注册表之后可以同时支持多个存储库,并且允许您根据业务需求来随时添加或删除存储库。而在以前的版本中要完成此功能均需要用户自己来实现自定义的注册表,现在 V6.1 缺省提供的联合用户注册表无疑能大大提高易用性,同时这也是 WebSphere Portal Server V6.1 缺省使用的用户注册表类型。
下面我们来看一下联合用户注册表下的常用功能:
-
查询当前存储库列表
-
添加 LDAP 存储库
-
添加数据库存储库
-
删除存储库
-
设置缺省存储库
查询当前存储库列表
WebSphere Portal Server V6.1 缺省使用的就是联合用户注册表,并且包含一个文件存储库(InternalFileRepository)。需要注意的是,由于它是一个基于本地文件的轻量级存储库,不能将其用于集群环境下,并且一旦删除后只能通过 WebSphere Application Server 的相关命令来将其重新添加回来。
查询当前存储库
ConfigEngine 的任务 wp-qurey-repository 可以用来查询当前为 Portal 配置的所有存储库信息。
[root@pvcent107 ConfigEngine]# ./ConfigEngine.sh wp-query-repository
......
[wplc-query-federated-repository] Existing Federated Repositories
[wplc-query-federated-repository] Repository Name : {Details}
[wplc-query-federated-repository] *******************************
[wplc-query-federated-repository] InternalFileRepository :
{repositoryType=File, host=LocalHost}
[wplc-query-federated-repository] Status = Complete
......
|
从上面可以看出,缺省装完 Portal 后联合用户注册表中将包含一个文件存储库,该存储库 ID 为 "InternalFileRepository" ,类型为"文件",主机为"本地主机"。查询当前存储库列表并不需要额外的参数就可运行。
添加 LDAP 存储库
 | |
wkplc.properties
wkplc.properties 是 ConfigEngine 的主要配置文件,在 <wp_profile>/ConfigEngine/properties/ 中可以找到它。
|
|
下面我们来看一下如何添加一个 LDAP 存储库。此时我们就需要编辑 wkplc.properties 文件来告诉 ConfigEngine 相关的参数。这里 我们仅简单介绍几个重要参数,详细参数列表请参见 WebSphere Portal Server V6.1 信息中心。
wkplc.properties
-
federated.ldap.id=RepositoryID_pvcent49.cn.ibm.com:389
-
federated.ldap.baseDN=dc=ids601,dc=com
-
基本项 (Base Entry) 用来唯一标识并表明将此存储库的一个子树还是全部映射到虚拟存储库里
-
federated.ldap.ldapServerType=IDS6
编辑完成后,可以通过执行 ConfigEngine 的相关任务 wp-create-ldap 来添加 LDAP 存储库。
添加 LDAP 存储库
[root@pvcent107 ConfigEngine]# ./ConfigEngine.sh wp-create-ldap
......
wp-create-ldap:
Wed Apr 30 07:10:36 CST 2008
validate-federated-ldap:
Wed Apr 30 07:10:37 CST 2008
[echo] LDAPHostName federated.ldap.host=pvcent49.cn.ibm.com
[echo] LDAPPort federated.ldap.port=389
[echo] LDAPAdminUId federated.ldap.bindDN=cn=root
......
BUILD SUCCESSFUL
Total time: 31 seconds
[root@pvcent107 ConfigEngine]#
|
值得注意的是,此命令的执行时间只是仅仅31秒,速度上比起以前版本有了极大的提升。现在,再让我们来看一下当前的存储库列表:
查询当前存储库
[root@pvcent107 ConfigEngine]# ./ConfigEngine.sh wp-query-repository
......
[wplc-query-federated-repository] Existing Federated Repositories
[wplc-query-federated-repository] Repository Name : {Details}
[wplc-query-federated-repository] *******************************
[wplc-query-federated-repository] RepositoryID_pvcent49.cn.ibm.com:389 :
{specificRepositoryType=IDS6, repositoryType=LDAP, host=pvcent49.cn.ibm.com}
[wplc-query-federated-repository] InternalFileRepository :
{repositoryType=File, host=LocalHost}
[wplc-query-federated-repository] Status = Complete
......
[root@pvcent107 ConfigEngine]#
|
可见,LDAP 存储库已经添加到联合用户注册表中。借此,我们可以进一步来分析域/基本项/存储库三者是如何在 Portal 的安全配置文件中存储的。它们被存储在 wimocnfig.xml 文件中。该文件包含了 Portal 里有关 VMM 的配置信息,可以在<wp_profile>/config/cells/<cell_name>/wim/config/ 中找到此文件。
wimconfig.xml
<config:repositories xsi:type="config:FileRepositoryType"
adapterClassName="com.ibm.ws.wim.adapter.file.was.FileAdapter"
id="InternalFileRepository" supportPaging="false" messageDigestAlgorithm="SHA-1">
<config:baseEntries name="o=defaultWIMFileBasedRealm"/>
</config:repositories>
......
<config:repositories xsi:type="config:LdapRepositoryType"
adapterClassName="com.ibm.ws.wim.adapter.ldap.LdapAdapter"
id="RepositoryID_pvcent49.cn.ibm.com:389"
ldapServerType="IDS6" translateRDN="false">
<config:baseEntries name="dc=ids601,dc=com" nameInRepository="dc=ids601,dc=com"/>
<config:ldapServers authentication="simple"
bindDN="cn=root" bindPassword="{xor}Lz4sLChvLTs="
connectionPool="true" connectTimeout="0" derefAliases="always"
referal="ignore" sslEnabled="false">
<config:connections host="pvcent49.cn.ibm.com" port="389"/>
</config:ldapServers>
</config:ldapServerConfiguration>
......
</config:repositories>
......
<config:realmConfiguration defaultRealm="defaultWIMFileBasedRealm">
<config:realms delimiter="/" name="defaultWIMFileBasedRealm" securityUse="active">
<config:participatingBaseEntries name="o=defaultWIMFileBasedRealm"/>
<config:participatingBaseEntries name="dc=ids601,dc=com"/>
......
</config:realms>
</config:realmConfiguration>
|
我们这里摘录的片段包括三个部分,前两个以“ <config:repositories ”开头的部分定义了文件存储库和 LDAP 存储库的配置信息,第三个以“ <config:realmConfiguration ”开头的部分定义了域的配置信息。
首先看到的文件存储库的配置信息,值得注意的是它的类型(“ FileRepositoryType ”),存储库 ID(“InternalFileRepository”) 以及基本项(“ o=defaultWIMFileBasedRealm ”)这三个参数。第二部分就是我们刚添加的 LDAP 存储库了,此时需要注意的参数依然是类型 (“LdapRepositoryType”),存储库 ID(“RepositoryID_pvcent49.cn.ibm.com:389”)以及基本项(“ dc=ids601,dc=com ”)。最后的域(Realm)配置信息说明当前缺省域是“ defaultWIMFileBasedRealm ”,此域中包含两个基本项(“ o=defaultWIMFileBasedRealm ”以及“ dc=ids601,dc=com ”),分别对应上面所提到的两个存储库。我们可以通过图2来重新回顾一下三者之间的关系。
添加数据库存储库
添加数据库存储库的步骤和添加 LDAP 存储库的过程基本一致,我们可以把 JDBC 可访问的数据库也添加到联合用户表中,同样需要编辑 wkplc.properties 并填写相应参数,然后通过执行 ConfigEngine.sh wp-create-db 来完成此配置。这里就不展开介绍了。
删除存储库
当我们不再需要某一个存储库时,我们可以在任意时刻将它删除,此时所说的删除其实包括两个步骤。第一步是将此存储库在域中所对应的基本项从域中移除,第二步是将存储库彻底删除。其实从我们上面所分析的 wimconfig.xml 文件来看,第一步就是修改域配置信息,移除其相应包含的基本项,第二步是删除存 储库的配置信息。在 WebSphere Portal Server V6.1 中提供了一个任务 (wp-delete-repository) 来一次性完成这两个步骤。此任务包括两个配置参数:
wkplc.properties
-
federated.delete.baseentry=o=defaultWIMFileBasedRealm
-
federated.delete.id=InternalFileRepository
值得注意的是,如果此存储库包含当前正在使用的管理员 ID,用户需要将 Portal 管理员 ID 更改为其他存储库中的用户,然后才能删除此存储库。另外,如果此存储库同时被包含在其他域中,用户需要先将其基本项从其他域中移除之后再来删除。如何从其他域中删除基本项请参看“多用户域以及虚拟门户”。
设置缺省存储库
当联合用户注册表中包含多个存储库时,新创建的用户会保存在哪一个存储库中呢?如何更改缺省的存储库呢?其实这一切都可以通过分析 wimconfig.xml 来得到答案。
wimconfig.xml
<config:supportedEntityTypes defaultParent="o=defaultWIMFileBasedRealm"
name="Group">
<config:rdnProperties>cn</config:rdnProperties>
</config:supportedEntityTypes>
……
<config:supportedEntityTypes defaultParent="o=defaultWIMFileBasedRealm"
name="PersonAccount">
<config:rdnProperties>uid</config:rdnProperties>
</config:supportedEntityTypes>
|
可以看出缺省的新用户和组都会保存在 o=defaultWIMFileBasedRealm 这个基本项中,也就是缺省的文件存储库。我们可以通过运行 ConfigEngine 的任务 (wp-update-entitytypes) 来完成对缺省存储库的配置。例如:
wkplc.properties
-
personAccountParent=cn=users,dc=ids601,dc=com
-
groupParent=cn=groups,dc=ids601,dc=com
运行完任务之后我们通过 Portal 所创建的新用户就会保存在 LDAP 存储库里,而不是以前的文件存储库了,用户 ID 也会自动添加上“ cn=users,dc=ids601,dc=com ”的后缀。新创建的组也是一样的道理。运行完毕后,新的 wimconfig.xml 文件相关内容如下所示。
运行 wp-update-entitytypes 之后的 wimconfig.xml
<config:supportedEntityTypes defaultParent="cn=groups,dc=ids601,dc=com"
name="Group">
<config:rdnProperties>cn</config:rdnProperties>
</config:supportedEntityTypes>
......
<config:supportedEntityTypes defaultParent="cn=users,dc=ids601,dc=com"
name="PersonAccount">
<config:rdnProperties>uid</config:rdnProperties>
</config:supportedEntityTypes>
|
联合用户注册表的局限性
-
DN(Distinguished Name) 在同一个域的所有存储库中必须唯一。例如,如果在 LDAP1 存储库中包括 uid=wpsadmin,o=youco ,那么在其它存储库中不能再包括这一用户。
-
短名(例如: wpsadmin )也必须在同一个域的所有存储库中唯一。
-
在同一个域的所有存储库所对应的基本项中不能出现重叠。例如,如果 LDAP1 存储库的基本项为 c=us,o=youco ,那么 LDAP2 存储库的基本项不能为 o=youco
-
由于 VMM 的限制,如果联合注册表中的任一存储库停止运行,用户将不能进行身份验证,即使此用户存储在别的此时工作正常的存储库也不行。
单个孤立的注册表
在 WebSphere Portal Server V6.1 中,单个孤立的注册表并不被推荐使用。如果您的系统当中存有大量的历史遗留应用仅支持单个孤立的注册表,或者考虑到与其他系统集成因素在内,可以选择使用此用户注册表。
在单个孤立注册表与联合用户注册表之间切换
我们注意到,在 WebSphere Application Server V6.1 中,我们可以随时配置联合用户注册表或单个孤立注册表,并在需要的时候再将其设为当前选择。也就是说,在 WebSphere Application Server V6.1 里,这两部分的配置信息是独立共存的,互不干扰。但是在 WebSphere Portal Server V6.1 中并不是这样。原因在于 Portal 无论底层采用的是单个孤立注册表还是联合用户注册表都采取了用 VMM 直接读取,这样在单个孤立注册表时就必须也同时把它当作联合用户注册表来对待,同样在 wimconfig.xml 中创建了域/基本项/存储库,只不过此时域中就只包括唯一的存储库了。
需要注意的是,当用户从联合用户注册表切换到单个孤立注册表时,会先删除此时所有的基本项/存储库,然后再为单个孤立注册表创建 基本项及存储库,也就是说无法像 WebSphere Application Server 那样保持各自的配置信息独立共存,互不干扰。同理,当用户从单个孤立注册表切换到联合用户注册表时,就只会简单得更改一下域名称,而将原来的单个孤立注册表直接作为联合用户注册表中的一个存储库,无需再重新添加。
单个孤立的轻量级目录访问协议 (LDAP) 注册表。
让我们来看一下从联合用户注册表切换到单个孤立的轻量级目录访问协议 (LDAP) 注册表的过程。在我们当前的环境中,联合用户注册表现在包括了两个存储库,分别是文件存储库和已经新添加的 LDAP 存储库(LDAP 位于 pvcent49 的主机上)现在需要切换到单个孤立的 LDAP 注册表上(LDAP 位于 pvcent76 的主机上)。首先依然是修改 wkplc.properties 文件,其中需要特别注意的是如下几个参数:
wkplc.properties
-
standalone.ldap.realm = Realm_pvcent76.cn.ibm.com:389
-
standalone.ldap.id = RepositoryID_pvcent76.cn.ibm.com:389
-
standalone.ldap.baseDN = dc=ids5201,dc=com
从联合用户注册表切换到单个孤立注册表 (LDAP)
[root@pvcent107 ConfigEngine]# ./ConfigEngine.sh wp-modify-ldap-security
......
[wplc-create-realm] Realm Realm_pvcent76.cn.ibm.com:389 was created successfully.
......
[wplc-cleanup-repositories] Deleteing realm defaultWIMFileBasedRealm
[wplc-cleanup-repositories] Deleteing repository RepositoryID_pvcent49.cn.ibm.com:389
[wplc-cleanup-repositories] Repository
[wplc-cleanup-repositories] Deleteing repository InternalFileRepository
[wplc-cleanup-repositories] Status = Complete
......
wp-create-wimconfig-ldap:
[wplc-create-federated-ldap-repository]
id="RepositoryID_pvcent76.cn.ibm.com:389"
[wplc-create-federated-ldap-repository] Status = Complete
......
wp-create-base-entry:
[echo] id = RepositoryID_pvcent76.cn.ibm.com:389
[echo] baseDN = dc=ids5201,dc=com
[echo] nameInRepository = dc=ids5201,dc=com
......
BUILD SUCCESSFUL
Total time: 1 minute 36 seconds
[root@pvcent107 ConfigEngine]#
|
可以看到在配置过程中首先创建了新的域,然后依次删除了旧的域以及两个存储库,最后再创建新的 LDAP 存储库以及基本项。
事实上是不能通过检查 wimconfig.xml 来判断当前 Portal 的注册表类型的,我们可以通过检查 security.xml 来得到当前注册表类型。
security.xml
<security:Security xmi:version="2.0"
activeUserRegistry="LDAPUserRegistry_1"
......
<userRegistries xmi:type="security:LDAPUserRegistry" xmi:id="LDAPUserRegistry_1"
......
<hosts xmi:id="EndPoint_1" host="pvcent76.cn.ibm.com" port="389"/>
</userRegistries>
......
<userRegistries xmi:type="security:WIMUserRegistry"
......
registryClassName="com.ibm.ws.wim.registry.WIMUserRegistry"/>
|
在 security.xml 中可以看出,当前选择的用户注册表 ID 是 "LDAPUserRegistry_1",对应的是 LDAP 用户注册表。如果我们在配置了联合用户注册表的时候来查看此文件,就会发现这里的值是 "WIMUserRegistry_1",对应着联合用户注册表了。
多用户域以及虚拟门户
多用户域(multiple realms)和虚拟门户(virtual portal)的概念由来已久,最早出现在WebSphere Portal V5.1 中。在本文中我们就不详细讲解二者概念,只着重介绍 WebSphere Portal V6.1 给我们带来了哪些新的变化。首先,我们先简要给出用户域和虚拟门户在 WebSphere Portal V6.1 中的概念定义。
-
用户域:是将一个或多个用户存储库中的用户进行重新组合形成新的用户群。它是一个逻辑上的概念。
-
虚拟门户:是在一个单独的,公用的 WebSphere Portal 环境里,对门户的资源(包括页面,用户群等等)进行逻辑上的划分。
多用户域和虚拟门户之间的联系可以用下图 3 来表示
图 3. 多用户域和虚拟门户之间的联系

可以看出,从概念和之间关联上,多用户域和虚拟门户在 WebSphere Portal V6.1 中没有什么变化。但是 WebSphere Portal V6.1 通过 ConfigEngine 大大简化了多用户域的配置过程,避免了以前需要对门户安全配置文件的直接修改,大大提高了用户体验。
WebSphere Portal V6.1 的ConfigEngine 提供如下的任务用于配置门户的多用户域支持: 表 1. ConfigEngine 任务列表
|
ConfigEngine 多用户域配置任务
|
作用
| |
wp-create-realm
|
使用指定的基本项创建用户域
| |
wp-add-realm-baseentry
|
将指定的基本项添加到用户域中
| |
wp-delete-realm-baseentry
|
将指定的基本项从用户域中删除
| |
wp-query-realm-baseentry
|
查询用户域中的基本项
| |
wp-default-realm
|
设置缺省用户域 **
|
注意:如果原来的 WebSphere Portal Server 以及 WebSphere Application Server 的管理员帐号不在新的缺省用户域中,则需要调用 wp-change-was-admin-user 和 wp-change-portal- admin-user 来修改两个服务器的管理员帐号。具体请参看 WebSphere Portal V6.1 产品文档。
下面我们通过一个例子来了解如何配置 WebSphere Portal V6.1 的多用户域和虚拟门户支持。在前面的介绍中,我们已经了解了如何配置门户的联合用户注册表。在多用户域和虚拟门户的示例中,我们将利用 WebSphere Portal 中的3个存储库来配置多用户域支持。3 个 LDAP 存储库分别来自两个不同类型的目录服务器 IBM Directory Server 6.0.1 和 Domino 8 LDAP, 具体配置如下:
-
存储库1:
-
federated.ldap.id=Repository1_pvcent64.cn.ibm.com:389
-
federated.ldap.baseDN=o=realm01
-
存储库2:
-
federated.ldap.id=Repository2_pvcent64.cn.ibm.com:389
-
federated.ldap.baseDN=o=realm02
-
存储库3:
-
federated.ldap.id=Repository3_pvcent49.cn.ibm.com:389
-
federated.ldap.baseDN=dc=ids601,dc=com
在下面的例子中,我们将把这三个存储库中的三个不同基本项分布到两个用户域 realm1 和 reaml2 中,如下图 4 所示。其中 realm1 包含存储库1的基本项 o=realm01 和存储库3中的基本项 dc=ids601,dc=com;realm2 将仅包含存储库2的基本项 o=realm02。
图 4. 多用户域中存储库示例

现在让我们开始运行多用户域配置的 ConfigEngine 任务来体验它的简单快捷吧。
首先,来生成 realm1。在 wkplc.properties 文件中修改如下参数,然后运行 wp-create-realm 任务。
wkplc.properties
-
realmName=realm1
-
securityUse=active
-
delimiter=/
-
addBaseEntry=o=realm01
任务运行完后,结果如下:
wp-create-realm
[root@pvcent107 ConfigEngine]# ./ConfigEngine.sh wp-create-realm
……
[wplc-create-realm] Instance attributes (Set 1 of 1):
[wplc-create-realm] addBaseEntry="o=realm01"
[wplc-create-realm] name="realm1"
[wplc-create-realm] ignoreDuplicateIDs="false"
[wplc-create-realm] Base entry o=realm01 was created successfully.
[wplc-create-realm] Realm realm1 was created successfully.
[wplc-create-realm] Status = Complete
……
BUILD SUCCESSFUL
Total time: 16 seconds
|
同理在 wkplc.properties 文件中修改如下参数,再通过 wp-create-realm 任务创建 realm2。
wkplc.properties
-
realmName=realm2
-
securityUse=active
-
delimiter=/
-
addBaseEntry=o=realm02
接下来,我们在 wkplc.properties 文件中修改如下参数,再通过 wp-add-realm-baseentry 任务来将存储库3的基本项 dc=ids601,dc=com 加入 realm2 中。
wkplc.properties
-
realmName=realm2
-
addBaseEntry=dc=ids601,dc=com
运行结果如下:
wp-add-realm-baseentry
[root@pvcent107 ConfigEngine]# ./ConfigEngine.sh wp-add-realm-baseentry
……
wp-add-realm-baseentry:
……
[wplc-add-realm-baseentry] Instance attributes (Set 1 of 1):
[wplc-add-realm-baseentry] addBaseEntry="dc=ids601,dc=com"
[wplc-add-realm-baseentry] name="realm2"
[wplc-add-realm-baseentry] Base entry dc=ids601,dc=com was added successfully.
[wplc-add-realm-baseentry] Status = Complete
……
BUILD SUCCESSFUL
Total time: 8 seconds
|
多用户域已经按照我们预想的方式配置完成了。重启 WebSphere Portal 后,我们接下来就可以使用用户域来创建两个虚拟门户网站-- “虚拟门户网站1”和“虚拟门户网站2”。下图所示是通过管理器创建虚拟门户网站的过程。从图中看到 realm1 被指定给了“虚拟门户网站1”;同理将 realm2 被指定给了“虚拟门户网站2”。这样 realm1 中的用户只能访问“虚拟门户网站1”;而 realm2 中的用户只能访问“虚拟门户网站2”。
图 5. 创建虚拟门户网站
除了上面用到的两个任务外,ConfigEngine 还提供了一些方便的任务对多用户域进行管理,比如可以通过任务删除和查询用户域中的基本项,切换缺省用户域等等。这些任务的使用和前面的示例类似,可以参看 WebSphere Portal V6.1 文档进行使用。
结束语
至此,我们已经介绍了 WebSphere Portal Server V6.1 中单个孤立用户注册表/联合用户注册表以及多用户域的相关应用,联合用户注册表能够使您灵活的添加/删除存储库,单个孤立用户注册表能够更好的兼容原有系统,而多用户域和虚拟门户的配置过程在此版本中大大简化,更加易于使用。
参考资料
作者简介  | |  | 王宇,IBM中国软件开发中心 WebSphere Portal 高级软件工程师。 |
 | |  | 申毅,IBM 中国软件开发中心 WebSphere Portal 部门软件工程师。 |
对本文的评价
|