Access Manager 7 2005Q4 修补程序 3 (Sun Java System Access Manager 7 2005Q4 发行说明)

Sun Java System Access Manager 7 2005Q4 发行说明

Access Manager 7 2005Q4 修补程序 3

Access Manager 7 修补程序 3（修订版 03）可修复一系列的问题，其随附的自述文件中列出了具体内容。修补程序 3 还具有以下新增功能和已知问题：

修补程序 3 的新增功能

修补程序 3 的已知问题和限制

站点监视的新配置属性

Access Manager 站点监视功能包括以下新属性：

属性	描述
`com.sun.identity.sitemonitor.interval`	站点监视的间隔时间（单位为毫秒）。站点监视功能会在指定的时间间隔内检查每个站点的可用性。默认值：60000 毫秒（1 分钟）。
`com.sun.identity.sitemonitor.timeout`	站点可用性检查的超时时间（单位为毫秒）。站点监视功能会在指定的超时时间内等待站点的响应。默认值：5000 毫秒（5 秒）。

修补程序没有将这些属性添加到 AMConfig.properties 文件中。若要以默认值以外的其他值使用这些新属性，请执行下列操作：

将属性及其值添加到位于以下目录的 AMConfig.properties 文件中，具体目录取决于您所使用的平台：
- Solaris 系统：/etc/opt/SUNWam/config
- Linux 系统：/etc/opt/sun/identity/config
对于策略代理，将这些属性添加到 AMAgents.properties 文件。
重新启动 Access Manager Web 容器以使这些值生效。

自定义实现。另外，com.sun.identity.sitemonitor.SiteStatusCheck 类允许您使用以下接口自定义用于检查站点可用性的实现：

package com.iplanet.services.naming.WebtopNaming$SiteStatusCheck

每个实现类均必须使用 doCheckSiteStatus 方法。

public interface SiteStatusCheck { 
public boolean doCheckSiteStatus(URL siteurl);
}

Liberty Identity Web Services Framework (ID-WSF) 1.1 支持

Access Manager 7 修补程序 3 中的 ID-WSF 默认版本为 WSF1.1。除示例需使用新的安全机制外，触发 ID-WSF 不需要单独的配置。用于 ID-WSF1.1 的新安全机制为：

urn:liberty:security:2005-02:null:X509
urn:liberty:security:2005-02:TLS:X509
urn:liberty:security:2005-02:ClientTLS:X509
urn:liberty:security:2005-02:null:SAML
urn:liberty:security:2005-02:TLS:SAML
urn:liberty:security:2005-02:ClientTLS:SAML
urn:liberty:security:2005-02:null:Bearer
urn:liberty:security:2005-02:TLS:Bearer
urn:liberty:security:2005-02:ClientTLS:Bearer

Liberty ID-WSF 支持的新属性

在 Access Manager 充当 WSC 的情况下，当无法通过入站消息或资源提供来确定 Liberty ID-WSF 框架时，com.sun.identity.liberty.wsf.version 属性可确定 Liberty ID-WSF 框架。其值可以是 1.0 或者 1.1，默认为 1.1。

注安装修补程序时不会在 AMConfig.properties 文件中添加 com.sun.identity.liberty.wsf.version 属性 (CR# 6458184)。要使用此新属性，在安装修补程序后，将它和适当的值添加到 AMConfig.properties 文件中，然后重新启动 Access Manager Web 容器。

安装 Access Manager 7 修补程序 3 后，运行以下命令来加载模式更改（以将 Access Manager 安装在 Solaris 系统上的默认目录中为例）：

# /opt/SUNWam/bin/amadmin -u amadmin -w amadmin_password 
-t /etc/opt/SUNWam/wsf1.1_upgrade.xml

注册时，ID-WSF 搜索注册可使用这些新的安全机制。此外，WSC 在与 WSP 通信时会自动检测应使用哪个版本。要为 ID-WSF1.1 进行配置，请遵循产品随附的 Liberty ID-FF 范例 1 和 ID-WSF 范例的自述文件进行操作。

CR# 6463779 分布式验证的 `amProfile_Client` 日志和 Access Manager 服务器的 `amProfile_Server` 日志中充满了无害的异常

通过分布式验证 UI 向 Access Manager 服务器发送请求时，会触发异常并记录到 distAuth/amProfile_Client 日志和 Access Manager 服务器的 debug/amProfile_Server 日志中。经过大量会话后，amProfile_Client 日志的大小可增长到数千兆字节，而 Access Manager 服务器的 amProfile_Server 日志的大小可达数兆字节。日志中的这些异常不会对功能造成影响，但它们能导致用户接收到虚假报警，并且这些日志可能会填满整个硬盘空间。

解决方法。运行 cron 作业以清空日志文件内容。例如：

在分布式验证 UI 客户机上，每隔几个小时就运行一次 "cat /dev/null > distAuth/amProfile_Client"，具体间隔时间视流量大小而定。
在 Access Manager 服务器上，每隔几天（而不是几小时）就运行一次 "cat /dev/null > /var/opt/SUNWam/debug/amProfile_Server"。

CR# 6460974 默认分布式验证应用程序用户不应该是 `amadmin`

如果部署的是分布式验证 UI 服务器，则分布式验证管理员不应该是 amadmin。Makefile.distAuthUI 文件中的默认分布式验证应用程序用户是 amadmin，在客户机端部署 distAuth.war 文件后，此设置也随后出现在 AMConfig.properties 文件中。amadmin 用户具有的 AppSSOToken 会在 amadmin 会话结束时过期，这将在 amSecurity 日志文件（默认情况下位于 /tmp/distAuth 目录下）中产生 FATAL ERROR。

解决方法。将 UrlAccessAgent 指定为分布式验证应用程序用户。例如：

在客户机 Web 容器中部署 distAuth.war 文件之前，更改 Makefile.distAuthUI 文件中的以下参数：

APPLICATION_USERNAME=UrlAccessAgent
APPLICATION_PASSWORD=shared-secret-password 或 amldapuser-password

或

在客户机 Web 容器中部署 distAuth.war 文件之后，在 AMConfig.properties 文件中更改每个 Access Manager 服务器的以下属性：

com.sun.identity.agents.app.username=UrlAccessAgent
com.iplanet.am.service.password=shared-secret-password 或 amldapuser-password

另请参见CR# 6440697：分布式验证应以非 amadmin 用户身份运行。

CR# 6460576 控制台联机帮助的“过滤的角色”下，没有“用户服务”的链接

Access Manager 控制台联机帮助的“过滤的角色”下没有“用户服务”链接。在联机帮助中，转至“内容”、“过滤的角色”、“创建过滤的角色”。向下翻页，根据您所选的身份类型，会显示服务列表，但其中没有“用户服务”链接。

解决方法。无

CR# 6460085 运行 `reinstallRTM` 并重新部署 Web 应用程序之后，无法访问 WebSphere 上的服务器

在 Red Hat Linux AS 3.0 Update 4 的 IBM WebSphere Application Server 5.1.1.6 上对 DEPLOY_LEVEL=1 的部署应用 Access Manager 7 修补程序 3 之后，运行 reinstallRTM 脚本恢复 RTM RPM。在编辑了由 reinstallRTM 脚本生成的 amsilent 文件后，重新部署 Web 应用程序。用 stopServer.sh 和 startServer.sh 脚本重新启动 WebSphere。然后，访问登录页面时，WebSphere 却显示与 amlcontroller 过滤器相关的 500 错误。

发生此问题的原因是 reinstallRTM 脚本生成的新 server.xml 文件已损坏。

解决方法。amconfig 脚本备份的 server.xml 文件仍然有效。可以按照以下步骤来使用先前的副本：

停止服务器。
用 amconfig 脚本备份的副本替换损坏的 server.xml。

amconfig 脚本备份的 server.xml 文件的名称为 server.xml-orig- pid，其中 pid 是 amwas51config 脚本的进程 ID。此文件位于下面的目录中：
```
WebSphere-home-directory/config/cells/WebSphere-cell
/nodes/WebSphere-node/servers/server-name
```
重新启动服务器。

CR# 6455757：升级前必须将 `sunISManagerOrganization` 标记类添加到组织中

在 Access Manager 7 发行之前创建的 Access Manager DIT 中的组织可能不具有 sunISManagerOrganization 对象类。而且，由 Access Manager 以外的其他产品所创建组织的定义中也不会有 sunISManagerOrganization 对象类。

解决方法。在升级到 Access Manager 7 2005Q4 前，确保 DIT 中所有组织的定义中都具有 sunISManagerOrganization 对象类。如有必要，在升级前手动添加此对象类。

CR# 6454489：Access Manager 7 2005Q4 修补程序 2 升级导致控制台“当前会话”选项卡中出错

升级导致在 Access Manager 控制台的“当前会话”选项卡中出现以下错误：

无法从指定服务器获取有效的会话

对于从根后缀格式为 o=orgname 的 Access Manager 6 版本升级的部署，均会出现此问题。

解决方法。安装 Manager 7 2005Q4 后，应用 Manager 7 修补程序 3，然后运行 amupgrade 脚本以进行数据迁移，方法如下：

备份 Access Manager 6 DIT。
运行 ampre70upgrade 脚本。
安装 Access Manager 7 2005Q4，选择“以后再配置”选项。
取消部署 Access Manager Web 应用程序。
部署 Access Manager Web 应用程序。
应用 Access Manager 7 修补程序 3，但不要应用 XML/LDIF 更改。XML/LDIF 更改必须在下一步运行 amupgrade 脚本之后再应用。
运行 amupgrade 脚本。
因为 Access Manager 7 修补程序 3 进行了更改，重新部署 Access Manager Web 应用程序。
访问 Access Manager 控制台。

CR# 6452320：在客户机 SDK 中使用轮询时抛出异常

若在部署 Access Manager 客户机 SDK (amclientsdk.jar) 后启用轮询，可能发生如下错误：

错误：发送轮询错误：
com.iplanet.am.util.ThreadPoolException：
amSessionPoller 线程池的作业队列已满。

部署分布式验证 UI 服务器、J2EE 代理后，或者在客户机上部署了 Access Manager 客户机 SDK 的情况下，均可能发生此类错误。

解决方法。如果只有数百个并发会话，则在 AMConfig.properties 文件或者 AMAgents.properties 文件中添加以下属性和值：

com.sun.identity.session.polling.threadpool.size=10
com.sun.identity.session.polling.threadpool.threshold=10000

如果有数千或数万个会话，则应将值设置为与运行 amtune-identity 脚本后 Access Manager AMConfig.properties 文件中通知的值相同。例如，对于一台有 4 GB RAM 的计算机，Access Manager amtune-identity 脚本会设置以下值：

com.sun.identity.session.notification.threadpool.size=28
com.sun.identity.session.notification.threadpool.threshold=76288

在拥有 4 GB RAM 的客户机上部署了分布式验证 UI 服务器或 Access Manager 客户机 SDK 后，应在客户机端的 AMAgent.properties 或 AMConfig.properties 文件中设置类似的值。

CR# 6442905 已验证用户的 `SSOToken` 可能会在无意中透露给流氓站点

已验证的 Access Manager 用户单击流氓站点的 URL 时，可能会在无意中将 SSOToken 透露给流氓站点。

解决方法。在 Access Manger 中总是为所有参与的策略代理创建唯一的代理用户配置文件，以确保站点不是流氓站点。同时确保这些唯一代理用户使用的密码均不与共享的秘密密码或者 amldapuser 密码相同。默认情况下，Access Manager 应用程序验证模块将策略代理验证为 UrlAccessAgent 用户。

有关使用 Access Manager 管理控制台创建代理的详细信息，参见《Sun Java System Access Manager 7 2005Q4 管理指南》中的“代理”。

CR# 6441918：站点监视时间间隔和超时属性

Access Manager 站点故障转移包括以下新属性：

com.sun.identity.sitemonitor.interval
com.sun.identity.sitemonitor.timeout

有关详细信息，参见站点监视的新配置属性。

CR# 6440697：分布式验证应以非 amadmin 用户身份运行

要为分布式验证应用程序验证创建默认管理用户 (amadmin) 以外的分布式验证管理员，遵循以下步骤：

为分布式验证管理员创建 LDAP 用户。例如：
```
uid=DistAuthAdmin,ou=people,o=am
```
将分布式验证管理员添加到特殊用户列表。例如：
```
com.sun.identity.authentication.special.users=cn=dsameuser,
ou=DSAME Users,o=am|cn=amService-UrlAccessAgent,ou=DSAME Users,
o=am|uid=DistAuthAdmin,ou=People,o=am
```
将此属性添加到所有 Access Manager 服务器的 AMConfig.properties 文件中，这样分布式验证管理员的 AppSSOToken 在会话到期后也不会过期。

CR# 6440695：包含负载平衡器的分布式验证 UI 服务器

如果您的部署中在多个分布式验证 UI 服务器之前包含负载平衡器，则在部署 WAR 文件之后设置 AMConfig.properties 文件中的以下属性。

com.iplanet.am.lbcookie.name=DistAuthLBCookieName
com.iplanet.am.lbcookie.value=DistAuthLBCookieValue

CR# 6440651：Cookie 重放需要 `com.sun.identity.session.resetLBCookie` 属性

为使 Access Manager 会话故障转移的 cookie 重放功能正常工作，为策略代理和 Access Manager 服务器添加值为 true 的 com.sun.identity.session.resetLBCookie 属性。例如：

com.sun.identity.session.resetLBCookie='true'

对于策略代理，将此属性添加到 AMAgent.properties 文件。
对于 Access Manager 服务器，将此属性添加到 AMConfig.properties 文件。

注意：仅当已实施 Access Manager 会话故障转移后需要此属性。

CR# 6440648：`com.iplanet.am.lbcookie.name` 属性假定默认值为 `amlbcookie`

默认情况下，策略代理和 Access Manager 服务器假定负载平衡器 cookie 名称为 amlbcookie。如果在后端服务器更改了此 cookie 的名称，则必须为策略代理在 AMAgent.properties 文件中使用相同的名称。同样，如果使用 Access Manager 客户机 SDK，也必须使用后端服务器所使用的同一 cookie 名称。

CR# 6440641：`com.iplanet.am.lbcookie.value` 属性已过时

Access Manager 不再支持服务器上的 com.iplanet.am.lbcookie.value 属性自定义负载平衡器 cookie。现在，对于由代理重放的 cookie 值及名称，Access Manager 使用配置为会话配置一部分的服务器 ID 。

CR# 6429610：在 ID-FF SSO 使用案例中无法创建 SSO 令牌

设置 Liberty Identity Federation Framework (ID-FF) 范例 1 后，联合成功，但 SSO 失败。

解决方法。在 AMConfig.properties 文件中，将 dsameuser 的 uuid 添加到 com.sun.identity.authentication.special.users 属性。对于应用程序验证，dsameuser 需要 Access Manager 服务器不会过期的 SSO 令牌。

CR# 6389564：在 Access Manager 登录期间，会在 LDAP v3 数据存储库中对用户的角色成员资格进行重复不断的查询

用户登录到 Access Manager 时，会发生对用户的 nsRoleDN 属性进行重复 LDAP 搜索的情况。

解决方法。安装 Access Manager 7 修补程序 3 后，运行以下命令（以将 Access Manager 安装在 Solaris 系统上的默认目录中为例）：

# /opt/SUNWam/bin/amadmin -u amadmin 
-w amadmin_password 
-t /etc/opt/SUNWam/idRepoServiceAddAttrSchemaRequest_Cache.xml

CR# 6385185：验证模块必须能够覆盖 "goto" URL，并指定另一不同的 URL

验证模块可覆盖 "goto" URL 并请求重定向到其他外部 Web 站点的 URL 以验证用户状态

要在验证完成后覆盖 "goto" URL，在 SSOToken 中设置以下示例中所示的属性。可使用实现 AMPostAuthProcessInterface 的 PostProcess 类的 onLoginSuccess 方法来设置此属性。例如，在下例中 OverridingURL 即是覆盖 "goto" URL 的 URL：

public class <..> implements AMPostAuthProcessInterface {  
...
    public void onLoginSuccess(...) {
        try {
            ssoToken.setProperty("PostProcessSuccessURL", OverridingURL);
         } catch (Exception ...) {
         ...         }
...
}

CR# 6385184：当 SSO 令牌仍处于无效状态时，从自定义验证模块重定向

自定义验证模块中的新 RedirectCallback 方法允许通过验证 UI 重定向至外部 Web 站点来进行用户验证。如果验证成功，则会在之后将用户重定向回原来的 Access Manager 服务器 URL。范例文件包括：

LoginModuleSample.java
LoginModuleSample.xml
testExtWebSite.jsp

要实现此功能：

使用范例 LoginModuleSample.java 创建自定义验证模块。
将此模块加载到 Access Manager 服务器中。
使用范例 LoginModuleSample.xml 在 XML 文件中构造 RedirectCallback。
为外部 Web 站点使用范例 testExtWebSite.jsp 文件以测试此模块。

使用以下 URL 登录：

http://example.com/amserver/UI/Login?module=LoginModuleSample

用户名和密码均重定向至外部 Web 站点进行验证。如果用户名和密码都有效，则验证成功，然后将用户重定向回原来的 Access Manager 服务器 URL。

例如，设想一下这样的方案 - 在此方案中部署使用自定义验证模块来访问某个置备/信用卡站点：

用户调用自定义验证模块的验证进程/登录页面。
此用户输入证书（用户名和密码），然后向自定义验证模块提交请求。
自定义验证模块将用户重定向至外部置备/信用卡站点，并同时传递请求和所需的用户信息。
外部置备/信用卡站点检查用户的状态，然后返回请求以及成功或失败信息（已设为返回请求的一部分）。
自定义验证模块根据第 4 步返回的状态验证用户，并向验证服务返回相应的状态。
用户验证完成（成功或失败）。

CR# 6324056：使用辅件配置文件时联合失败

解决方法：要修复此问题，根据您所使用的平台，应用最新版本的 "Core Mobile Access" 修补程序：

基于 SPARC 系统的 Solaris OS：119527
x86 平台上的 Solaris OS：119528
Linux 系统：119529

应用修补程序后，重新启动 Web 容器。