Some thoughts as I’m starting to near where this would get used in the SP….

The SP at this point is reusing a substantial amount of the IdP security confg, tbough I haven’t worked in any SOAP support at this stage (it will be needed for artifact resolution though).

The profile config and relying party layer is substantially identical at least once things are “going” in a particular flow, though obvously we’ve never done a lot with them in the resolver, and the attribute library is in fact “under” the profile library, so we’re going to need to indirect access to the necessary config information so that the resolver never has to know where it comes from. We can always hang more material off the AttributeResolutionContext to drive new use cases, or perhaps add a second subcontext for some special scenarios like this.

The one thing that I realized though is that the query data connector is going to need/want to actually run the Attribute Filter service itself against the results. Otherwise, trying to do it “at the end” in the SP code will lack the right context for who the issuer of specific attributes was, whereas the query connector knows that so it can run the filter with the right inputs.

The meta point here is that all existing connectors today are sort of assumed to be operating against local data sources, or have enough power to directly control what data they “surface”, as in the HTTP case via scripted response handling.

This connector probably could be built that way, but if we want the most general approach, having it just run the filter against an issuer set to the AA identity makes the most sense to provide control. This assumes I will eventually get a wildcard rule of some kind of built into the filter language, which I will almost certainly have to do.

Probably the best way to tackle this is to outline eventually what the query connector will need from the configuration to run, and I can work from the other end to supply them.

(Point of fact it can’t leverage the IdP anyway since this is properly housed in the new Attribute library, thus I moved the ticket.)

Thinking ahead as I’m working on the SP, I think we will probably want to think about configuring behavior for this based on being able to derive some of the configuration objects at runtime.

The net.shibboleth.idp.profile.config.SecurityConfiguration interface unfortunately may not exactly get reused in the SP but I think the underlying objects it’s exposing from OpenSAML can be, so being able to produce the right ClientTLSValidationConfiguration and HttpClientSecurityConfiguration independently would be good. Then the IdP and SP can each supply those from slightly different underlying interfaces.

Brent is looking at this, not me

I was hoping you’d say that.