Extending the SP Dynamic Metadata Provider

Rod Widdowson rdw at steadingsoftware.com
Mon Oct 30 12:44:30 EDT 2017


> I don't know if the SP supports the <saml1md:SourceID> element in
> metadata, and I'm not suggesting it should, but the point is that
> artifact resolution is a problem in any case, not just in the presence
> of MDQ.

It does.  It also handles type 0x0002 artifacts (which look like they get their magicke value from the location in the
ArtifactResolutionService).

Further it does so for both dynamic and batch metadata providers (but read on)

But the key point is that if in order to know what the magicke value is you have to have the metadata and if all you have is the
magicke value and a need for the metadata then you are caught.  

The batch providers are fine because they see all the metadata upfront and they can go through and index all these magicke extra
values.  

The Dynamic provider is fine so long as you ask for the entity by name first (then we have the metadata and so we can keep the
magicke value around).  But if the first time you see the magicke value is in an artifact then you have nowhere to start.

And I don't know if there is a profile that makes this possible (delegation maybe), but it can (theoretically) happen in the usual
case (if artifacts can be considered as usual) if the entity goes invalid between initial approach and the time for artifact
resolution.

> AFAIK there are no <saml1md:SourceID> elements in published metadata

Doesn't matter, the spec allows that there could be.

.... And that is why I hate artifacts (amongst other reasons).

/R



More information about the dev mailing list