Non Incommon SPs

[Nicole Harris]

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


-- 
Shibboleth Consortium Manager
5 Lancaster Place
London WC2E 7EN

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