Non Incommon SPs

Tue Jul 17 16:46:57 EDT 2012

We definitely weren't buying in at $5k, but didn't like the LDAP
alternative.
Thanks for the additional perspective.  I'm looking forward now to engaging
the vendor.
 - Michael

On Tue, Jul 17, 2012 at 10:36 AM, Curry, Warren <whcurry at ufl.edu> wrote:

>  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> 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>
> 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>
> 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 [users-bounces at shibboleth.net] on
> behalf of Cantor, Scott [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> 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
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net****
>
> ** **
>
> ** **
>
> --****
>
> To unsubscribe from this list send an email to 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****
>
> ** **
>
>
>
> -- ****
>
> Ann West
> Assistant Director,
> Assurance and Community
> Internet2/InCommon/Michigan Tech
> awest at internet2.edu
> office: +1.906.487.1726 ** **
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net****
>
> ** **
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120717/e1b288ad/attachment.html 