忘掉Domino的认证吧，打造自己的认证系统

我们都知道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的认证，顺利访问基于这个平台上的业务应用。以上就是我们自己打造的认证系统工作的原理，还请各位读者看后提提自己的意见！