LDAP 實務:以資料庫作為成員儲存庫

使用 LDAP 伺服器作為成員儲存庫的實務之一,是建立一個新的 WebSphere Commerce 案例,並將其指定使用資料庫作為成員儲存庫。 當案例啟動和開始執行後,再切換為使用 LDAP 伺服器作為成員儲存庫。 在這個實務中,當 WebSphere Commerce 案例啟動並以資料庫作為成員儲存庫開始執行後, 您要透過架構管理程式,切換為使用 LDAP 伺服器作為成員儲存庫。

在這個實務中,您需要完成下列動作:

  1. 編輯 instancename.xml 檔,將 MigrateUsersFromWCSdb 選項設為開啟。
  2. 檢查 ORGENTITY 表格,確定 DN 直欄中有包含組織實體的正確值。 這些組織實體的登錄是由 WebSphere Commerce 建立在 LDAP 伺服器上,在建立登錄時,會使用 DN 值。 因此,您必須先決定好這些組織實體的 DN 值,並確定 DN 值有移入 ORGENTITY 表格中。
  3. 建立 LDAP 伺服器中需要的字尾。WebSphere Commerce 將要使用和建立的使用者和組織實體登錄都會儲存在這些字尾之下。
  4. 設定 ldapentry.xml 檔,將 WebSphere Commerce 屬性映射至 LDAP 屬性。 同時,以 LDAP 伺服器上的 wcsadmin 項目的 DN,更新 USERS 表格中的 DN 直欄,以及 USERREG 表格中的 LOGONID 直欄。 移除 DN 值中,介於分隔字元之間的不必要空格。如果 LOGONID 直欄不足以容納整個 DN 值,則會將值截斷,使其可填入直欄中。比方說,如果您在 LDAP 伺服器上建立了 wcsadmin 項目,此項目的 DN 值為 'uid=wcsadmin,o=IBM,o=Root Organization,c=US',您要將此 DN 值放置在 DN 直欄和 LOGONID 直欄中。
  5. 在切換為使用 LDAP 伺服器後,當使用者登入時,WebSphere Commerce 就會使用 LDAP 伺服器來鑑別使用者。由於您是從資料庫切換為 LDAP 伺服器(亦即,MigrateUsersFromWCSdb 選項為 ON),如果和 LDAP 伺服器鑑別失敗,則會再次嘗試使用 USERREG 表格來鑑別使用者。

注意,在切換為使用 LDAP 伺服器後,存在 WebSphere Commerce 資料庫中的使用者和組織實體都會自動「移轉」到 LDAP 伺服器上。 您並不需要手動從 WebSphere Commerce 資料庫移轉任何登錄到 LDAP 伺服器上。 不過,除了上述的準備工作清單外,視您希望使用者如何登入而定, 可能會有不同的限制和一些額外的設定工作要做。 當您決定您希望您的使用者如何登入時,有三種方式可以考慮。 在現行 WebSphere Commerce 版本中,如果是使用 LDAP 伺服器, 使用者可以使用他們的 DN 值或 RDN 值登入。如果使用 RDN,將會使用搜尋基底來找出使用者, 接著再執行鑑別。如果在搜尋期間找到多個使用者登錄,則會產生錯誤。 搜尋基底是在 ldapentry.xml 檔中指定。

在以下的說明中,「DB 使用者」是指存在 WebSphere Commerce 資料庫中的使用者, 且在您切換為使用目錄伺服器後,會由 WebSphere Commerce 自動「移轉」到目錄伺服器上。 如果您是在剛啟動和執行 WebSphere Commerce 案例後就切換為使用目錄伺服器, 就不會有太多「DB 使用者」存在。「DS 使用者」是指由 WebSphere Commerce 以外的其它應用程式建立在目錄伺服器中,且會登入 WebSphere Commerce 的使用者。 同時,您的目錄伺服器中也會有一些使用者登錄存在,但那些使用者卻可能永遠不會登入 WebSphere Commerce,在這種情況下,WebSphere Commerce 就不會辨識他們。

方法 A
您希望您的 DB 使用者以他們的 RDN 值(亦即,在您切換為使用目錄伺服器之前, 他們的 LogonId 值)登入,而 DS 使用者以他們的 DN 值登入。

這個方法表示 DB 使用者和 DS 使用者可以延用他們原來的 RDN 值和 LogonId 值。 例如,有一個 DB 使用者的 LogonId 是 'Abe',DS 使用者的 DN 是 'uid=Abe,ou=DeptA,ou=DivB,o=CompanyC,c=CA'。

您需要在 ldapentry.xml 檔中設定搜尋基底,使 DS 使用者位於搜尋基底的範圍外。搜尋基底是在使用者以 RDN 登入時,用來搜尋該使用者。

方法 A 的優點是不需要有唯一的 RDN 值。缺點是部份使用者(DS 使用者)需要以 DN 登入。 不過,您的 DB 使用者則可以繼續使用 RDN 登入。

方法 B
您希望所有使用者都使用 RDN 登入。對於 DB 使用者而言,這表示他們可以繼續使用他們的 LogonId 值。對於 DS 使用者而言,這表示他們要使用 RDN 值登入。

這個方法表示位於您要 WebSphere Commerce 加以辨識的目錄伺服器上的所有使用者,都必須要有唯一的 RDN 值。

在切換為以目錄伺服器作為成員儲存庫之前,請務必先確定位於您要 WebSphere Commerce 加以辨識的目錄伺服器上的使用者,都具有唯一的 RDN 值,這個唯一性質不只是指 RDN 值,同時也包括 DB 使用者的 LogonId 值。 例如,有位使用者在您的目錄伺服器上的 RDN 值是 'Abe', 其他使用者就不能有相同的 RDN 值,且 DB 使用者的 LogonId 也不可以使用 'Abe'。如果有任何兩個使用者具有相同的 RDN 或 LogonId 值,其中一位必須做變更。

您需要在 ldapentry.xml 檔中設定搜尋基底, 以便可以找到透過 WebSphere Commerce 登入的所有使用者。

方法 B 的優點是使用者可以具有簡單語法(亦即,RDN 值)的字串登入。 其缺點是如果 DB 使用者或 DS 使用者的人數眾多時,要維護唯一的 RDN 值會變得極其困難。一般而言,要求唯一的 RDN 值不是很彈性化的解決方案。 如果您是在 WebSphere Commerce 案例已經開始執行一段期間後, 才切換為使用目錄伺服器,DB 使用者的人數可能會很龐大。 當目錄伺服器上建立愈來愈多的使用者,不論他們是不是透過 WebSphere Commerce 建立,都會導致 DS 使用者人數增多。

方法 C
您希望所有使用者都使用 DN 登入。對於 DB 使用者而言,這表示在您切換為使用目錄伺服器後, 他們要從原先以 LogonId 值登入方式,變更為以 DN 登入。

這個方法表示 DB 使用者和 DS 使用者可以延用他們原來的 RDN 值和 LogonId 值。 例如,有一個 DB 使用者的 LogonId 是 'Abe',DS 使用者的 DN 是 'uid=Abe,ou=DeptA,ou=DivB,o=CompanyC,c=CA'。

您必須要決定 DB 使用者的 DN 值。在此假設 DN 的 RDN 值是 DB 使用者在 USERREG 表格中的 LogonId 值。

在您切換為使用目錄伺服器後,您需要通知 DB 使用者,要求他們使用 DN 登入。

方法 C 的優點是不需要有唯一的 RDN 值。缺點是使用者需要以 DN 登入。

相關概念

相關作業

相關參照

IBM copyright