Central discovery service filter by role?

[Tom Poage]

On Jun 26, 2014, at 1:03 AM, Rod Widdowson <rdw at steadingsoftware.com> wrote:
> For the record and those searching in the future.
> 
> It's not clear from the thread whether people have considered and rejected
> the CDS white and black filter (towards the bottom of
> https://wiki.shibboleth.net/confluence/display/SHIB2/DSAddMetadata)
> 
> I'd maintain that this is not really what you want 
> 
> - The list is static and the CDS does not reload it's configuration.
> - White (or black) listing is probably not enough for your situation,

That's what I was attempting to use, but could not find a way to white list e.g. all SPs with a subset of IdPs. Impractical to track and blacklist a large and changing number of unnecessary IdPs, and impractical to track and whitelist the small number of infrequently changing IdPs plus a large and changing number of SPs.

Anyhow, to answer Tom Scavo's question, yes, it's federation metadata. 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. 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. 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.

Given the UC doesn't add schools all that often :-) the thought was, from a maintenance standpoint, to allow an open-ended set of (InC-registerd and maybe locally-federated) SPs and present the limited set of IdPs. That said, it's extremely unlikely InCommon registered, non-UC SPs would wire themselves up for this discovery service (unless someone gets creative crafting initiation URLs), so maybe maintaining the gradually-growing list of SPs (multiplied by prod, dev, QA) by hand in the DS white list isn't all that daunting.

Anyhow, I'm just exploring what can and can not be done at this point.

Thanks.
Tom.