A cleaner way to prefetch MDQ metadata?

Wessel, Keith kwessel at illinois.edu
Mon Jun 27 20:08:33 UTC 2022

Thanks, Scott.

I think I’ll stick with the InCommon prefetch route even though I know that’s cheating and not really using MDQ in a true dynamic fashion until I can put something comprehensive and modular together. It’s not ideal, but it’s better in the short term than showing my SP operators how to configure even more pieces.

And if I'm going to change directions, yes, SeamlessAccess is the way to go.


-----Original Message-----
From: Cantor, Scott <cantor.2 at osu.edu> 
Sent: Monday, June 27, 2022 2:22 PM
To: Shib Users <users at shibboleth.net>
Cc: Wessel, Keith <kwessel at illinois.edu>
Subject: Re: A cleaner way to prefetch MDQ metadata?

On 6/27/22, 3:06 PM, "users on behalf of Wessel, Keith via users" <users-bounces at shibboleth.net on behalf of users at shibboleth.net> wrote:

>    So, are you saying it's bad to use the method proposed by InCommon to add additional resolvers to support
> my use case of loading metadata for an embedded discovery service?

I'm just saying it's not pre-fetching. If you want to use the EDS, you can't use MDQ, it simply isn't compatible.

>    Is there another way to accomplish what I'm trying to do other than downloading a huge federation
> metadata aggregate?

There are lots of ways to do discovery and all of them are bad. As a project, it's fair to say we gave up. I would personally just use Seamless Access if the list was huge and just create a simple UI myself if the list was small.

You could of course just build an XSLT that consumes the metadata aggregate out of band and produces the JSON for the EDS, or some other driver of a discovery UI. Ian actually threw together an MDA pipeline example that does it, we used it very briefly on shibboleth.net before we got out of the federated app business.


-- Scott

More information about the users mailing list