On 31 Jul 2011, at 06:07, Chris Hecker wrote: > 3. Set up and use kx509 so the services can get short term x.509 > certificates. This seems like the best one, but...is the kx509 project > still being developed? The public source code hasn't been touched since > 2005. This post talks about being wary of its code quality (at least, > KCT's quality): > > http://orthrus.blogspot.com/2007/10/kx509-kerberos-and-cosign.html
I wrote that. KCT is horrible. kx509 is nicer. We are still running kx509 locally, but it's increasingly a service in search of applications. At the moment all we use it for is getting client certificates for OpenVPN. Cosign has completely supplanted it for web authentication at most sites that I am aware of. kx509 does still have some traction - there is native support in Heimdal, for example, and Henry Hotz is working on specifying an improved version of the protocol. It's still probably not the best solution for this problem, though. > 4. Write a custom kerberized proxy for just the pages I need, services > make normal krb5 requests to that, and it runs on the webserver. Yuck. Yuck indeed. What we do is ... 5. Provide a Kerberos protected version of the cosign login CGI. This allows applications to authenticate using NegotiateAuth, get cosign cookies, and then continue onwards as a cosign'd service. We also provide this to users who are using supported browsers (mainly Firefox) on managed machines, so that we avoid the Web-Double-Signon problem. I blogged about this in 2007 - http://orthrus.blogspot.com/2007/10/kx509-kerberos-and-cosign.html Hope that helps! Cheers, Simon. ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ Cosign-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cosign-discuss
