Parsec with multiple authenticators

[hug-dev]

With #200 and #232 we can imagine a future where we will have three possible authentication methods:

1. Direct authentication using the parsec-cliens group to restrict access on the socket
2. Unix Peer Credentials authentication
3. SPIFFE/SPIRE based authentication

This raises multiple questions:

• How will each one of them be activated? What is the default one?
• What is the impact on the threat model (both service and client) and the recommendations for secure deployment?
• What is the impact on the permission checks that we do in the service under the no-parsec-user-and-clients-group feature?
• What is the impact on the permission checks we do in the client under the no-fs-permission-check feature?

As our threat model and code assume that the deployment is secure enough for direct authentication, we can securely add more authenticators in the code base respecting the same requirements.
However, if we want to loosen those requirements when using other authenticators and remove the current restrictions for Parsec clients:

• they have to trust each other
• they have to be part of the parsec-clients group

The questions above will have to be answered and modifications done in the code and the documentation.

[hug-dev]

Adding a possible threat: if multiple authentication methods are concurrently allowed how to deal with two authenticators returning the same application name? Should that allow using the same keys or should we add one more layer in the key store for authenticator name?
Another level of isolation could protect the keys created with other authenticator from one with a vulnerability.

[hug-dev]

We will only first allow one and only one authenticator at a time. There is a possible threat if an authenticator is re-configured while keys are stored in Parsec. If that happens then the same keys will be accessible with another authentication method, with different security protections. For now, we will add a WARNING notice in the configuration file to warn the admin not to re-configure the authenticator if there are existing keys.

See #271 for reference.