tree 7411321e498a2320f1fa8611f1317452bfc6b098
parent 89cda63d6646074f4be2d49981a5609f761c015f
author Ed Tanous <ed@tanous.net> 1719356525 -0700
committer Ed Tanous <ed@tanous.net> 1720744099 +0000

Support RespondToUnauthenticatedClients PATCH

RespondToUnauthenticatedClients allows users to explicitly select mTLS
as their only authentication mechanism, thus significantly reducing
their code exposure to unauthenticated clients.

From the Redfish specification

```
The RespondToUnauthenticatedClients property within the
ClientCertificate property within the MFA property of the AccountService
resource controls the response behavior when an invalid certificate is
provided by the client.
• If the property contains true or is not
supported by the service, the service shall not fail the TLS handshake.
This is to allow the service to send error messages or unauthenticated
resources to the client.
• If the property contains false , the service
shall fail the TLS handshake.
```

This commit implements that behavior.

This also has some added benefits in that we no longer have to check the
filesystem for every connection, as TLS is controlled explicitly, and
not whether or not a root cert is in place.

Note, this also implements a TODO to disable cookie auth when using
mTLS.  Clients can still use IsAuthenticated to determine if they are
authenticated on request.

Tested:
Run scripts/generate_auth_certs.py to set up a root certificate and
client certificate.  This verifies that mTLS as optional has not been
broken.  Script succeeds.

```
PATCH /redfish/v1/AccountService
{"MultiFactorAuth": {"ClientCertificate": {"RespondToUnauthenticatedClients": false}}}
```

GET /redfish/v1
without a client certificate now fails with an ssl verification error

GET /redfish/v1
with a client certificate returns the result

```
PATCH /redfish/v1/AccountService
{"MultiFactorAuth": {"ClientCertificate": {"RespondToUnauthenticatedClients": false}}}
With certificate returns non mTLS functionality.
```

Change-Id: I5a9d6d6b1698bff83ab62b1f760afed6555849c9
Signed-off-by: Ed Tanous <ed@tanous.net>