MDQ

Wed Feb 3 18:56:28 UTC 2021

Hi Don,

Of course you should continue to use a file-backed provider if that's what
is the best option for your institution.  I wasn't clear about that from
your original posts, but I am now.  And if that's what you're going to do,
you should definitely use the "All entities" URL "
https://mdq.incommon.org/entities" for your IdP.

-Les

<http://www.carleton.edu/>

*Les LaCroix '79*

Strategic Technologist

Information Technology Services

t: (507) 222-5455

On Wed, Feb 3, 2021 at 12:17 PM Donald Lohr <lohrda at jmu.edu> wrote:

> I realize it is splitting hairs.
>
> InCommon's "Migrating to the MDQ Service" (
> https://spaces.at.internet2.edu/display/MDQ/migrate-to-mdq) speaks to:
>
> 1) retiring the legacy metadata service at *md.incommon.org
> <http://md.incommon.org>*
> 2) changing to consuming metadata from *mdq.incommon.org
> <http://mdq.incommon.org>*
> 3) the legacy metadata service is approaching the 100MB mark when
> aggregated & is no longer sustainable for the vast majority of deployments
> 4) InCommon will continue to provide aggregates at the new metadata
> location, signed with the new key, for the foreseeable future (at least the
> next five years), barring an unforeseen event that forces us to retire
> aggregates.
>
> So my read on this is, moving from the *md* url to the new *mdq* url is
> all that is needed to move to the new mdq service, no matter how you
> configure it.  The new *mdq* service supports (as document by InCommon):
>
> a) caching the entries as needed by using DynamicHTTPMetadataProvider
> b) caching entries as needed by using DynamicHTTPMetadataProvider +
> pre-fetching metadata for specific SPs by using
> FileBackedHTTPMetadataProvider
> c) caching the entire aggregate by using FileBackedHTTPMetadataProvider
> as supported via the md service
>
> Switching to the new mdq service is changing the url. Configuring for the
> new mdq for any of its features (based on the needs of the organization -
> with one of the above a-c options) is the second part. While the two can be
> done together, they should not be married together to exclusively mean or
> not mean switching to or not switching to the new MDQ service.
>
> While the a benefit to the new mdq service is grabbing only the metadata
> (just-in-time) needed by the organization, meaning less cached metadata.
> The one negative would be if the mdq site is down and metadata can not be
> obtained when using DynamicHTTPMetadataProvider for per-entity or the
> full aggregate. The advantage on using FileBackedHTTPMetadataProvider is
> having the local copy.
>
> I'm not saying the uptime of InCommon mdq service is poor, I'm just trying
> to have the best of all options available from a configuration using the
> mdq service.
>
> Don
>
> On 2/3/21 12:32 PM, Les LaCroix via users wrote:
>
> *CAUTION: *This email originated from outside of JMU. Do not click links
> or open attachments unless you recognize the sender and know the content is
> safe.
> ------------------------------
> Donald,
>
> ...the thinking is to initially configure MDQ for "All Entities"
>
>
> IIUC you're reading the "Retrieving metadata as aggregates" section, which
> lists URLs that can be used with the FileBackedHTTPMetadataProvider in lieu
> of the old URLs.  If you replace the URL in your legacy configuration, I
> believe that all you are doing is creating an equivalent file using a new
> source URL.  In my mind, that's not really "configuring MDQ".  Configuring
> MDQ would be defining a DynamicHTTPMetadataProvider to use the InCommon MDQ
> service, along with removing (or commenting out) the
> old FileBackedHTTPMetadataProvider stanza for the old way of acquiring
> metadata from InCommon.
>
> -Les
>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.carleton.edu_&d=DwMFaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=YuDkHVbNM9swmUy8F09P-iTUoavftOtQrZe4sv7jJ98&s=mPdTXa0OrmpjuXLqvY1x2XImtYgjZp_Nh1X_ZJESw2A&e=>
>
> *Les LaCroix '79*
>
> Strategic Technologist
>
> Information Technology Services
>
> t: (507) 222-5455
>
>
> On Wed, Feb 3, 2021 at 11:03 AM Donald Lohr <lohrda at jmu.edu> wrote:
>
>> 1)
>>
>> https://spaces.at.internet2.edu/display/federation/Download+InCommon+metadata
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__spaces.at.internet2.edu_display_federation_Download-2BInCommon-2Bmetadata&d=DwMFaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=YuDkHVbNM9swmUy8F09P-iTUoavftOtQrZe4sv7jJ98&s=XWPY5gzkRmSP9VR8xuUf6klXpmYZbRb0DV_K-5FuA0g&e=>
>> and https://spaces.at.internet2.edu/display/MDQ/production-metadata
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__spaces.at.internet2.edu_display_MDQ_production-2Dmetadata&d=DwMFaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=YuDkHVbNM9swmUy8F09P-iTUoavftOtQrZe4sv7jJ98&s=ToxeSKZ5ufyu25ESZCQJd35MqVRWrKT83mP_O63iUJA&e=>
>>
>> ...speaks to their MDQ "akin to legacy" offering which gets the entire
>> file.
>>
>> 2) I believe I just answered my original question.  In all their MDQ
>> examples DynamicHTTPMetadataProvider is used. In our current MD (legacy)
>> configuration FileBackedHTTPMetadataProvider is used.
>>
>> Thanks,
>> Don
>>
>> On 2/3/21 11:44 AM, Cantor, Scott wrote:
>> > CAUTION: This email originated from outside of JMU. Do not click links
>> or open attachments unless you recognize the sender and know the content is
>> safe.
>> > ________________________________
>> >
>> >>     In the new MDQ configuration to support this "akin to legacy"
>> approach, does it support writing to a file similar to the
>> >> old MD service like:
>> > No. Doing that is something you would do with the older batch metadata
>> provider by pointing it at that URL. I would not think InCommon would want
>> that unless they intend people to move off the old URL for some reason but
>> continue to suck down the whole file. That's not my impression.
>> >
>> > -- Scott
>> >
>> >
>> > --
>> > For Consortium Member technical support, see
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwICAg&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=kyaNL4qLve7vrv2fAj0zytujAQ87UhscZGPXxDyV9Z0&s=yf5zydTHnILqRhBXTutaKqSbAQDgIh7V7E0XtWJVabA&e=
>> > To unsubscribe from this list send an email to
>> users-unsubscribe at shibboleth.net
>>
>> --
>> 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
>>
>> --
>> For Consortium Member technical support, see
>> https://wiki.shibboleth.net/confluence/x/coFAAg
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwMFaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=YuDkHVbNM9swmUy8F09P-iTUoavftOtQrZe4sv7jJ98&s=EQ254IY8Tz5fJSwq9vJKTw3qT5Y9eyibfV3okxLOIDg&e=>
>> To unsubscribe from this list send an email to
>> users-unsubscribe at shibboleth.net
>>
>
>
> --
> 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
>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20210203/5afa0d3d/attachment.htm>