InC-Lib-Vendor

[David Kennedy <>]

The value of federation
attributes mainly to institutions.

I certainly get your point, Kent.  But,
I think it does go both ways as well.  That management of IdP metadata
is simplified for SPs if those SPs only need to maintain updating this
metadata from a few sources (federations) rather than with each individual
customer.

If you look at the Elsevier workflow
for initiating a new Shibboleth customer, their helpdesk support is the
point of contact, and that level of support is able to get things up and
running for an InCommon member by just asking the customer for their EntityID.
 It seems to me that there is value of the federation for the SP as
well.

Dave

-----
David Kennedy
Application Developer
Perkins Library, Duke University
(919) 613-6831

From:	"Kent Percival" <>
To:	"'inc-lib-vendor'" <>
Date:	10/22/2009 10:17 PM
Subject:	RE: [InC-Lib-Vendor] First stab at Shib/EZproxy how-to document

---

David,
Our good friends at
that little company down the road .. called Microsoft … don’t seem to
worry about federations for some things that do.  Their DreamSpark
program is using Shibboleth to verify students are registered at qualifying
educational institutions.  Their instructions to educational institutions
are to send them the IdP metadata directly so they recognize the institution.
 … and then they say BTW, if you are a member of a federation that
would also work.
 
That approach is OK
for service providers who are keen to work directly with their customer
technical folk as part of their contractual & support effort – no
middleman.  The value of federation attributes mainly to institutions.
 Scalability of access management occurs when IdP metadata only has
to be updated with the federation operator who distributes it with everyone
else’s metadata.
 
....Kent
 _
 
From: David Kennedy []
Sent: October 22, 2009 11:14
To: Foster Zhang
Cc: inc-lib-vendor; 
Subject: RE: [InC-Lib-Vendor] First stab at Shib/EZproxy how-to document
 
Foster, while this is not a technical requirement
of the Shib software for an institution to join a federation, it will be
a blocker for institutions that try to deal with information providers
w/o joining.  I imagine that some vendors will not want to, or maybe
not be able to, deal with institutions not in a federation. 

I would say leave the requirement in, and if we think it necessary, put
a footnote in indicating that an institution can do this w/o a federation,
but that not all vendors are equipped to deal with this situation.

Andy, this is a great start to the document.  This IS what I was expecting.
 Thanks for working on this.

Dave 

-----
David Kennedy
Application Developer
Perkins Library, Duke University
(919) 613-6831

From:	Foster Zhang <>
To:	"" <>, inc-lib-vendor <>
Date:	10/22/2009 11:06 AM
Subject:	RE: [InC-Lib-Vendor] First stab at Shib/EZproxy how-to document

---

Steven,

https://shibboleth.johnshopkins.edu/shibboleth-idp/SSO?shire=https%3A%2F%2Fpqshibboleth.proquest.com%3A9443%2FShibboleth.sso%2FSAML%2FPOST&time=1249052380&target=https%3A%2F%2Fpqshibboleth.proquest.com%3A9443%2Fpqdweb&providerId=https%3A%2F%2Fpqshibboleth.proquest.com%3A9443%2Fshibboleth

do not know if I name it correctly.

Foster

-----Original Message-----
From:  []
Sent: Thursday, October 22, 2009 10:17
To: inc-lib-vendor
Subject: RE: [InC-Lib-Vendor] First stab at Shib/EZproxy how-to document

At 9:25 AM -0400 10/22/09, Foster Zhang wrote:
>Andy,
>
>If you set up a shib wayfless url from Information Provider that 
>hardcoded the IdP info, you do not have to be a member of a 
>federation to use it.
>

could someone define this term for me: "shib wayfless url from 
Information Provider", and give an example?

thanks!