Non Incommon SPs

[Curry, Warren]

We had a case where the initial estimate by a vendor for one of the UF division was to charge them 11K  .

After a face to face meeting with the vendor , the division needing /purchasing the service and the IAM  office the amount came down to a ½ day charge for setup of some scripts and minor custom delta to the install script.    Total cost about $500.  Still seemed high but it was palatable.   The vendors are simply charging based on what they think you might pay based on gross overestimates of the time it takes to implement.    In fact it may even be simpler to implement in SAML in some cases.

Be tuff and don't just give your money away.    I had to help our people in the PPD division and ask the vendor direct question involving what they were being charged for.  First I had them admit the supported SAML authentication.   I then followed then what will you be doing for several days of extra install and service fees.  Can we see the list of tasks to be done  in addition to the tasks you will not need to do for an LDAP based install.    They in this case relented and got reasonable.    I was not convinced they needed to charge anything but we moved them from $11,000 to $500.

Stay the course..

Warren

From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Michael Hodges
Sent: Tuesday, July 17, 2012 2:03 PM
To: Shib Users
Subject: Re: Non Incommon SPs

Their rationale in our case has been based on the need to defray the costs to deploy custom code to support us (even though we are not their first).  The fact that we aren't their first deployment fueled my initial skepticism since how many hours could a 2nd or 3rd (or higher) custom deployment really entail?  This is a one time charge BTW.

The feedback here is much appreciated; I'm ready to get back into the ring and negotiate this some more.

 - Michael

On Tue, Jul 17, 2012 at 3:35 AM, Ann West <awest at internet2.edu<mailto:awest at internet2.edu>> wrote:
$5K is substantially more than what the top tier Corporate Participant (revenue of $1 B USD) pays per year for InCommon participation. Is that per year or one time, Michael.

If they are asking every InCommon Participant to pay that cost, they could be making a pretty penny that far exceeds their membership fees.

Ann
________________________________
And I'm indeed dealing with an academic publisher; I suppose I should be a little less miffed.
Thanks for the feedback.
 - Michael
On Mon, Jul 16, 2012 at 8:08 PM, Nicole Harris <nicole at shibboleth.net<mailto:nicole at shibboleth.net>> wrote:
Passing subscription charges for federation services back on to the institution is certainly behaviour I've seen from academic publishers, although it is often not as explicit it as this, just wrapped up in the service cost.  I'd say it would be unusual for most commercial vendors NOT to recoup federation fees from IdPs as part of their business model.  I guess you could argue that at least these guys are being completely upfront about it and not just hiding it in their product costs :-)

On 17/07/2012 01:25, Michael Hodges wrote:
Somewhat related to this thread, I'm dealing with a vendor that *is* an InCommon member, but they are requesting a $5k premium for supporting with our IdP rather than directly accessing our LDAP server (have they no shame!).  Has anyone run across this scenario?  I've pushed back since it's hard to consider this to be a reasonable additional cost, but haven't yet prevailed.

 - Michael
On Mon, Jul 16, 2012 at 2:05 PM, Bryan E. Wooten <bryan.wooten at utah.edu<mailto:bryan.wooten at utah.edu>> wrote:
Thank you all for the feedback. I don't know if it confirmation bias or not. But this type a quick response is what makes me a proponent of the open source (especially in Higher Ed) community. I would never expect this response from any of the "big" vendors. I thank you.

I am sure most of us deal with this level of conflict on a daily basis.

We all know that funding is an issue and I feel it is my responsibility to push back at vendors. This won't be the first or last. For me this is the 3rd HR / recruitment vendor I have had the pleasure of dealing with relating to SSO. Even an Incommon can't do it right. Sigh.

They all fail.

Best Regards.

Bryan
________________________________________
From: users-bounces at shibboleth.net<mailto:users-bounces at shibboleth.net> [users-bounces at shibboleth.net<mailto:users-bounces at shibboleth.net>] on behalf of Cantor, Scott [cantor.2 at osu.edu<mailto:cantor.2 at osu.edu>]
Sent: Monday, July 16, 2012 5:18 PM
To: Shib Users
Subject: Re: Non Incommon SPs

On 7/16/12 7:01 PM, "Bryan E. Wooten" <bryan.wooten at utah.edu<mailto:bryan.wooten at utah.edu>> wrote:
>
>What are the steps we can make to make this possible? Do we require they
>provide us with their SP's metadata or can we create that on our own. I
>am also not sure about certificate exchange for SAML assertions.

If you care, and if you decide you need to encrypt data to them, then
you'll have to have a way to verify their key. They will not understand
what you mean, or why you care, but that's life. You can save some trouble
by not bothering with a key on their end if you can live with the data in
the clear in the messages.

You may also, based on the eduPerson comment, have to create custom
attribute encodings (or maybe even definitions) in your resolver, which is
a significant change.

>Any idea the level of effort we will need to make this happen (man hours)?

There are too many variables to answer that. It can take me minutes to
several hours or even longer if I'm busy debugging their implementation,
pen-testing it, finding bugs, sitting on phone calls explaining to them
why their code is broken. Not that I've ever done that.

A lot of this comes down to whose data it is. If it's OSU's, then I have
to care or I'm not doing my job. If it's not, then to be honest, they can
do what they like to protect (or botch the protection of) their own data.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>



--

To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>


--

Shibboleth Consortium Manager

5 Lancaster Place

London WC2E 7EN


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>



--
Ann West
Assistant Director,
Assurance and Community
Internet2/InCommon/Michigan Tech
awest at internet2.edu<mailto:awest at internet2.edu>
office: +1.906.487.1726<tel:%2B1.906.487.1726>

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120717/af3d2b0d/attachment-0001.html