在过去的几年里,我不得不"偶尔"与Heimdal/MIT Gssapi合作进行kerberos认证.我必须构建一个应用程序,用作在Linux机器上运行的Web服务,并提供运行在Windows和/或Linux桌面和工作站上的浏览器等客户端应用程序.当然不是最容易驯服的野兽.最后,在总结我的工作时,我可以记录由于多方面的挑战而产生的困难.开始使用gssapi编程确实是一个挑战,因为文档很差,并且实际上是不存在的教程.谷歌搜索通常会导致对什么是kerberos进行一些理论上的讨论,或者导致内容写成假设你已经知道除了某些特定的语义问题之外的所有内容.这里有一些非常好的黑客对我有所帮助,因此我认为从开发人员的角度总结这些东西是个好主意,并在这里分享它作为某种维基,给回到这个梦幻般的地方,和其他程序员.
以前没有真正做过像这样的维基,而且我肯定对GSSAPI和Kerberos没有权限,所以请善待,但更重要的是请贡献并纠正我的错误.网站编辑,我指望你做你的魔术;)
成功完成项目需要正确完成3项具体任务:
设置测试环境
设置您的库
你的代码
正如我已经说过的那样,这些项目都是野兽,因为这三个项目都没有放在同一个页面的任何地方.
好的,让我们从头开始吧.
新手 GSSAPI的不可避免的理论帮助客户端应用程序为服务器提供凭据以权威地识别用户.非常有用,因为服务器应用程序可以根据用户调整其服务响应.因此非常自然地 - 客户端和服务器应用程序必须是kerberized,或者有些人会说kerberos知道.
基于kerberos的身份验证要求客户端和服务器应用程序都是Kerberos领域的成员.KDC(Kerberos域控制器)是指定领域的指定权限.Microsoft的AD服务器是KDC中最受欢迎的示例之一,但您当然可以使用基于*NIX的KDC.但肯定没有KDC,根本就没有Kerberos业务.只要所有桌面,服务器和工作站都加入域中,它们就会相互识别.
对于您的初始实验,请在同一领域中设置客户端和服务器应用程序.虽然Kerberos身份验证肯定也可以通过在这些领域的KDC之间创建信任,甚至合并来自不相互信任的不同KDC的密钥记录来跨领域使用.您的代码实际上不需要任何更改来适应这种不同且复杂的场景.
Kerberos身份验证基本上通过"票证(或令牌)"工作.当一个成员加入这个领域时,KDC会向每个成员"授予令牌".这些代币是独一无二的; 时间和FQDN是这些门票的必要因素.
在你想到代码的第一行之前,请确保你有这两个权利:
陷阱#1在设置开发和测试环境时,请确保所有内容都经过测试并以FQDN进行寻址.例如,如果要检查连接,请使用FQDN而不是IP进行ping.因此,不用说,它们必须具有相同的DNS服务配置.
陷阱#2确保所有运行KDC,客户端软件,服务器软件的主机系统都具有相同的时间服务器.时间同步是一种忘记的东西,并且在经过大量的分裂和头撞之后意识到自己很不舒服!
两者,客户端和服务器应用程序都需要kerberos keytabs.因此,如果您的应用程序将在*NIX主机中运行,并且是Microsoft域的一部分,那么在我们开始查看gss编程的剩余准备步骤之前,您必须生成kerberos keytab.
Kerberos 5循序渐进指南(krb5 1.0)互操作性绝对必读.
GSS-API编程指南是一个很好的书签.
根据您的*NIX发行版,您可以安装用于构建代码的标头和库.我的建议是下载源代码并自行构建.是的,你可能不会一气呵成,但它肯定是值得的.
陷阱#3确保您的应用程序在Kerberos感知环境中运行.我真的很努力地学到了这一点,但也许是因为我不那么聪明.在我最初的gssapi编程斗争阶段,我发现kerberos keytabs对于让我的应用程序感知kerberos是绝对必要的.但我根本找不到任何关于如何在我的应用程序中加载这些keytabs.你知道为什么?!!因为没有这样的api !!! 因为:应用程序将在知道keytabs的环境中运行.好吧,让我这么简单:在将环境变量设置KRB5_KTNAME
为存储keytabs的路径之后,应该运行应该执行GSSAPI/Kerberos事务的应用程序.所以要么你做的事情如下:
export KRB5_KTNAME=
或者在运行使用gssapi的第一行代码之前充分setenv
设置KRB5_KTNAME
应用程序.
我们现在准备在应用程序的代码中执行必要的操作.
据我所知,应用程序开发人员必须审查其他许多方面,以编写和测试应用程序.我知道一些环境变量,这很重要.
任何人都可以对此有所了解吗?