Central discovery service filter by role?

[Tom Scavo]

On Thu, Jun 26, 2014 at 11:20 AM, Tom Poage <tfpoage at ucdavis.edu> wrote:
>
> The metadata attribute is an intriguing idea, but would be limited to the following context (unless one finds utility for other decent-sized institutions):
>
> The University of California has a group of InCommon member IdPs (ten campuses, plus a handful of labs and affiliated schools) collectively known as UCTrust. The UC has been onboarding an increasing number of UC-only SPs, many vendor implementations of some sort.

Actually, we have been discussing this exact use case with UCTrust.
The plan is for UCTrust to be authoritative for an entity attribute in
SP metadata. You may be in luck :-)

> The typical choice for these apps has been to wire up the InCommon DS.
>
> Certainly, the embedded discovery service is one option, except that we end up redoing the same work over and over for each new SP stood up, not to mention maintenance burden/cost for any change to the discovery component.

In our experience, the embedded discovery service is dead simple to set up.

> From a user experience standpoint, there is the combination of wading through a list of some 400+ IdPs at the InCommon DS, the implicit suggestion that someone happening to visit from a non-UC institution might be allowed access, and there's a minor point of branding.

Yes, those are all good reasons NOT to use the InCommon DS, but then
replacing it with a centralized DS (central to your infrastructure) is
likewise not optimal. I think most people will agree that discovery is
best handled at the SP. There are always exceptions, and your use case
may be one of them, but so far I haven't heard a strong argument to
use a CDS.

Tom