我們都知道Domino服務器的認證是封閉不開放的，Domino系統都是通過定製開發的domcfg.nsf數據庫實現登錄界面。但其實大多數時候，我們想用自己的認證系統代替Domino平臺自己的。當然，這是不可實現的。不過，IBM還是提供了一個DSAPI接口，但它必須用C語言編寫。問題搞大了，幹嘛還必須用C語言啊？就不會編個Java 的接口嗎？發牢騷是沒用的，想別的轍吧！
山重水複疑無路，柳暗花明又一村！IBM在Domino平臺上沒有爲用戶提供認證接口，但是提供了TAM+TIM來實現與其他系統的集成訪問，但那東西不是要花錢嗎！Domino是提供SSO功能的，這也是我們可以利用的---開發出我們自己的認證系統。
對於SSO的概念，可能還有些人不太熟悉，沒關係，我這裏有篇文章，詳細講解了Domino服務器SSO的運行原理。《Domino單點登錄LTPAtoken生成原理》
既然是自己開發認證系統，就需要一個用戶數據庫。那選擇就多了，比如使用LDAP-典型 的就是AD服務器。或者用RDB數據，那就需要解決安全問題，比如密碼的加解密，系統的安全性和健壯性等等，需要解決的問題還是不少的。所以一般省事的做法就是採用第三方的LDAP。這麼做的好處也是顯而易見的，不需要花費很大的精力去解決安全，省了很多事情。假設我們採用微軟的AD服務器，那肯定就會有人提出了：可以採用DA（Direct Access）數據庫，用AD服務來代替Domino自己的認證。沒毛病！但是有個問題：利用AD服務器認證時，會返回用戶的DN（Distinguished Name），在Domino平臺上不好處理，想真正用起來還需要在names裏爲每一個用戶增加對應AD的DN，而且一般DN中都帶有OU的信息，那維護起來就是噩夢啊。如果不想修改names，那就只能修改AD端，增加新的屬性，用於存放names裏的用戶全名。那麼兩端如何同步就是要解決的最大問題了，當然現在都有解決方案，但不是文本的範圍了。
利用DA數據庫處理起來比較麻煩，我們有一個更好的處理方式。只需AD服務器，不用再做任何同步工作。
看上圖，我們的認證系統先訪問AD服務器，通過認證後返回用戶DN。由於AD域中的用戶DN一般都很長，而且帶有複雜的OU信息。但是在names中爲了方便管理，都將用戶註冊在根組織機構下，沒有用戶的組織單元(OU)信息，因此會造成AD用戶的DN過長，在Domino平臺上不好處理的情況。爲了使用方便，在取得AD服務器的用戶DN後，要將其裁剪爲在Domino中常用的根式。如果OU信息沒用也可以過濾掉這些信息，一切都要看實際的要求。然後使用Domino的SSO祕鑰將用戶信息加密後寫入Cookie中，攜帶Cookie訪問Domino，即可通過Domino的認證，順利訪問基於這個平臺上的業務應用。以上就是我們自己打造的認證系統工作的原理，還請各位讀者看後提提自己的意見！