认证的烦恼
小明的公司有很多IT系统， 比如邮箱、SVN、Jenkins , JIRA,VPN, WIFI...... 等等 。
新人入职时需要在每个系统中申请一遍账号，每个系统对用户名和密码的要求还不一样， 实在是烦人。
这还不算， 按照公司的策略， 这些密码每隔三个月还得更改一次，每次都是一次大折腾。
离职的时候， 各个账号又都得删除一遍，太折磨了。
能不能让这些系统用同一套用户名和密码呢？ 申请一次，到处使用！
“嗯，这其实是一个用户统一认证的问题” 小明做了一个总结。
怎么去实现？ 当然是开发一套系统了， 关键是要把账号统一起来用Mysql 数据库来保管， 然后用自己擅长的SpringMVC对外提供JSON接口， 别的系统比如SVN想做用户认证的时候，调用一下这个接口，把用户名和密码传过来，系统就会判断认证是否成功。
被这么一个美好的前景激励着，小明像打了鸡血，充满激情地、迅速地把这个系统开发出来了。
2
推广
他先找了SVN的管理员，结果栽了跟头，人家根本不买账，理由很简单： “你这个系统稳定性、性能怎么样？ 还有，你这接口是自己定义的，也不是业界标准，我甚至得开发代码和你做集成， 太麻烦。 对了， 你怎么不用LDAP啊？”
LDAP ? 这是什么鬼？ 小明没放在心上， 又去找邮箱和VPN的负责人， 都被残忍地拒绝了， 甚至连理由都一样。
最后的希望集中在Jenkins身上， 管理Jenkins的是自己的哥们张大胖， 中午吃饭的时候小明向基友哭诉了自己的悲惨遭遇，希望能博得一点同情。
“我觉得你的想法很好啊，我们就缺你这样的实干家， 你说说接口是什么样的？” 大胖路见不平，决定为好基友两肋插刀。
“其实我这里提供了一个HTTP+JSON的接口， 你的Jenkins调用一下就行了” 小明满怀期望。
“这个.... 虽然我没有仔细研究过， 但是Jenkins 好像只支持自定义的用户认证，还没有LDAP。” 大胖的刀还没拔出来就放回去了。
看来推广又要失败了。
3
LDAP
“这个LDAP是什么东西，你们的系统为什么都要支持它？” 小明愤愤不平地问道。
“LDAP是Lightweight Directory Access Protocol ， 即轻量级目录访问协议， 用这个协议可以访问提供目录服务的产品，例如OpenLDAP。 ”
“目录服务？”
“对， 比如公司有个员工列表名单， 对于一个员工，你能查到他的电话，工位，部门等各种信息， 这就是一个目录啊。”
“听起来很适合保存一个公司员工的账号和密码啊” 小明说。
“是啊，这个目录服务啊，存储数据的方式有点特殊，完全不像我们熟知的关系数据库， 数据都在表中，一行一行的，一目了然，这个OpenLDAP是以树的方式存储的。 比如一个人的信息是这样的：
小明说：“ 有点古怪，不过这很像文件系统的目录树， 每个目录都有属性，可以存储信息，比如用户名和秘密，但是查询的时候还得一层一层的来，多麻烦， 为啥不用关系型数据库，直接一个select 不就出来了 ”
张大胖说： “我对LDAP研究不深， 但是我知道LDAP速度快， 非常快，比当今最快的数据库还要快。“
“怎么可能，现在的关系数据库多强悍啊。”
“其实LDAP主要的应用场景是查询多而修改极少，查询和修改的比率是10:1 甚至更高， 那就充分发挥LDAP的优势了，因为没有事务处理，那数据库的速度可是比不上。 还有LDAP能存储海量的数据，还可以轻松地在各个系统之间复制，可用性超高。 ”
小明想想确实是这样，公司员工信息变化本来就很少，我们把用户名密码存进去， 三个月才改一次， 查询的操作远远高于修改，如果LDAP专注于优化查询，又没有事务处理， 就像一个缓存一样， 肯定要更快了， 怪不得很多软件都支持LDAP做用户认证，这是个重要原因啊。
小明有点沮丧，觉得自己在没有充分调查研究的情况下，又造了一个轮子。
既然如此，那就搭建一个支持LDAP的目录服务器吧， 小明这一次吸取了教训，先说服了领导，在领导的支持下，进行了跨部门的沟通，经过艰苦的努力，各个系统终于搞成了统一认证， 现在的结构是这样的：
小明的努力没有白费， 除了学到技术外，还得到了公司的认可，年底的时候给他发了一个领导力的奖，奖励他勇于走出自己的工作岗位、跨部门的与同事沟通，用自己的专业能力带来大家完成了用户的统一认证，极大提高了工作的效率。