TLS, no seriously. (#2963)

CODE_OF_CONDUCT.md

@@ -23,6 +23,7 @@ Examples of unacceptable behavior by participants include:
 - Public or private harassment
 - Publishing others’ private information, such as a physical or electronic address, without explicit
   permission
+- Refusing to accept decisions or reasonable requests of project maintainers
 - Other conduct which could reasonably be considered inappropriate in a professional setting
 
 ## Our Responsibilities
@@ -34,7 +35,9 @@ behavior.
 Project maintainers have the right and responsibility to remove, edit, or reject comments, commits,
 code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or
 to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate,
-threatening, offensive, or harmful. Scope
+threatening, offensive, or harmful.
+
+## Scope
 
 This Code of Conduct applies both within project spaces and in public spaces when an individual is
 representing the project or its community. Examples of representing a project or community include
@@ -49,6 +52,7 @@ the project team at:
 
 - william at blackhats.net.au
 - charcol at redhat.com
+- james at terminaloutcomes.com
 
 All complaints will be reviewed and investigated and will result in a response that is deemed
 necessary and appropriate to the circumstances. The project team is obligated to maintain
@@ -61,4 +65,4 @@ temporary or permanent repercussions as determined by other members of the proje
 ## Attribution
 
 This Code of Conduct is adapted from the Contributor Covenant, version 1.4, available at
-https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+<https://www.contributor-covenant.org/version/1/4/code-of-conduct.html>

book/src/frequently_asked_questions.md

@@ -6,14 +6,30 @@
 
 You may have noticed that Kanidm requires you to configure TLS in your container or server install.
 
-We are a secure-by-design rather than secure-by-configuration system, so TLS for all connections is
+One of the fundamental goals of the project is a secure-by-design rather than
-considered mandatory and a default rather than an optional feature you add later.
+secure-by-configuration system, so TLS for all connections is mandatory. It is not an optional
+feature you add later.
 
-### Can Kanidm work without TLS?
+> [!NOTE]
+>
+> Please respect the maintainers decision on TLS-by-default, no discussions on this topic will be
+> entered into.
 
-No, it can not. TLS is required due to our use of `secure-cookies`. `secure-cookies` is a flag set
+### Why not allow HTTP (without TLS) between my load balancer and Kanidm?
-in cookies that asks a client to transmit them back to the origin site if and only if the client
+
-sees HTTPS is present in the URL.
+Because Kanidm is one of the keys to a secure network, and insecure connections to them are not best
+practice. This can allow account hijacking, privilege escalation, credential disclosures, personal
+information leaks and more.
+
+We believe that the **entire** path between a client and the server must be protected at all times.
+This includes the path between load balancers or proxies and Kanidm.
+
+### Can Kanidm authentication work without TLS?
+
+No, it can not. TLS is required due to our use of the `Secure` flag our cookies, which requires a
+client to transmit them back to the origin site
+[if and only if the client
+sees HTTPS as the protocol in the URL](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#security).
 
 Kanidm's authentication system is a stepped challenge response design, where you initially request
 an "intent" to authenticate. Once you establish this intent, the server sets up a session-id into a
@@ -24,18 +40,17 @@ detects this as an invalid-state request in the authentication design, and immed
 connection, because it appears insecure. This prevents credential disclosure since the
 authentication session was not able to be established due to the lost session-id cookie.
 
-Simply put, we are trying to use settings like `secure_cookies` to add constraints to the server so
+Simply put, we are using settings like secure cookies to add constraints to the server so that you
-that you _must_ perform and adhere to best practices - such as having TLS present on your
+_must_ perform and adhere to best practices - such as having TLS present on your communication
-communication channels.
+channels.
 
-This is also why we do not allow the server to start without a TLS certificate being configured.
+This is another reason why we do not allow the server to start without a TLS certificate being
+configured.
 
-### Why disallow HTTP (without TLS) between my load balancer and Kanidm?
+### WebAuthn
 
-Because Kanidm is one of the keys to a secure network, and insecure connections to them are not best
+Similarly, WebAuthn and its various other names like Passkeys, FIDO2 or "scan the QR code to log in"
-practice. This can allow account hijacking, privilege escalation, credential disclosures, personal
+will [only work over TLS](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API).
-information leaks and more. The entire path between a client and the server must be protected at all
-times.
 
 ## OAuth2
 
@@ -78,6 +93,14 @@ mitigations, authorisation code interception is not prevented by the presence or
 We would strongly encourage OAuth2 client implementations to implement and support PKCE, as it
 provides defense in depth to known and exploited authorisation code interception attacks.
 
+### Why do you allow disabling PKCE but not TLS?
+
+Because there are still many applications where PKCE is not available and it is not trivial to solve
+for all downstream applications. In the case that PKCE is absent on a single OAuth2 client, the
+scope of failure is reduced to that single client. This is not the case with TLS, which is trivial
+to configure, and in the case of compromise of an internal network between a load balancer and
+Kanidm, the attacker can access and steal all traffic and authentication data.
+
 ### Why is RSA considered legacy
 
 While RSA is cryptographically sound, to achieve the same level as security as ECDSA it requires
@@ -106,7 +129,8 @@ review, assessment and improvement.
 
 ## Can I change the database backend from SQLite to - name of favourite database here -
 
-No, it is not possible swap out the SQLite database for any other type of SQL server.
+No, it is not possible swap out the SQLite database for any other type of SQL server, nor will it be
+considered as an option.
 
 **_ATTEMPTING THIS WILL BREAK YOUR KANIDM INSTANCE IRREPARABLY_**
 
@@ -152,4 +176,5 @@ Don't [ask](https://www.youtube.com/watch?v=0QaAKi0NFkA). They just
 
 ## Why won't you take this FAQ thing seriously?
 
-Look, people just haven't asked many questions yet.
+Look, people just haven't asked many questions yet. Sorry, there are no easter eggs in this
+document, but there may be elsewhere 🥚

book/src/integrations/oauth2/examples.md

@@ -207,14 +207,16 @@ allow_assign_grafana_admin = true
 
 > [!WARNING]
 >
-> Vouch proxy requires a unique identifier but does not use the proper scope, "sub". It
+> Vouch proxy requires a unique identifier but does not use the proper scope, "sub". It uses the
-> uses the fields "username" or "email" as primary identifiers instead. As a result, this can cause
+> fields "username" or "email" as primary identifiers instead. As a result, this can cause user or
-> user or deployment issues, at worst security bypasses. You should avoid Vouch Proxy if possible
+> deployment issues, at worst security bypasses. You should avoid Vouch Proxy if possible due to
-> due to these issues.
+> these issues.
 >
 > - <https://github.com/vouch/vouch-proxy/issues/309>
 > - <https://github.com/vouch/vouch-proxy/issues/310>
+
 &nbsp;
+
 > [!NOTE]
 >
 > You need to run at least version 0.37.0