Non Incommon SPs

[Michael Hodges]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120716/95e9c492/attachment.html