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 用作 WCS 時，如果無法依據傳入訊息或資源提供確定 Liberty ID-WSF 架構，則 com.sun.identity.liberty.wsf.version 特性可確定 Liberty ID-WSF 架構。特性值可以是 1.0 或 1.1。預設值是 1.1。

備註修補程式安裝不會將 com.sun.identity.liberty.wsf.version 特性加入 AMConfig.properties 檔案 (CR# 6458184)。若要使用此新特性，請在安裝修補程式後，將它及適當的值加入 AMConfig.properties 檔案，然後重新啟動 Access Manager Web 容器。

在安裝 Access Manager 7 修補程式 3 之後，請執行下列指令來載入模式變更 (以安裝在 Solaris 系統上預設目錄中的 Access Manager 為例)：

# /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 記錄檔大小可能會擴充到數個 GB，而 Access Manager 伺服器的 amProfile_Server 記錄檔也可能增長到數個 MB。記錄檔中的異常不會導致功能失常，但會造成向使用者傳送假警報，而且記錄檔可能填滿硬碟空間。

解決方法：執行 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。amadmin 使用者具有在 amadmin 階段作業時間執行完畢之後到期的 AppSSOToken，因此會在 amSecurity 記錄檔 (預設位於 /tmp/distAuth 目錄) 中造成 FATAL ERROR。

解決方法：指定 UrlAccessAgent 做為分散式認證應用程式使用者。例如：

在用戶端 Web 容器中部署 distAuth.war 檔案之前，請變更 Makefile.distAuthUI 檔案中的下列參數：

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

或

在用戶端 Web 容器中部署 distAuth.war 檔案之後，請為每個 Access Manager 伺服器變更 AMConfig.properties 檔案中的下列特性：

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 檔案仍然有效。請使用此舊副本，方法如下：

停止伺服器。
將毀壞的 server.xml 替代為 amconfig 程序檔所備份的副本。

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 變更。必須在下一步執行 amupgrade 程序檔之後再套用 XML/LDIF 變更。
執行 amupgrade 程序檔。
重新部署 Access Manager Web 應用程式，因為 Access Manager 7 修補程式 3 進行了變更。
存取 Access Manager 主控台。

CR# 6452320：在用戶端 SDK 中使用輪詢會丟出異常

部署 Access Manager 用戶端 SDK (amclientsdk.jar) 並啟用輪詢時，會發生如下錯誤：

ERROR: Send Polling Error:
com.iplanet.am.util.ThreadPoolException: 
amSessionPoller thread pool's task queue is full.

在部署分散式認證 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

當分散式認證 UI 伺服器或 Access Manager 用戶端 SDK 部署在具有 4GB RAM 的用戶端機器上時，請在用戶端的 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。Access Manager 現在改用伺服器 ID，伺服器 ID 配置為階段作業配置的一部份，用於代理程式要重送的 cookie 值及名稱。

CR# 6429610：無法在 ID-FF SSO 使用案例中建立 SSO 記號

設定 Liberty Identity Federation Framework (ID-FF) 範例 1 之後，聯合成功，但 SSO 失敗。

解決方法：將 dsameuser 的 uuid 加入 AMConfig.properties 檔案的 com.sun.identity.authentication.special.users 特性中。若為應用程式認證， dsameuser 需要 Access Manager 伺服器不會到期的 SSO 記號。

CR# 6389564：Access Manager 登入期間，在 LDAP v3 資料存放區中對使用者的角色成員身份進行重複不斷的查詢

當使用者登入 Access Manager 時，會對使用者的 nsRoleDN 屬性進行重複的 LDAP 搜尋。

解決方法：在安裝 Access Manager 7 修補程式 3 之後，請執行下列指令 (以安裝在 Solaris 系統上預設目錄中的 Access Manager 為例)：

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

CR# 6385185：認證模組必須可以置換「goto」URL 並指定不同的 URL

認證模組可以置換「goto」URL 並請求重新導向至其他外部網站的 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 重新導向至外部網站，以便驗證使用者。如果認證成功，則會將使用者重新導向回原來的 Access Manager 伺服器 URL。範例檔案包括：

LoginModuleSample.java
LoginModuleSample.xml
testExtWebSite.jsp

若要實作此功能：

使用範例 LoginModuleSample.java 建立自訂認證模組。
將該模組載入 Access Manager 伺服器。
使用範例 LoginModuleSample.xml 在 XML 檔案中建構 RedirectCallback。
將範例 testExtWebSite.jsp 檔案用於外部網站，以測試該模組。

使用下列 URL 登入：

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

使用者名稱及密碼會重新導向至外部網站進行驗證。如果名稱及密碼有效，則認證成功，而且會將使用者重新導向回到原來的 Access Manager 伺服器 URL。

例如，請思考這樣的情況，在此情況中，部署使用自訂認證模組來存取佈建/信用卡站點：

使用者呼叫自訂認證模組的認證程序/登入頁面。
使用者輸入憑證 (使用者名稱及密碼)，並向自訂認證模組提交請求。
自訂認證模組將使用者重新導向至外部佈建/信用卡站點，同時隨附請求及必要的使用者資訊。
外部佈建/信用卡站點檢查使用者的狀態，並傳回請求成功或失敗的訊息，該訊息設定為所傳回之請求的一部分。
自訂認證模組根據步驟 4 中傳回的狀態驗證使用者，並將對應狀態傳回認證服務。
使用者認證完成，結果為成功或失敗。

CR# 6324056：使用工件設定檔時聯合失敗

解決方法：若要修正此問題，請根據您的平台套用最新版本的「Core Mobile Access」修補程式：

基於 SPARC 之系統上的 Solaris OS：119527
x86 平台上的 Solaris OS：119528
Linux 系統：119529

套用修補程式後，重新啟動 Web 容器。