Shibboleth Developers

["Scott Cantor" <>]

> Well, you already provide the first two so I'd say that's a good
> start.  We could use C (since MyProxy is C) but that's our problem.

For some people, only the scripting languages matter. If you approach this
problem from the middleware/infrastructure side, as I do, the code
integrates at a low level and so low level languages like C++ or Java (yes,
these people think it's low level) are appropriate.

If you view it as something applications have to do, things like PHP are
much more important. Java has very little traction outside of
enterprise/corporate development.

Depending on what you're trying to implement, the problem with supporting
the scripting languages is that XML code above just vanilla parsing is
non-existent. So one option is to glue stuff on top of existing C libraries,
otherwise you have a ton of work to do or you have to scrupulously avoid any
signing or encryption.

> SAML has way too much traction right now so a REST approach (which is
> what I think you're talking about) is probably not realistic.  That
> said, we expect to extend the Shib AuthN Request Profile slightly to
> accommodate our short-term needs.  That's an example of REST, isn't it?

Well, I'd be highly amused to see you square off with the REST guys arguing
that SAML has traction  ;-), but I think within a certain community (ours),
it does.

REST means a lot more than just parameter passing, but most of the people
claiming to support it seem to think that's all it is. That's certainly part
of it, but REST is really about addressing things with URLs and manipulating
those things with a set of 4 operations, GET, PUT, POST, DELETE. It's why I
tend to separate protocol behavior into distinct endpoints. I like URLs and
I like using them rather than burying distinctions underneath.

REST itself fundamentally is more about the argument that only a single RPC
abstraction is useful on a wide scale, whereas SOAP is exposed more as
object marshalling. The fact that SOAP is really just document exchange is
irrelevant because that's not how most people use it. It's CORBA/DCOM in
angle brackets. The angle brackets provide a layering of extensions that
wasn't possible before, but at the application level, nothing's changed.

All that aside, this isn't about REST, even though that's being used as a
red herring. Certainly SAML is not really very dependent on SOAP, I
handcranked the wrappers I needed for that in a day. It's about XML. But
saying XML is hard and unworkable as a data exchange format is not an
argument some people like to make, so they call it a REST argument instead.

I may sound like I'm being critical of their arguments, but I'm really not.
I think the state of libraries supporting XML standards is really awful, and
the libraries we have are bloated and inefficient. That doesn't serve the
cause of promoting data exchange with XML.

-- Scott