shibboleth vs those "other" idps

[Bryan Wooten]

Ok, my cents.

Given SAML is a known standard and most SaaS vendors (SPs) support SAML more or less correctly, I think it is in a school's best interest is host its own IDP using Shib.

Hosted SAML IDP (Ping, Okta, Gluu) is not inexpensive, but having in house Shib  expertise is not free either.

Having said that, schools will always need in house talent to control, monitor, test, integrate SPs with the IDP (whether Shib or not). 

And here is the important part. Out sourced vendors are in no position to support ECP, MCB, Fedushare, LOA (Silver), etc. needed in a research / academic world.

One last thing. The support from Open Source Community surrounding Shib (and CAS) is at least equal to or superior to any commercial support contract.

These are just my personal opinions. 

-Bryan

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Thursday, May 14, 2015 12:08 PM
To: Shib Users
Subject: Re: shibboleth vs those "other" idps

On 5/14/15, 12:37 PM, "Rob Gorrell" <rwgorrel at uncg.edu> 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

-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net