[JIRA] (IDP-1870) Detect duplicate entityIDs when ingesting metadata

[Brent Putman (Jira)]

Brent Putman ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A97de0981-adc3-4044-95ed-131622fad81e ) *commented* on IDP-1870 ( https://shibboleth.atlassian.net/browse/IDP-1870?atlOrigin=eyJpIjoiMjljZWFlYWQ5ZGRmNGFiOWJjYWU1ZGFmMjQ0NTg0ZDciLCJwIjoiaiJ9 )

Re: Detect duplicate entityIDs when ingesting metadata ( https://shibboleth.atlassian.net/browse/IDP-1870?atlOrigin=eyJpIjoiMjljZWFlYWQ5ZGRmNGFiOWJjYWU1ZGFmMjQ0NTg0ZDciLCJwIjoiaiJ9 )

Exactly, the current duplicate detection is only for duplicates within the same provider. For example, dups inside an EntitiesDescriptor as loaded by a given provider. There is currently no support for detecting duplicates across providers as in your example.

It would actually be a bit difficult to achieve that. Offhand and at a high level: First we’d have to expose on the resolver interface(s) a way to enumerate the entityIDs currently known by that provider. And then second, there would have to be some kind of async task/job that ran periodically that knew how to interrogate each running provider and then did the comparison to see if there were duplicates in the global set. Not exactly sure how/where that would live (IdP-only vs OpenSAML, etc). And not sure how that would then “raise” the error, other than by just logging it.

It might in the end be achievable, but not without some redesign of some of the higher-level components and interfaces.

There’s also conceptual issues here when you have a mix of batch and dynamic providers. Dynamic is well, “dynamic”. It might not have a given entityID fetched and cached at this moment, but it could later when an actual request causes it to be fetched.

Another idea is we could take a middle approach: Expose the known entityIDs via the provider interfaces, and in the IdP expose that via our admin APIs. Then it would be possible for a deployer to implement the dup detection themselves by fetching and comparing across the providers of interest, using whatever technology (e.g. script + cron) and report out however they like (e.g. send email, etc).

We can leave this open for now for brainstorming, but there unfortunately isn’t a simple and obvious fix here.

( https://shibboleth.atlassian.net/browse/IDP-1870#add-comment?atlOrigin=eyJpIjoiMjljZWFlYWQ5ZGRmNGFiOWJjYWU1ZGFmMjQ0NTg0ZDciLCJwIjoiaiJ9 ) Add Comment ( https://shibboleth.atlassian.net/browse/IDP-1870#add-comment?atlOrigin=eyJpIjoiMjljZWFlYWQ5ZGRmNGFiOWJjYWU1ZGFmMjQ0NTg0ZDciLCJwIjoiaiJ9 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core&referrer=utm_source%3DNotificationLink%26utm_medium%3DEmail ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailNotificationLink&mt=8 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100183- sha1:445115c )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/commits/attachments/20211014/dea24dfd/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-comment-icon-b77aac25-04a4-45cf-9de8-948bea2982bc
Type: image/png
Size: 1084 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20211014/dea24dfd/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-avatar-0bdabe84-640a-4129-9a27-c1ec5a86ce1f
Type: image/png
Size: 457 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20211014/dea24dfd/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-footer-desktop-logo-dffb9956-c9dc-4305-a844-c5d181ec1fd3
Type: image/png
Size: 10805 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20211014/dea24dfd/attachment-0005.png>