Dynamic metadata resolver; HttpClient usage

[Rod Widdowson]

> I didn't see (point me if I'm missing) that we are by default 
> wiring in any particular HttpClient instance into components, 
> and in particular I'm wondering about use of caching HttpClients.
> Should we either wire one of those in 

As  recall the mechanics of this get pretty grubby since we have tried
to keep all configuration defaults out of the parsers.  At one stage
the legacy relying-party still had a lot of hardwired bean names 
(rather than hardwired defaults), I think we've cut it down, but it's
still a worry

However, since then we have become smarter in the use of properties.  I am
wondering whether we could end up across all our providers with defaulting
(no other options provided) the value of client-ref to be 

"%{idp.httpclient.dynamicmetadata}:shibboleth.httpclient.caching}".  

Then have we idp.properties allow local override of the property - potentially 
indirecting through another property it as we do for the services resources.

That way we still have defaulting in the parsers (which worries me) but it's
visible and controllable at the property level.  

If we then made the bean definitions visible and lazy init then we should
have reasonable level of control all the way between neophyte and advanced.


> and/or make the parsers, etc build a caching variant by default?  
> Having it be on by default might be nice for deployers, but would 
> mean that we'd have to decide upon the caching strategy/store 
> (essentially in-memory vs filesystem), so I don't know how contentious
> that choice would be...

I had the same internal dialog when I first thought about this and decided that, for then, I didn't want to make any call.  There was too much configuration and too much of a chance to get it wrong.  But in all the cases until now the use were very much in the advanced space, so it was reasonable to let the deployer decide.

This feel more like a game changer, but the problem remains of making the right choice.  I would have thought memory since they will be few, but I have no deployment experience.  Equally there is caching above us so maybe none is correct.

> The dynamic metadata resolver and associated IdP Spring schema
> and config is essentially done.  It might be a good idea if 
> someone other than me gives the IdP config schema a look 
> over (shibboleth-metadata.xsd) and the parsers, just to
> have another opinion what it should look like, etc.  
> Or in case I've totally missed something that is 
> expected to be there.

I skimmed the checkins as they happened and didn't see any surprises; I'll check it out in more detail, but it may be this weekend.

Rod