> >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 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
