Implement an authenticator based on the domain socket peer credential

[paulhowardarm]

Summary

Implement a new front-end authenticator module that uses domain socket peer credentials to deduce and validate the client application identity.

Rationale

In the specific case where domain socket is being used as the transport, and a peer property (such as UID, GID or PID) can be used as a sufficient differentiator for the application identity, it allows for a simple means of identity management without a separate identity provider component.

Constraints

This authenticator can only be used with domain socket transport, because the notion of peer credentials only exists in that case. It can also only be used when some aspect of the peer credential is a suitable token of application identity. (Typically this would be the UID, but it could also be the GID - theoretically even the PID, although in practice this is probably far too volatile to be useful).

Details

Requires the following:

• Assign and document an integer selector to be used as the auth_type field in the wire protocol.
• Design and document how a client application should populate the authentication header when using this auth type.
• Design and implement a means of passing data (which in this case is the peer credential) from the listener to the authenticator, which is captured as a separate issue here: Create a mechanism for the listener to pass system-level data to the authenticator #199
• Rework the DomainSocketListener so that it can obtain peer credentials from the system. This might mean using a different UDS library, because it looks like the standard Rust UnixListener does not provide access to the peer credential.
• Implement an authenticator module that can read the auth header and use the peer credential to validate it.
• Suitable unit tests and integration tests to prove the mechanism.
• May require modifications to the thread model and recommendations for secure deployment when this type of authenticator is being used.

Definition of Done

It is possible to create a demo deployment where at least two distinct client applications, running as different users, can both create and use a Parsec key with the same name. It is also possible to show that a request will be rejected if the client attempts to spoof its UID in the auth header of the request.

[ionut-arm]

Design and document how a client application should populate the authentication header when using this auth type.

Are we making the assumption that multiple applications might run under the same user? Trying to gauge whether we need to actually pass anything in the authentication header or if we should just namespace on the user ID alone.

Also, given that the metadata is actually dependent on the listener, it might make sense to have it enabled conditionally on the listener in the config data - as in, attach or enable the processing of metadata for each authenticator that we have, when the service gets created. This would lead to app identity being a composite of metadata and request auth and there's no need for another authentication type - you can use any authentication and the request metadata gets mixed in automatically by the service, the client doesn't need to be aware.

[hug-dev]

it looks like the standard Rust UnixListener does not provide access to the peer credential.

Not for too long! @joechrisellis has made a PR on Rust to enable this: rust-lang/rust#75148

[hug-dev]

Implementation is in #214