Liberty:鑑別

在 Liberty 安全中,鑑別就是確認使用者的身分。

如果要存取受保護的 Web 資源,使用者必須提供認證資料,例如:使用者 ID 與密碼。鑑別程序包含收集這個使用者認證資訊(根據如何配置 Web 應用程式來收集這個資料),以及對照所配置的登錄來驗證它。 當驗證認證資訊時,會建立這個使用者的 JAAS 主體。 這個主體包含使用者的其他相關資訊,例如,使用者所屬的群組以及針對使用者建立的記號。 之後,在授權程序期間,會利用這個主體中的資訊來判斷使用者是否可以存取資源。

下圖說明 Web 資源的一般鑑別程序流程。

圖 1. 鑑別程序概觀鑑別服務利用 JAAS 登入模組來處理鑑別。

鑑別程序包含從使用者收集認證資料、檢查快取來查看這個使用者的主體是否存在,當不存在時,會呼叫 JAAS 服務執行鑑別來建立主體。 JAAS 服務會呼叫一組登入模組來處理鑑別。 一或多個登入模組會根據認證資料來建立主體。 之後,登入模組會呼叫配置來驗證認證資訊的登錄。 如果驗證成功,鑑別程序會收集及建立這位使用者的相關資訊,其中包括使用者所屬的群組以及 SSO 功能所用的單一登入 (SSO) 記號,且會將它們當作相關的認證而儲存在主體中。您也可以在這項程序期間外掛自訂登入模組,來自訂儲存在主體中的資訊。

當鑑別成功時,這個程序期間所建立的 SSO 記號會傳回瀏覽器的 Cookie 中。 這個可配置的 Cookie,預設名稱是 ltpaToken2。 在後續呼叫時,會利用記號資訊來鑑別使用者。 如果這個鑑別失敗,但要求中仍有其他鑑別資料,例如使用者 ID 和密碼,鑑別服務會嘗試使用這些資料。
註: 如果要支援包含非 US-ASCII 字元的使用者 ID 和密碼,Web 應用程式需要有表單登入方法。如需相關資訊,請參閱 autoRequestEncoding 和 autoResponseEncoding

使用者登錄

當驗證使用者的鑑別資料時,登入模組會呼叫配置來驗證使用者資訊的使用者登錄。 Liberty 支援簡式配置型使用者登錄,也支援更健全的 LDAP 型登錄。 如需相關資訊,請參閱在 Liberty 中配置使用者登錄

當使用 LDAP 登錄時,您還可以將多個儲存庫聯合起來,以及在兩個或更多登錄上執行 LDAP 作業。 Liberty 使用者可以直接在 server.xml 檔中配置 LDAP 登錄聯合特性,也可以在開發人員工具的 LDAP 登錄聯合區段中配置。配置聯合儲存庫之後,您可以在您想要執行的任何作業上,取得聯合儲存庫的合併結果。 比方說,如果您想要對開頭是 test 的所有使用者名稱執行搜尋作業,您可以在整組 LDAP 登錄中執行搜尋,並取得合併的搜尋結果,這個結果之後可以傳回呼叫端程式。

鑑別快取

由於建立主體的相對成本較高,Liberty 提供了在使用者鑑別成功之後,用來儲存主體的鑑別快取。快取的預設有效期限是 10 分鐘。 如果使用者沒有在 10 分鐘內再次登入,就會移除主體,且會重複鑑別程序來建立這位使用者的主體。 會影響建立主體的配置變更,例如,新增登入模組或變更 LTPA 金鑰,會導致清除鑑別快取。 如果快取主體,但登錄中的資訊又變更了,就會用登錄中的資訊來更新快取。 您可以配置快取逾時期間和快取大小,也可以停用或啟用快取。 如需相關資訊,請參閱在 Liberty 中配置鑑別快取

JAAS 配置

JAAS 配置定義一組登入模組來建立主體。 Liberty 支援下列 JAAS 配置:
system.WEB_INBOUND
在存取 Servlet 和 JSP 之類的 Web 資源時使用。
WSLogin
在使用程式化登入時,供應用程式使用。此外,也供在應用程式用戶端儲存器中執行的應用程式使用,但是不同於 ClientContainerJAAS 配置,它無法識別用戶端應用程式模組的部署描述子中指定的 CallbackHandler 處理程式。
system.DEFAULT
當未指定 JAAS 配置時,用來登入。
system.DESERIALIZE_CONTEXT
在解除序列化安全環境定義時使用。這項 JAAS 配置會處理鑑別,以重建將安全環境定義序列化時作用於執行緒的主體。您可以在 server.xml 檔中編輯 JAAS 配置項目,來指定這項 JAAS 配置,並新增自己的 JAAS 登入模組,以確保所傳播的主體含有您的自訂資訊。
ClientContainer
供在應用程式用戶端儲存器中執行的應用程式使用。這種 JAAS 登入配置可辨識用戶端應用程式模組的部署描述子中指定的 CallbackHandler 處理程式(若有指定的話)
在 system.WEB_INBOUND 和 system.DEFAULT 配置中,這些預設登入模組的順序如下:hashtableuserNameAndPasswordcertificatetoken。WSLogin 配置的預設登入模組是 Proxy 登入模組,Proxy 會將所有作業全部委派給 system.DEFAULT 中實際的登入模組。

除非您想要利用自訂登入模組來進行自訂,否則,不需要任何明確的配置。 您可以依照需求來自訂特定的登入配置。 比方說,如果您想自訂所有 Web 資源登入,您必須只將自訂登入模組新增到 system.WEB_INBOUND 配置中。 請參閱 配置 Liberty 的 JAAS 自訂登入模組

JAAS 登入模組

JAAS 配置利用一組登入模組來建立主體。Liberty 在每個登入配置中,各提供一組登入模組。特定登入模組會依鑑別資料而定來建立主體。 依照 JAAS 規格所指定,鑑別資料會利用回呼處理常式來傳遞給登入模組。 比方說,如果利用使用者 ID 和密碼回呼處理常式來進行鑑別,userNameAndPassword 登入模組會處理這項鑑別。 如果是 SingleSignonToken 認證呈現為鑑別資料,就只有記號登入模組會處理鑑別。

Liberty 支援下列預設登入模組:
userNameAndPassword
當利用使用者名稱和密碼來作為鑑別資料時,用來處理鑑別。
憑證
當利用 X509 憑證來作為相互 SSL 的鑑別資料時,用來處理鑑別。
記號
當 SSO 記號呈現為鑑別資料時,用來處理鑑別。 在鑑別程序期間,會建立 SSO 記號,並在 Cookie 中傳回 HTTP 用戶端(瀏覽器)。 在後續要求時,瀏覽器會傳回這個 Cookie,當啟用單一登入時,伺服器會從 Cookie 中擷取這個記號來鑑別使用者。
雜湊表
在透過預先定義的雜湊表來傳送鑑別資料之時使用。 如需雜湊表登入的相關資訊,請參閱雜湊表登入模組。 當只利用身分來執行鑑別時,安全執行時期也會使用這個登入模組;例如,在 runAs 的情況中,就是如此。
proxy
WSLogin 的預設登入模組。 請參閱 Proxy 登入模組

登入模組是依照配置順序來呼叫。 預設順序是 hashtableuserNameAndPasswordcertificatetoken。 如果您必須利用自訂登入模組來自訂登入程序,您可以依照您需要的順序來提供它們及配置它們。 通常是將一個自訂登入模組放在登入模組清單中的第一個位置,以便首先呼叫它。 當使用自訂登入模組時,您必須依照必要的順序指定自訂登入模組,以及將所有登入模組資訊指定在配置中。

當登入模組判斷它能夠處理鑑別時,它會先確定傳入的鑑別資料是否有效。 比方說,如果是使用者名稱和密碼鑑別,就會呼叫配置的使用者登錄來驗證鑑別資訊。 如果是記號鑑別,記號必須解密且有效,驗證才會成功。

當驗證鑑別資料時,登入模組會利用使用者的其他資料來建立認證,其中包括群組和 SSO 記號。 自訂登入模組也可以建立它自己的認證來新增其他資料到主體中。 如果要讓 Liberty 授權起作用,這個主體必須包含 WSCredentialWSPrincipalSingleSignonToken 認證。WSCredential 認證包含群組資訊,以及安全執行時期環境所需要的其他資訊。

回呼處理常式

Liberty 支援在 JAAS 鑑別程序期間,向登入模組提供資料的各種回呼處理常式。自訂登入模組可以利用回呼處理常式資訊來鑑別它本身。 比方說,如果回呼處理常式必須存取 HttpServletRequest 物件中的某些資訊,它可以利用這個特定的回呼處理常式來執行這個動作。

Liberty 支援程式化 JAAS 登入的下列回呼處理常式和 Factory:
  • com.ibm.websphere.security.auth.callback.WSCallbackHandlerImpl
  • com.ibm.wsspi.security.auth.callback.WSCallbackHandlerFactory
每一個 Liberty API 的 Java API 文件都是以個別的 .zip 檔來提供(其位於 ${wlp.install.dir}/dev 目錄下的其中一個 javadoc 子目錄中)。

請參閱 開發系統登入配置的 JAAS 自訂登入模組

認證和記號

loginModule 一節所提及,建立主體的程序中會建立認證。 Liberty 會建立 WSCredentialSingleSignonTokenWSPrincipal 認證。SingleSignonToken 認證包含在 Cookie 中傳回給瀏覽器的記號,以使 SSO 能運作。 這個記號包含使用者資訊和有效期限。 它是利用第一次啟動伺服器時所產生的「小型認證機構 (LTPA)」金鑰來簽章和加密。 預設有效期限是 2 小時,這是一個絕對時間,不是以使用者活動為基礎。 2 小時之後,記號會到期,使用者必須重新登入,才能存取資源。

LTPA

LTPA 主要用於分散式環境及多重應用程式伺服器環境。 在 Liberty 中,LTPA 透過加密法來支援分散式環境中的 SSO 和安全。這種支援使 LTPA 能夠對鑑別的相關資料進行加密、數位簽章,以及進行安全傳輸,然後再進行解密及驗證簽章。

應用程式伺服器可以利用 LTPA 通訊協定來安全通訊。 另外,這個通訊協定也提供 SSO 特性,只有在連接到網域名稱系統 (DNS) 時,才需要鑑別使用者。 之後,系統不會進行任何提示,使用者就可以存取相同網域其他 Liberty 伺服器中的資源。DNS 網域每一個系統的網域範圍名稱都會區分大小寫,且必須完全相符。

LTPA 通訊協定利用加密金鑰來進行伺服器之間所傳遞之使用者資料的加密和解密。 如果所有涉及的伺服器都使用相同的使用者登錄,各不同伺服器必須共用這些金鑰,一部伺服器上的資源才能存取其他伺服器中的資源。 LTPA 要求所配置的使用者登錄必須是一個集中共用的儲存庫,以便不論是哪一部伺服器,使用者和群組都會相同。

當使用 LTPA 時,會建立一個包含使用者資訊和有效期限的記號,且會用金鑰來進行簽章。 LTPA 記號會區分時間。 所有參與的伺服器,其時間和日期都必須同步。 否則,LTPA 記號會提早過期,而導致鑑別或驗證失敗。 依預設,會使用世界標準時間 (UTC),所有其他伺服器都必須有相同的 UTC 時間。 請參閱您的作業系統說明文件,以取得如何確保各伺服器有相同 UTC 時間的相關資訊。

當啟用 SSO 時,會透過 Web 資源的 Cookie,將 LTPA 記號傳給其他伺服器。

如果接收端伺服器與原始伺服器使用相同的金鑰,就可以將記號解密來取得使用者資訊,之後,會加以驗證,確保記號沒有過期,且記號中的使用者資訊在其登錄中有效。 驗證成功時,在授權檢查之後,就可以存取接收端伺服器中的資源。

每一部伺服器都必須具備有效的認證。 當認證到期時,伺服器必須與使用者登錄通訊來進行鑑別。 將 LTPA 記號保持快取的時間延長,當定義安全原則時,會稍微增加必須考量的安全風險。

如果需要在不同的 Liberty 伺服器之間共用金鑰,請在伺服器之間複製金鑰。為了安全,會用隨機產生的金鑰將金鑰加密,且會利用使用者定義的密碼來保護金鑰。將金鑰匯入另一部伺服器時,需要這個相同的密碼。 這個密碼只用來保護金鑰,不用來產生金鑰。

當啟用安全時,在 Liberty 伺服器的啟動期間,依預設,會配置 LTPA。如需 LTPA 支援的相關資訊,請參閱在 Liberty 中配置 LTPA

OpenID

OpenID 是一種開放式鑑別標準,可讓使用者本身接受多個實體的鑑別,而不需要管理多個帳戶或多組認證。Liberty 以「依賴方」身分運作,來支援「OpenID 鑑別 2.0」標準。在這項標準中,「依賴方」需要來自「OpenID 提供者」的鑑別確認。使用者將不提供認證給「依賴方」,反倒會將他們重新導向至「OpenID 提供者」,來提交其認證。「OpenID 提供者」會向「依賴方」確認鑑別結果,並傳回使用者擁有的唯一 ID,可能還外加使用者核准的一部分個人資訊,例如:使用者名稱或電子郵件位址。接著,「依賴方」可以使用此資訊來完成鑑別,甚至不需處理使用者的認證。此外,使用者可以將單一帳戶與「OpenID 提供者」搭配使用,利用任何擔任「依賴方」的實體來自我鑑別,如此就不需要管理或建立每一個實體的唯一帳戶。

如需 OpenID 的相關資訊,請參閱OpenID。 如果要在 Liberty 伺服器上配置 OpenID,請參閱在 Liberty 中配置「OpenID 依賴方」

OpenID Connect

OpenID Connect 是一種簡式身分通訊協定和開放式標準,以 OAuth 2.0 通訊協定為建置基礎。OpenID Connect 可讓用戶端應用程式根據「OpenID Connect 提供者」執行的鑑別,來驗證使用者的身分。

用戶端應用程式也可以採取可交互作業的類 REST 方式,從「OpenID Connect 提供者」取得使用者的基本設定檔資訊。OpenID Connect 支援以 OpenID Connect 標準 1.0 版為基礎。

如需 OpenID Connect 的相關資訊,請參閱 OpenID Connect。如果要在 Liberty 伺服器上配置 「OpenID Connect 用戶端」或「依賴方」,請參閱在 Liberty 中配置「OpenID Connect 用戶端」。如果要在 Liberty 伺服器上配置「OpenID Connect 提供者」,請參閱在 Liberty 中配置「OpenID Connect 提供者」

SPNEGO

「簡易且受保護的 GSS-API 協議機制 (SPNEGO)」可讓使用者只需登入 Microsoft 網域控制站一次,就能存取 Liberty 伺服器上受保護的應用程式,而不會再次獲得提示。

當啟用 SPNEGO Web 鑑別時,如果瀏覽器用戶端存取 Liberty 伺服器上受保護的資源,SPNEGO 會負責鑑別 HTTP 要求中所識別之受保護資源的存取權。瀏覽器用戶端會建立 SPNEGO 記號,並成為 HTTP 要求的一部分,一併傳送給 Liberty 伺服器。WebSphere Application Server 會驗證並擷取 SPNEGO 記號中的使用者身分。身分用來在使用者與應用程式伺服器之間建立安全環境定義。

如需 SPNEGO 的相關資訊,請參閱使用 SPNEGO Web 鑑別針對 HTTP 要求進行單一登入。 如需在 Liberty 伺服器上配置 SPNEGO 的進一步相關資訊,請參閱在 Liberty 中配置 SPNEGO 鑑別

SPNEGO 的 Kerberos 受限委派

Kerberos 受限委派特性提供兩個 API,用來為支援 SPNEGO 鑑別的後端服務(例如:.NET 伺服器和其他 Liberty 伺服器)建立出埠 SPNEGO 記號。

Kerberos 第 5 版延伸稱為 S4U(Services for Users,使用者服務),由下列兩個組件組成:
S4U2self

容許 Liberty 伺服器代表使用者取得通往其本身的服務通行證。這可搭配 Liberty 支援的任何鑑別形式。S4U2self 是「Kerberos 通訊協定轉移」的延伸。

S4U2proxy

容許 Liberty 伺服器代表使用者取得通往授信服務的服務通行證。這些服務通行證是利用使用者通往 Liberty 服務的服務通行證取得。這些服務受限於「Kerberos 金鑰配送中心 (KDC)」管理者。S4U2proxy 是「Kerberos 受限委派」的延伸。

單一登入 (SSO)

SSO 可讓使用者登入一個位置(如一部伺服器),然後無需系統的任何提示,就可以再度存取其他伺服器中的應用程式。 如果要使 SSO 能夠運作,LTPA 金鑰必須能夠在不同的 Liberty 伺服器之間進行交換,使用者登錄必須相同,且記號不能過期。如果要交換 LTPA 金鑰,您可以在伺服器之間複製 ltpa.keys 檔,然後重新啟動伺服器來使用新的 LTPA 金鑰。 參與 SSO 網域的所有伺服器必須使用相同的登錄。

當使用者在某一 Liberty 伺服器中接受鑑別時,鑑別程序期間為這個使用者所建立的 SSO 記號會放在傳給 HTTP 用戶端(如瀏覽器)的 Cookie 中。如果這個用戶端發出另一個要求來存取在不同伺服器上,但仍在第一部伺服器的 SSO 配置中所配置的相同 DNS 內的另一組應用程式,這個 Cookie 會隨著要求而一併傳送。 接收端伺服器會嘗試利用 Cookie 中的記號來鑑別使用者。 如果符合這兩個條件,接收端伺服器會驗證記號,且會根據這部伺服器中的使用者來建立一個主體,不會提示使用者重新登入。如果無法驗證記號(例如,因為 LTPA 金鑰不符而無法解密或驗證記號),就會提示使用者重新輸入認證資訊。

任何配置來使用 Form-login 屬性的應用程式都必須配置這部伺服器的 SSO。 當使用者接受 form-login 鑑別時,記號會傳回存取資源時將用來進行使用者授權的瀏覽器。

請參閱 在 Liberty 中利用 LTPA Cookie 來自訂 SSO 配置

SAML Web 瀏覽器 SSO

「SAML Web 瀏覽器 SSO」可讓 Web 應用程式將使用者鑑別委派給 SAML 身分提供者,而非所配置的使用者登錄。

如需在 Liberty 伺服器上配置「SAML Web 瀏覽器 SSO」的進一步資訊,請參閱SAML 2.0 Web 瀏覽器單一登入

外掛式鑑別

請利用下列方法來自訂鑑別程序:
  • 提供一個自訂登入模組。大部分鑑別程序都是圍繞著 JAAS 登入模組來建置,因此,您可以在 Liberty 所提供的登入模組之前、之後或之間,外掛自訂的登入模組。請參閱 配置 Liberty 的 JAAS 自訂登入模組
  • 實作「信任關聯攔截程式 (TAI)」來處理所有基於 Web 資源的鑑別。 請參閱 開發 Liberty 的自訂 TAI

如需 JAAS 登入模組和 TAI 的相關資訊,請參閱 WebSphere Application Server 中的進階鑑別

身分主張

除了必須要求實體來證明其身分的鑑別,Liberty 也支援身分主張。這是一個不需要身分證明的寬鬆鑑別形式,它根據一種與所主張的身分之擔保實體的信任關係來接受身分。

請利用下列方法來主張 Liberty 中的身分:
  1. 使用雜湊表登入。請參閱 開發系統登入配置的 JAAS 自訂登入模組
  2. 使用 IdentityAssertionLoginModule。 您可以讓應用程式或系統提供者利用信任驗證來主張身分。 如果要使用 IdentityAssertionLoginModule,請使用 JAAS 登入架構,這個架構是在一個自訂登入模組中完成信任驗證,然後在 IdentityAssertionLoginModule 中將認證建立完成。 您可以利用兩個登入模組來建立可用來主張身分的 JAAS 登入配置。
    需要的自訂登入模組有兩個如下:
    使用者實作的登入模組(信任驗證)
    使用者實作的登入模組會執行使用者在信任驗證中所需要的任何動作。 當進行信任驗證時,必須將信任驗證狀態和登入身分放在登入模組共用狀態的一項對映中,以便建立認證的登入模組能夠使用這項資訊。 這項對映儲存在下列內容中:
    com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.state
    這個內容由下列內容組成:
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.trusted
      如果信任,這個內容就設為 true,否則設為 false
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.principal
      這個內容包含身分主體。
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.certificates
      這個內容包含身分的憑證。
    身分主張登入模組(建立認證)
    下列模組會建立認證:
    com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule
    這個模組有賴於在登入環境定義共用狀態中的信任狀態資訊。
    身分主張登入模組會在共用狀態內容中尋找信任資訊:
    com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.state
    這個內容包含信任狀態及要登入的身分,且必須包括下列內容:
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.trusted
      當信任時,這個內容設為 true,否則設為 false
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.principal
      如果使用主體,這個內容包含要登入的身分主體。
    • com.ibm.wsspi.security.common.auth.module.IdentityAssertionLoginModule.certificates
      如果使用憑證,這個內容包含一個憑證鏈陣列,憑證鏈含有要登入的身分。

    如果遺漏狀態、信任或身分資訊,會傳回 WSLoginFailedException 訊息。 之後,登入模組會以這個身分登入,主體會包含新的身分。

    請參閱 利用 JAAS 自訂應用程式登入來執行身分主張

RunAs() 鑑別

當您在呼叫 Servlet 之後鑑別成功,Servlet 可以進行後續的呼叫,例如呼叫其他 Servlet。 這些後續的呼叫通常是利用您原來登入 Servlet 時所用的相同安全身分來發出。 這個身分稱為呼叫端身分。 另外,您也可以選擇利用 RunAs 規格來委派給不同的身分,以便 Servlet 所發出的任何後續呼叫都會利用這個其他身分來執行。 總而言之,您有兩個選項可以傳播安全身分:
  • 延伸呼叫端身分,這是預設行為。
  • 委派給您可以利用 RunAs 規格來指定的執行身分。

伺服器鑑別原始使用者之後,伺服器會鑑別 RunAs 使用者。 如果這個鑑別失敗,伺服器會進行撤回,以傳播呼叫端身分。

如果要使用 RunAs 規格,您必須更新您應用程式的部署描述子,以併入 run-as 元素或 @RunAs 註釋。 請將這個元素設為您想要委派給它的安全角色。

請參閱 在 Liberty 中配置 RunAs 鑑別

Proxy 登入模組

Proxy 登入模組類別會載入應用程式伺服器登入模組,且會將所有作業委派給實際的登入模組實作。 在選項配置中,實際的登入模組實作是指定為委派選項。 Proxy 登入模組是必要的,因為應用程式類別載入器看不到應用程式伺服器產品的共用程式庫類別載入器。 當應用程式的程式化登入會搭配 JAAS 登入環境定義項目 WSLogin 來使用 LoginContext 類別的 Login() 方法時,Proxy 登入模組會將所有工作都委派給 JAAS 登入環境定義項目 system.DEFAULT。

憑證登入

當使用憑證登入特性時,您可以利用用戶端 X509 憑證來鑑別 Servlet 之類的 Web 要求,而不是提供使用者 ID 和密碼來鑑別。

憑證鑑別的運作方式,是將使用者登錄中的使用者關聯於 Web 要求之用戶端憑證中的識別名稱。 信任關係的建立在於擁有伺服器所信任的用戶端憑證,例如,用戶端憑證的簽章者必須在伺服器的信任儲存庫中。在這個機制之下,使用者不需要提供密碼來建立信任關係。

請參閱 利用 Liberty 來維護通訊安全

雜湊表登入模組

請從使用者登錄中查閱必要的屬性,將屬性放在雜湊表中,然後將雜湊表新增到共用狀態中。 如果在這個登入模組中切換了身分,您必須將雜湊表新增到共用狀態中。 如果沒有切換身分,但 requiresLogin 代碼值是 true,您可以建立屬性雜湊表。 在這個狀況中,您不需要建立雜湊表,因為 Liberty 會處理您的登入。不過,在特殊情況下,您可能需要考慮建立一份雜湊表來收集屬性。 比方說,如果您使用自己的特殊使用者登錄,則建立 UserRegistry 實作,使用雜湊表並讓伺服器為您收集使用者屬性,可能是一個簡單的解決方案。

下列規則詳細定義完成雜湊表登入的方式。 您必須在「主體」(公用或專用認證集)或共用狀態 HashMap 中,使用 java.util.Hashtable 物件。 com.ibm.wsspi.security.token.AttributeNameConstants 類別定義包含使用者資訊的索引鍵。 如果利用列在雜湊表登入模組之前的自訂登入模組,使 Hashtable 物件進入登入環境定義的共用狀態中,就會利用共用狀態 hashMap 內的下列索引鍵來搜尋 java.util.Hashtable 物件的值:

內容
com.ibm.wsspi.security.cred.propertiesObject
內容的參照
AttributeNameConstants.WSCREDENTIAL_PROPERTIES_KEY
說明
這個索引鍵會在登入環境定義的共用狀態中,搜尋包含必要內容的 Hashtable 物件。
預期的結果
java.util.Hashtable 物件。

如果在「主題」或共用狀態區域內找到 java.util.Hashtable 物件,請驗證在雜湊表中,下列內容是否存在:

  • com.ibm.wsspi.security.cred.uniqueId
    內容的參照
    AttributeNameConstants.WSCREDENTIAL_UNIQUEID
    傳回
    java.util.String
    說明
    內容的值必須是使用者的唯一表示法。如果是 Liberty 預設實作,這個內容代表儲存在應用程式授權配置中的資訊。在部署之後及執行使用者至角色的對映之後,這項資訊會在應用程式部署描述子中。 如果查閱 Liberty 的使用者登錄實作來執行使用者至角色的對映,請參閱預期的格式範例。
    預期的格式範例
    表 1. uniqueId 的格式範例. 這份表格提供預期的格式範例。
    使用者登錄 格式 (UniqueUserId) 值
    LDAP ldapRegistryRealm/cn=kevin,o=mycompany,c=use
    基本 basicRegistryRealm/kelvin
    需要 com.ibm.wsspi.security.cred.uniqueId 內容。
  • com.ibm.wsspi.security.cred.securityName
    內容的參照
    AttributeNameConstants。WSCREDENTIAL_ SECURITYNAME
    傳回
    java.util.String
    說明
    這個內容會搜尋鑑別使用者的 securityName。 這個名稱通常稱為顯示名稱或簡稱。 Liberty 會將 securityName 屬性用於 getRemoteUsergetUserPrincipalgetCallerPrincipal 應用程式設計介面 (API)。如果要確保能夠與預設實作的 securityName 值相容,請呼叫 public String getUserSecurityName(String uniqueUserId) UserRegistry 方法。
    預期的格式範例
    表 2. securityName 的格式範例. 這份表格提供預期的格式範例。
    使用者登錄 格式 (securityName) 值
    LDAP kevin
    基本 kevin
    需要 com.ibm.wsspi.security.cred.securityname 內容。
  • com.ibm.wsspi.security.cred.group
    內容的參照
    AttributeNameConstants。WSCREDENTIAL_GROUP
    傳回
    java.util.ArrayList
    說明
    這個索引鍵會搜尋使用者隸屬之群組的陣列清單。 群組是以 realm_name/user_name 格式指定。 這些群組的格式很重要,因為在部署描述子中,Liberty 授權引擎會利用群組來進行群組至角色的對映。提供的格式必須符合 Liberty 預設實作預期的格式。當您使用協力廠商授權提供者時,則必須使用協力廠商提供者所預期的格式。 如果要確保能夠與唯一群組 ID 值的預設實作相容,請呼叫 public List getUniqueGroupIds(String uniqueUserId) UserRegistry 方法。
    預期的格式範例
    表 3. 群組的格式範例. 本表提供一些格式範例,用於配置入埠身分對映。
    使用者登錄 格式 (group) 值
    LDAP ldapRegistryRealm/cn=group1,o=Groups,c=US
    基本 basicRegistryRealm/group1
    需要 com.ibm.wsspi.security.cred.group 內容。 使用者不需要具有相關聯的群組。
  • [16.0.0.3 以及更新版本]com.ibm.wsspi.security.cred.realm
    內容的參照
    AttributeNameConstants。WSCREDENTIAL_REALM
    傳回
    java.util.String
    說明
    這個索引鍵內容可以指定儲存在 LTPA Cookie 中的使用者登錄網域範圍名稱。
    這個索引鍵內容不是必要的。
  • com.ibm.wsspi.security.cred.cacheKey
    內容的參照
    AttributeNameConstants。WSCREDENTIAL_CACHE_KEY
    傳回
    java.lang.Object
    說明
    這個索引鍵內容可指定一個物件來代表登入的唯一內容,這包括使用者特定的資訊,以及會影響唯一性的使用者動態屬性。例如,當使用者從位置 A 登入時,可能會影響其存取控制,快取索引鍵必須包含位置 A,使接收到的「主體」是現行位置的正確「主體」。
    這個 com.ibm.wsspi.security.cred.cacheKey 內容並非必要。 如果未指定這個內容,快取查閱就是對 WSCREDENTIAL_UNIQUEID 指定的值。 當在 java.util.Hashtable 物件中找到這個資訊時,Liberty 會建立一個「主體」,它類似於透過一般登入程序的「主體」,至少對 LTPA 而言是如此。這個新「主體」包含一個 WSCredential 物件,以及一個其中已完全移入在 Hashtable 物件中找到之資訊的 WSPrincipal 物件。

指示主題類型的圖示 概念主題



「時間戳記」圖示 前次更新: 2016 年 11 月 30 日
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwlp_authentication
檔名:cwlp_authentication.html