On Wed, Oct 7, 2009 at 4:14 PM, Alec Kloss <alec.kloss_at_oracle.com> wrote:
> 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.
>
>
Full blown PKI management is not for the faint hearted. I am not talking
about ssh certificate authentication. I use it all the time. Clock
synchornization, network latency issues do not make Kerberos particularly
attractive for distributed SSO either. It would be wishful thinking to
consider it as such. I actually read through initial MIT manuscript and then
some later MS-tish incarnations of such. You say Active directory does it
right. Perhaps... Tell it to thousands of customers running linux. Yes, I
know there are Open LDAP, FDS and etc but I don't want to diverge with
discussion of these either.
> > 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.
>
>
To continue riding with this figure of speech, there are plenty of coookies
based solutions (SOAP, RESTfull or custom) that - like AK-47 - simply get
the job done not matter heat or cold. NASA spent millions in research to
invent a ballpark pen that would work in space when Russians brought
pensils.
This is a joke but there is a rationale to this.
> > 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.
>
>
I would love to save myself and everyione else time to find maitenance free
SSO solution. Infrastructure is simply a huge wasteful time sink. But
without it, you might be looking at more trouble down the road.
> > 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.
>
>
Yep we still are on that point. I believe neon lib had rudimentary cookies
support starting in 2001.
My last resort would be looking at the code and trying to work though a
little POC.
Definitely not the first time. Most likely not the last time:).
I was simply hoping that somebody in the group knew the answer to this or
have made a similar attempt
I must humbly appologize if I wasted people's time with my not very well
thought through comments.
Thanks,
Vadim
> --
> Alec.Kloss_at_oracle.com Oracle Middleware
> PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x432B9956
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2404764
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-08 03:40:03 CEST