Kerberized authorization service

[John Hascall]

> >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).


John