n.b. I came close to doing the PR to make this happen then quickly concluded I should write this feature request first, to ensure the PR wouldn't be summarily rejected for one reason or another. Otherwise, I'd be perfectly happy to do the leg work.
Problem:
The *tls.ConnectionState from the origin request is not available in the *logical.Request passed to external plugin callbacks. This greatly hinders development of plugins intent on examining incoming client certificates.
Solution:
The original request's *tls.ConnectionState should be marshalled through to external plugins as part of the pb.Connection protobuf message that's included when making gRPC calls to the plugin.
As an optimization, inclusion could be optional and the ConnState only added for plugins (or perhaps just Paths or Operations) that request it.
Alternatives:
In my current use-case I'm developing a plugin that needs to examine several x.509v3 custom extensions attached to a client's certificate and, as a work around, I've extracted those values on the client side and sent them to the plugin as field values -- but, this is an ugly hack and introduces several limitation.
n.b. I came close to doing the PR to make this happen then quickly concluded I should write this feature request first, to ensure the PR wouldn't be summarily rejected for one reason or another. Otherwise, I'd be perfectly happy to do the leg work.
Problem:
The
*tls.ConnectionStatefrom the origin request is not available in the*logical.Requestpassed to external plugin callbacks. This greatly hinders development of plugins intent on examining incoming client certificates.Solution:
The original request's
*tls.ConnectionStateshould be marshalled through to external plugins as part of thepb.Connectionprotobuf message that's included when making gRPC calls to the plugin.As an optimization, inclusion could be optional and the ConnState only added for plugins (or perhaps just Paths or Operations) that request it.
Alternatives:
In my current use-case I'm developing a plugin that needs to examine several x.509v3 custom extensions attached to a client's certificate and, as a work around, I've extracted those values on the client side and sent them to the plugin as field values -- but, this is an ugly hack and introduces several limitation.