InCommon MDQ

Lohr, Donald - lohrda lohrda at
Mon Jul 6 17:05:21 UTC 2020

Our Shibboleth IdP exceeds the 3.2 version referenced on the url.

1) Right/wrong/indifferent (likely wrong) our practice seems to have 
always been when adding a new non-InCommom member's metadata is to drop 
in the default /metadata folder and to edit the 
/conf/metadata-providers.xml file and add either configuration:

FileBackedHTTPMetadataProvider / backingFile / metadataURL

FilesystemMetadataProvider / metadataFile

...based on what the SP vendor supports.

Our metadata-providers.xml file has the various metadata definitions all 
listed in alphabetical order. This includes non-InCommon SPs metadata 
definitions, the InCommon definition and the metadata definition for 
another federation.

Somewhere  I read, that the InCommon definition should come before or or 
after everything else, but am not able to locate that again. In a 
metadata-providers.xml file like I am describing, what kind of order 
listing should be used to list federations and specific SPs?

On the same url I mentioned above I did find similar wording stating 
that InCommon (for MDQ) should be last:
**Configuring with multiple metadata providers*
If you have more than one metadata provider in your Shibboleth 
configuration, you will want to put the InCommon Per-Entity Metadata 
Distribution Service after any statically configured metadata providers. 
If you do not do this, Shibboleth will try to fetch your static entities 
from InCommon each time it is requested before falling back to your 
static metadata providers.

2) On the "pre-fetch MDQ url 
it states:

/You may wish to pre-fetch one or more entities//
Does anyone have any real word experiences as to how many pre-fetches 
one should not exceed?


D o n a l d   L o h r
I n f o r m a t i o n   S y s t e m s
J a m e s   M a d i s o n   U n i v e r s i t y
5 4 0 . 5 6 8 . 3 7 3 0

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list