And I'm indeed dealing with an academic publisher; I suppose I should be a little less miffed.<div>Thanks for the feedback.</div><div> - Michael<br><br><div class="gmail_quote">On Mon, Jul 16, 2012 at 8:08 PM, Nicole Harris <span dir="ltr"><<a href="mailto:nicole@shibboleth.net" target="_blank">nicole@shibboleth.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
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 :-) <br><div><div class="h5">
<br>
On 17/07/2012 01:25, Michael Hodges wrote:
<blockquote type="cite">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.
<div>
<br>
</div>
<div> - Michael<br>
<br>
<div class="gmail_quote">On Mon, Jul 16, 2012 at 2:05 PM, Bryan
E. Wooten <span dir="ltr"><<a href="mailto:bryan.wooten@utah.edu" target="_blank">bryan.wooten@utah.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
I am sure most of us deal with this level of conflict on a
daily basis.<br>
<br>
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.<br>
<br>
They all fail.<br>
<br>
Best Regards.<br>
<br>
Bryan<br>
________________________________________<br>
From: <a href="mailto:users-bounces@shibboleth.net" target="_blank">users-bounces@shibboleth.net</a>
[<a href="mailto:users-bounces@shibboleth.net" target="_blank">users-bounces@shibboleth.net</a>]
on behalf of Cantor, Scott [<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>]<br>
Sent: Monday, July 16, 2012 5:18 PM<br>
To: Shib Users<br>
Subject: Re: Non Incommon SPs<br>
<div>
<div><br>
On 7/16/12 7:01 PM, "Bryan E. Wooten" <<a href="mailto:bryan.wooten@utah.edu" target="_blank">bryan.wooten@utah.edu</a>>
wrote:<br>
><br>
>What are the steps we can make to make this
possible? Do we require they<br>
>provide us with their SP's metadata or can we create
that on our own. I<br>
>am also not sure about certificate exchange for SAML
assertions.<br>
<br>
If you care, and if you decide you need to encrypt data
to them, then<br>
you'll have to have a way to verify their key. They will
not understand<br>
what you mean, or why you care, but that's life. You can
save some trouble<br>
by not bothering with a key on their end if you can live
with the data in<br>
the clear in the messages.<br>
<br>
You may also, based on the eduPerson comment, have to
create custom<br>
attribute encodings (or maybe even definitions) in your
resolver, which is<br>
a significant change.<br>
<br>
>Any idea the level of effort we will need to make
this happen (man hours)?<br>
<br>
There are too many variables to answer that. It can take
me minutes to<br>
several hours or even longer if I'm busy debugging their
implementation,<br>
pen-testing it, finding bugs, sitting on phone calls
explaining to them<br>
why their code is broken. Not that I've ever done that.<br>
<br>
A lot of this comes down to whose data it is. If it's
OSU's, then I have<br>
to care or I'm not doing my job. If it's not, then to be
honest, they can<br>
do what they like to protect (or botch the protection
of) their own data.<br>
<br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>--
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a></pre>
</blockquote>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888"><pre cols="72">--
Shibboleth Consortium Manager
5 Lancaster Place
London WC2E 7EN </pre>
</font></span></div>
</blockquote></div><br></div>