On 2009-10-07 15:58, vadim marchenko wrote:
> Hi Alec,
>
> Thanks for the info.
> Have you had experience using either Http Negotiate or GSSAPI or both? If
> yes, can you share your main pain points with each/either?
>
> When I say robust, I mean there is backing by big industry leaders Sun, IBM,
> MS, Oracle and etc.
> You can evaluate and test products from big vendors. We have done testing of
> some of the products.
Kerberos/GSSAPI is well supported by Microsoft, MIT, Mozilla,
OpenSSH, Java, and anything that links against a SASL library, so I
wouldn't exactly say it's not industry supported. If your target
audience are Windows users (and their workstations are on an Active
Directory domain), they already have everything you need to do
Kerberized SSO. There shouldn't be any reason you can't
essentially do both. I know heimdal at least can use an arbitrary
LDAP server to store the kerberos keys in, which could be the same
LDAP server your cookie-based login system uses as well, so your
web-based cookies and kerberos keys would be in the same LDAP
server managed by the same account management tools. I guess my
point is that it should be possible to use these technologies
together. At least that's how I'd like to see it work.
> GSSAPI api has more mostly Kerberos implementations. I have been exposed to
> Kerberos at some point more than I bargained for.
> It has its own issues and is rather considered a cannon to use when when you
> all you want to do is sport hunting.
Yes, typically GSSAPI is used with Kerberos. I think your
observations about size of weapon vs task at hand applies to any
SSO solution when compared to a simple authentication scheme like
HTTP basic with a text file on the server.
> I have not dealt with Http Negotiate. I suspect a lot of implementations
> will require either use of Kerberos or NTLM.
> It probably requires additional research on my part.
I can save you some time; that's pretty much true, and with
mod_auth_kerb, all you get is Kerberos, no NTLM. I believe with
mod_auth_sspi, all you get is NTLM, no Kerberos.
> What I wonder is if there is a technical difficulty in adding support for
> cookies to subversion client.
> Everybody seems to shy away from the main question I asked.
Good point. The primary issue is that Subversion links in
third-party HTTP client libraries (either Neon or Serf). If you
want cookie support in Subversion you probably need to get cookie
support added to one of those libraries. I think there are other
problems with typical web/cookie authentication schemes and
Subversion... Subversion can't really render HTML to prompt a user
to log in so Subversion would need to get cookies from somewhere
else. It would be a little odd to have Subversion's HTTP client
library read the cookies from your web browser to log in.
--
Alec.Kloss_at_oracle.com Oracle Middleware
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x432B9956
- application/pgp-signature attachment: stored
Received on 2009-10-07 22:15:13 CEST