New Function in IdP V3.4/V4

[Rod Widdowson]

Thanks for the response.  It pretty much answers both my question and my need.

Just for the record

> > 1) Support DBCP from native configuration syntax/deprecate C3P0
> 
> That's the sort of thing I tend to not want to do in point releases because it's an invisible change that's pretty substantive. 

The plan is _not_ to make it invisible.  The current attributes map directly onto C3P0 ones so we'd need to put in a parallel set of attributes that map DBCP, do the "either one or the other" test and then fork.

But it does help my understanding.  Gratuitous looking _invisible_ changes are for V4.  Stuff you can choose to take advantage of or not is 3.4

> > 2) New “shell refresh” Resource to replace SVN based Resources (and to open the door to git).  Deprecate SVN
> 
> Which OTOH is just new. That should get in as soon as we can

I'll put in an explicit case and JFDI

>, as much as "shell anything" is pretty much a "hack me" sign

Urk, not sure why I didn't spot that.  Obvious mitigation is to require/allow an encrypted shell command, we can take that to the case; I quail at using xsec, although we _do_ have the infrastructure.

> 
> > 3) Security custom namespace:
> 
> Need to know more about that one (even if I created the issue, I don't remember).

Such discussions we had are hidden in https://wiki.shibboleth.net/confluence/x/5QAOAg

The basic idea is that in V3 we have driven the sec: namespace into a corner such that it is now only used in
   - LDAP Data connector (<StartTLSTrustCredential>, <StartTLSAuthenticationCredential> )
   - HTTP Client behavior:
        - HTTPMetadata resolvers (<TLSTrustEngine>), 
        - HTTPDataConnector
    - Metadata SignatureValidation Filter (<TrustEngine>)

And the question is whether we can get rid of sec: entirely and rely on attributes and inline certificates for the common cases and for the edge cases use bean references and a native bean based configuration for trust engines.  The metadata signature filter is a long way down the track with this. The other two less so.

I'm confident about simplifying the common cases for the LDAP data Connector and probably for the HTTPClient.  I'd need input & help before embarking on the last (native bean base TrustEngines).

I'll take as a general steer to (in order)
  1) Get Shell Refresh  Resource done.
  2) Simplify LDAP credentials
  3) Do due diligence  / research on
       a) C3P0
       b) TrustEngines 
 4) I think that for now I'll shelve the proposal to allow true mixed mode Spring configuration and slide it in to V4 for one or two schema only.

Getting (3) done will make it possible to make the call on what we can/should do in 3.4, but as you say time & hours are going to be the drivers.

Thanks again.

/Rod