Integration of Discovery Service
skoranda at gmail.com
Tue May 5 21:31:41 EDT 2015
On Tue, May 5, 2015 at 8:10 PM, Peter Schober
<peter.schober at univie.ac.at> wrote:
> * Scott Koranda <skoranda at gmail.com> [2015-05-06 03:02]:
>> On Tue, May 5, 2015 at 8:40 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>> > On 5/5/15, 7:00 AM, "Peter Schober" <peter.schober at univie.ac.at> wrote:
>> >>I'd still rather deploy a Shib SP with the EDS specifically for the
>> >>purpose of providing a "fallback" central DS than run the CDS.
>> >>Or use Lukas' SWITCHwayf.
>> > We think so too, that's why we're pretty much ready to kill the
>> CDS as part of the V2 EOL. If that panics anybody, particularly any
>> consortium members, now's a good time to yell.
>> I would not use the word "panic", but LIGO (a small consortium member)
>> is preparing right now to roll out the CDS into production.
>> While the EDS (at each SP) has worked well for us technically, our
>> users have come to us and asked that we deploy a centralized discovery
>> service instead. The Shibboleth CDS appeared to be the best choice at
>> the time we decided to move forward.
> You seem to have discounted (and/or misunderstood) my and Scott's
> comments wrt using the EDS /as/ as CDS: Just slap a Shib SP on a box
> (to do the heavy metadata lifting and filtering, not to protect any
> content) and let that feed JSON to a copy of the EDS.
> "CDS" done, no Java, enjoy.
Neither discounted nor misunderstood--just providing feedback from a
consortium member as requested. We understand the balance the
development team needs to maintain given limited resources.
We will definitely consider a centralized deployment of the EDS as an option.
Apologies for running two threads on this issue, so to try and consolidate...
The extensible nature of the CDS via plugins looked attractive. We
find as a VO rather (than a campus) that we have use cases different
enough that extensibility is often helpful.
More information about the users