> >Recently, I had a couple of my student employees work up a
> >proof-of-concept using SAML (with a kerb auth as part of the payload)
> >as the protocol -- since SAML seems like a more likely future direction
> >for a standardized auth protocol than something I threw together one
> >night in 1990

> I am not that sure, actually. Every time I look at SAML, I re-remember
> my biggest issue with it - the spec is frickin' huge (379 pages for all
> of the documents for SAML 2.0). Also, it's rather "webby" ... I mean,
> the protocol is based on HTTP? You need an XML library? And it seems
> that you probably need SOAP in there as well. Every example I've seen
> of it clearly is web-oriented. I guess I see the advantage to using
> it when you have an already-bloated web server, but cramming all of
> that into sshd? Ugh.
> Okay, you'll bring up points about code reuse, complying with a
> standard, having someone else design the protocol, etc etc ... yeah, I
> don't disagree with you on all that. But it just seems like a whole
> mess of baggage you're getting when a home-grown protocol will be
> simpler to understand, easier to maintain, and overall less work.

Yes, SAML is a really big ugly pig, XML is a big really ugly pig, and
SOAP is the answer to pretty much only "Every port but 80 is blocked,
so I do I turn HTTP into a poor re-implementation of TCP" And, I think
my students wanted to choke me because it is all so web-centric (at least
in all the examples and existing uses they could find).
Plus the kind of people who love it also seem to love building
monstrous edifaces of java (*cough* shibboleth and friends *cough*).

But, in the end, by using the gsoap lib it turned out to be not that
much code and most of their work was spent figuring out how to cram a
kerberos authenticator into the thing (as it was clearly designed
by people who are certificate-happy).