shibboleth vs those "other" idps

Cantor, Scott cantor.2 at
Thu May 14 14:07:33 EDT 2015

On 5/14/15, 12:37 PM, "Rob Gorrell" <rwgorrel at> wrote:
>What I'm being asked more and more these days is to justify the choice of staying with shibb being that it is largely centered around SAML (and CAS thanks to v3.0). That if we were to pick one these others that support the long list of integrations, we could onboard more services without having to evangelize SAML.

Any examples? I'd be curious.

The real issue I see, that I think we all see, is that vendors aren't deploying anything in a rational, scaleable way, and that's a protocol-independent issue (I have news for anybody who thinks OIC will fix that). I find it somewhat funny that the solution to vendors doing a bad job is to go find another vendor, but that's life I guess.

>So I was hoping you guys might be able to help me collect and organize my thoughts on what sets the shibb IdP aside from the growing number of generic players that have joined the game. What principally does shibb do very well that the others don't?

I don't know that I could contribute anything very effectively to that conversation, but I'll just note that a lot of those products that are also supporting SAML are doing it with our code, and many of them haven't contributed a line of code or any support. (The exceptions to that are of course thanked.)

>I think most of the argument evolves around the word "federation" and metadata management, but I figure I'd ask those much more knowledgeable about the subject to arm me with a little more ammo than I'm carrying today.

I think we have almost the only federation software with a well-defined security model. A lot of the rest couldn't actually tell you what their code will do in specific situations if you asked, and I guess I find that pretty odd in a security product, but that sort of thing doesn't really sell.

Mostly I guess I would point to attention to detail, standards compliance, protocol expertise, level of technical support, and actual commitment to advancing a technology and not just surface adoption. Most of that doesn't sell very well in comparison to GUIs, and unfortunately though GUIs don't scale, neither to vendor approaches to federation, so it's unsurprising they fit well.

I would not, of course, point to documentation on that list.

-- Scott

More information about the users mailing list