企業的資訊化過程是一個循序漸進的過程，在企業各個業務網站逐步建設的過程中，根據各種業務資訊水平的需要構建了相應的應用系統，由於這些應用系統一般是在不同的時期開發完成的，各應用系統由於功能側重、設計方法和開發技術都有所不同，也就形成了各自獨立的使用者庫和使用者認證體系。
隨著新的業務網站不斷的增加，使用者在每個應用系統中都有獨立的賬號，這樣就造成在訪問不同的應用系統時，需要記錄對應的使用者名稱和密碼，多個使用者名稱密碼極易記混，如果忘記或記錯了某一個業務網站的使用者名稱或密碼就無法進行登入，耽誤工作，影響工作效率，隨著局內資訊化程式的推進還會有新的應用系統產生，如果不引入單一使用者登入的解決方案，全公司工作人名特別是承擔審批許可權的各級領導很難記清各類應用系統的使用者名稱和密碼，嚴重影響由資訊化帶來快捷性和高效性。此外，多個應用平臺就有多個使用者管理，這也為系統管理員維護人員系統帶來巨大的工作量，例如，一次變更10個人員，即使只有5個應用系統，也需要重複維護50個人員資訊，而企業的每次人員調整遠不至10人，這種幾何增長的維護工作量，會浪費大量的精力和時間，減弱了資訊化系統帶來方便快捷，為此，需建立一套統一的、完善的、科學的單點登入系統，每個使用者只需記錄一個使用者名稱密碼，登入一個平臺後即可實現各應用系統的透明跳轉，而且實行統一的使用者資訊管理系統，系統管理員只需維護一套人員資訊，更改資訊通過平臺介面同步更新至各個應用系統，實現人員系統單次維護全公司同步變更，大大提高工作效率。
新的應用系統在不斷開發，早一天規劃設計出單點登入的規範介面，就可以為新開發的系統提出的一種整合的標準，在開發初期無論哪個開發商，無論採用哪種技術開發，只要遵循單點登入的規範標準，新的系統開發完成之後即可無縫整合的到單點登入平臺中，從而減少了系統開發完成後再整合到單點登入改動而造成資源的浪費。
從資訊共享角度看現有的各個業務系統都使用各自的資料儲存方式，不經過基礎的使用者名稱和密碼認證後，相互之間無法傳遞有效資訊。為避免資訊孤島的產生，因此需要建立一個連線各個業務系統的技術架構和標準，實現平臺統一化整合；通過對業務處理和異常處理實現監管透明；通過將業務流程從應用中抽離，實現業務流程的靈活安排，這樣就需要一套可以整合現有各個業務網站的資訊共享平臺。
單點登入的英文名稱為Single Sign-On，簡寫為SSO，它是一個使用者認證的過程，允許使用者一次性進行認證之後，就訪問系統中不同的應用；而不需要訪問每個應用時，都重新輸入密碼。IBM對SSO有一個形象的解釋“單點登入、全網漫遊”。
SSO將一個企業內部所有域中的使用者登入和使用者帳號管理集中到一起，SSO的好處顯而易見：
- 減少使用者在不同系統中登入耗費的時間，減少使用者登入出錯的可能性
- 實現安全的同時避免了處理和儲存多套系統使用者的認證資訊
- 減少了系統管理員增加、刪除使用者和修改使用者許可權的時間
- 增加了安全性：系統管理員有了更好的方法管理使用者，包括可以通過直接禁止和刪除使用者來取消該使用者對所有系統資源的訪問許可權
對於內部有多種應用系統的企業來說，單點登入的效果是十分明顯的。很多國際上的企業已經將單點登入作為系統設計的基本功能之一。
公司第一個版本的單點登陸系統從2005年執行以來，從幾十個應用系統擴充套件到現在的幾百個系統。在應用的過程中沒有很好的解決跨域名的問題，單點登陸客戶端程式碼使用問題，應用系統的訪問規則問題等都沒有很好的解決。
SSO的實現機制不盡相同，大體分為Cookie機制和Session機制兩大類。
- WebLogic通過Session共享認證資訊。Session是一種伺服器端機制，當客戶端訪問伺服器時，伺服器為客戶端建立一個惟一的SessionID，以使在整個互動過程中始終保持狀態，而互動的資訊則可由應用自行指定，因此用Session方式實現SSO，不能在多個瀏覽器之間實現單點登入，但卻可以跨域。
- WebSphere通過Cookie記錄認證資訊。Cookie是一種客戶端機制，它儲存的內容主要包括: 名字、值、過期時間、路徑和域，路徑與域合在一起就構成了Cookie的作用範圍，因此用Cookie方式可實現SSO，但域名必須相同。
目前大部分SSO產品採用的是Cookie機制，公司第一個版本的單點登陸系統也是如此，目前能夠找到的最好的開源單點登入產品CAS也是採用Cookie機制。 CAShttp://www.ja-sig.org/products/cas/，CAS單點登入系統最早由耶魯大學開發。2004年12月，CAS成為JA-SIG中的一個專案。JA-SIG的全稱是Java Architectures Special Interest Group，是在高校中推廣和探討基於Java的開源技術的一個組織。CAS的優點很多，例如設計理念先進、體系結構合理、配置簡單、客戶端支援廣泛、技術成熟等等。這也是我們這次SSO改造的參照產品。
以CAS為例，使用Cookie實現單點登入的原理圖如圖1所示。
- 首先，單點登入分為“服務端”和“客戶端”。服務端就是單點登入伺服器，而客戶端通常是“函式庫”或者“外掛”。需要使用單點登入的應用程式，需要把客戶端外掛安裝到自己的系統中，或者將客戶端函式庫包括在程式碼中。單點登入的客戶端通常替換了原來應用程式的認證部分的程式碼。
- 某個應用程式首先要發起第1次認證。大部分情況下，應用程式中嵌入的客戶端會把應用程式原來的登入畫面遮蔽掉，而直接轉到單點登入伺服器的登入頁面。
圖 1 使用Cookie實現單點登入的原理圖
- 使用者在單點登入伺服器的登入頁面中，輸入使用者名稱和密碼。
- 然後單點登入伺服器會對使用者名稱和密碼進行認證。認證本身並不是單點登入伺服器的功能，因此，通常會引入某種認證機制。認證機制可以有很多種，例如自己寫一個認證程式，或者使用一些標準的認證方法，例如LDAP或者資料庫等等。在大多數情況下，會使用LDAP進行認證。這是因為LDAP在處理使用者登入方面，有很多獨特的優勢，這在本文的後面還會比較詳細地進行介紹。
- 認證通過之後，單點登入伺服器會和應用程式進行一個比較複雜的互動，這通常是某種授權機制。CAS使用的是所謂的Ticket。具體這點後面還會介紹。
- 授權完成後，CAS把頁面重定向，回到Web應用。Web應用此時就完成了成功的登入（當然這也是單點登入的客戶端，根據返回的Ticket資訊進行判斷成功的）。
- 然後單點登入伺服器會在客戶端建立一個Cookie。注意，是在使用者的客戶端，而不是服務端建立一個Cookie。這個Cookie是一個加密的Cookie，其中儲存了使用者登入的資訊。
- 如果使用者此時希望進入其他Web應用程式，則安裝在這些應用程式中的單點登入客戶端，首先仍然會重定向到CAS伺服器。不過此時CAS伺服器不再要求使用者輸入使用者名稱和密碼，而是首先自動尋找Cookie，根據Cookie中儲存的資訊，進行登入。登入之後，CAS重定向回到使用者的應用程式。
這樣，就不再需要使用者繼續輸入使用者名稱和密碼，從而實現了單點登入。
注意，這種單點登入體系中，並沒有通過http進行密碼的傳遞（但是有使用者名稱的傳遞），因此是十分安全的。
CAS被設計為一個獨立的Web應用，目前是通過若干個Java servlets來實現的。CAS必須執行在支援SSL的web伺服器至上。應用程式可以通過三個URL路徑來使用CAS，分別是登入URL（login URL），校驗URL（validation URL）和登出URL（logout URL）。
- 應用程式一開始，通常跳過原來的登陸介面，而直接轉向CAS自帶的登入介面。當然也可以在應用程式的主介面上增加一個登入之類的按鈕，來完成跳轉工作。
- 如果使用者喜歡的話，也可以手工直接進入CAS的登入介面，先進行登入，在啟動其他的應用程式。不過這種模式主要用於測試環境。
- CAS的登入介面處理所謂的“主體認證”。它要求使用者輸入使用者名稱和密碼，就像普通的登入介面一樣。
- 主體認證時，CAS獲取使用者名稱和密碼，然後通過某種認證機制進行認證。通常認證機制是LDAP。
- 為了進行以後的單點登入，CAS向瀏覽器送回一個所謂的“記憶體cookie”。這種cookie並不是真的儲存在記憶體中，而只是瀏覽器一關閉，cookie就自動過期。這個cookie稱為“ticket-granting cookie”，用來表明使用者已經成功地登入。
- 認證成功後，CAS伺服器建立一個很長的、隨機生成的字串，稱為“Ticket”。隨後，CAS將這個ticket和成功登入的使用者，以及服務聯絡在一起。這個ticket是一次性使用的一種憑證，它只對登入成功的使用者及其服務使用一次。使用過以後立刻失效。
- 主體認證完成後，CAS將使用者的瀏覽器重定向，回到原來的應用。CAS客戶端，在從應用轉向CAS的時候，同時也會記錄原始的URL，因此CAS知道誰在呼叫自己。CAS重定向的時候，將ticket作為一個引數傳遞回去。
- 例如原始應用的網址是http://www.itil.com/，在這個網址上，一開始有如下語句，轉向CAS伺服器的單點登入頁面https://secure.oa.com/cas/login?service=http://www.itil.com/auth.aspx。
- CAS完成主體認證後，會使用下面URL進行重定向http://www.itil.com/authenticate.aspx?ticket= ST-2-7FahVdQ0rYdQxHFBIkKgfYCrcoSHRTsFZ2w-20。
- 收到ticket之後，應用程式需要驗證ticket。這是通過將ticket 傳遞給一個校驗URL來實現的。校驗URL也是CAS伺服器提供的。
- CAS通過校驗路徑獲得了ticket之後，通過內部的資料庫對其進行判斷。如果判斷是有效性，則返回一個NetID給應用程式。
- 隨後CAS將ticket作廢，並且在客戶端留下一個cookie。
- 以後其他應用程式就使用這個cookie進行認證（當然通過CAS的客戶端），而不再需要輸入使用者名稱和密碼。
採用.NET 來實現CAS原理的SSO系統，在第一個版本的SSO系統基礎上羅列一些問題，有的已經是第一個版本的SSO系統中採用的方式。有些問題需要澄清的，
很多人談論單點登入時，常常和統一使用者，以及單一使用者管理混淆了，要麼誤認為單點登入自然實現了單一使用者管理；要麼誤認為統一使用者或者單一使用者管理就是單點登入。實際上，這三個概念是有明確的區別的。
統一使用者就是指不同的系統，使用同一套使用者處理的機制。
- 使用者ID全域性惟一，使用者登入名，密碼全域性唯一，並且統一儲存在單一系統中。
- 使用者的一些屬性，如姓名、電話、地址、郵件等，統一儲存在單一系統中。儘管各應用系統還可以自行增加一些屬性，但是基本的屬性應該統一儲存和管理。
- 應用系統不應該直接對使用者資訊的進行增加、修改和刪除，但是可以進行查詢。對使用者資訊的增加、修改和刪除，應該由專門的系統進行統一的管理。
很顯然，統一使用者是單點登入的基礎，但是統一使用者並不意味著實現了單點登入。
單一使用者管理則指所有的使用者管理工作都在唯一的地方進行處理，而每個應用程式不再保留自己的使用者管理功能。單一使用者管理和統一使用者管理的最大區別在於，統一使用者管理之後，每個應用程式仍然保留自己的使用者管理功能，用於額外的屬性設定；而單一使用者管理時，每個應用程式不再保留自己的使用者管理功能。
在企業應用場景下，所有的使用者資訊來自HR系統，HR系統中包含的戶資訊和部門資訊，同時這些資訊會存在於公司的活動目錄中。公司採用的是LDAP和資料庫連線方式相結合,正式員工登陸OA系統並不採用LDAP方式認證，採用的RSA的token方式認證，也就是資料庫方式認證。對於忘記帶token卡和客戶服務部的外聘人員沒有token卡的，通過白名單方式允許他們通過LDAP方式認證。第一個版本的單點登陸系統使用的HTTP，新版本的整合子系統使用https方式通訊。
術語解釋：
- HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容請看SSL。它是一個URI scheme（抽象識別符號體系），句法類同http:體系。用於安全的HTTP資料傳輸。https:URL表明它使用了HTTP，但HTTPS存在不同於HTTP的預設埠及一個加密/身份驗證層（在HTTP與TCP之間）。這個系統的最初研發由網景公司進行，提供了身份驗證與加密通訊方法，現在它被廣泛用於全球資訊網上安全敏感的通訊。
- LDAP（全稱是Lightweight Directory Access Protocol），一般都簡稱為LDAP。它是基於X.500標準的，但是簡單多了並且可以根據需要定製。與X.500不同，LDAP支援TCP/IP，這對訪問Internet是必須的。LDAP的核心規範在RFC中都有定義，所有與LDAP相關的RFC都可以在LDAPman RFC網頁中找到。
簡單說來，LDAP是一個得到關於人或者資源的集中、靜態資料的快速方式。LDAP協議是跨平臺的和標準的協議，因此應用程式就不用為LDAP目錄放在什麼樣的伺服器上操心了。實際上，LDAP得到了業界的廣泛認可，因為它是Internet的標準。產商都很願意在產品中加入對LDAP的支援，因為他們根本不用考慮另一端（客戶端或服務端）是怎麼樣的。LDAP伺服器可以是任何一個開發原始碼或商用的LDAP目錄伺服器（或者還可能是具有LDAP介面的關係型資料庫），因為可以用同樣的協議、客戶端連線軟體包和查詢命令與LDAP伺服器進行互動。