Give LeaseSender view into Authentication context (per-user leases)

[rrileyca]

Currently, the only context a Lease seems to have access to is the connection through the TrackingLeaseSender interface. This makes sense, but I have a use case where I would like to send a nonce that is used for HMAC authentication in the LEASE metadata. This seems to be impossible at the moment, since the LeaseSender can only gather context about the connection (via the generation of some unique "connectionId", as in the advanced lease sample). However, then the Authentication/Authorization framework does not have access to the connection and subsequently the Lease context.

I would like to tie these together such that in the SETUP <-> LEASE exchange, the LEASE frame could contain user-aware metadata, such as a nonce that will later be used by the Authentication/Authorization framework.

Motivation

I would like to enable an HMAC solution for Authorization where the Requester and Responder each send each other a nonce to be used in the HMAC dervation (as the info and salt parameters). The flow would look like this:

1. Requester generates a requesterNonce, and sends it to the Responder in its SETUP Metadata
2. Responder receives requesterNonce and generates its own responderNonce. It sender both back to the Requester in the LEASE frames Metadata

At this point, using cryptographic keys exchanged outside this RSocket flow/context, each side can generate an HMAC for each frame and place the HMAC in the Metadata of a frame. The Authorization framework would validate the HMAC using the exchanged nonces.

For clarity, there are reasons why transport layer security (TLS) is not an option. I am open to suggestions if I have missed a way for this capability to be implemented.

[rrileyca]

Adding a thought - perhaps even just passing in the SETUP frame would be enough to perform some dynamic logic on the LEASE frames. I think this makes sense. For example, if you wanted to apply backpressure to a specific routing endpoint, you would need to read the SETUP metadata to make that decision. I'm sure there are other use cases. This would also satisfy my use case.