diff --git a/Cargo.lock b/Cargo.lock index 5d4f537d0..c94974918 100644 --- a/Cargo.lock +++ b/Cargo.lock @@ -365,6 +365,9 @@ name = "ahash" version = "0.3.8" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "e8fd72866655d1904d6b0997d0b07ba561047d070fbe29de039031c641b61217" +dependencies = [ + "const-random", +] [[package]] name = "aho-corasick" @@ -664,18 +667,39 @@ dependencies = [ [[package]] name = "concread" -version = "0.1.18" -source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "e391cd28b9a522a8a3a4566fcd6d031847d82e436196c1120017e3b1112872fa" +version = "0.1.19" dependencies = [ + "ahash", "crossbeam", "crossbeam-epoch", "crossbeam-utils", + "libc", "num", "parking_lot", + "rand", "smallvec", ] +[[package]] +name = "const-random" +version = "0.1.8" +source = "registry+https://github.com/rust-lang/crates.io-index" +checksum = "2f1af9ac737b2dd2d577701e59fd09ba34822f6f2ebdb30a7647405d9e55e16a" +dependencies = [ + "const-random-macro", + "proc-macro-hack", +] + +[[package]] +name = "const-random-macro" +version = "0.1.8" +source = "registry+https://github.com/rust-lang/crates.io-index" +checksum = "25e4c606eb459dd29f7c57b2e0879f2b6f14ee130918c2b78ccb58a9624e6c7a" +dependencies = [ + "getrandom", + "proc-macro-hack", +] + [[package]] name = "constant_time_eq" version = "0.1.5" diff --git a/FAQ.md b/FAQ.md new file mode 100644 index 000000000..cc33119ed --- /dev/null +++ b/FAQ.md @@ -0,0 +1,104 @@ +Frequently Asked Questions +-------------------------- + +This is a list of common questions that are generally raised by developers +or technical users. + +Why don't you use library/project X? +------------------------------------ + +A critical aspect of kanidm is the ability to test it. Generally requests to add libraries +or projects can come in different forms so I'll answer to a few of them: + +## Is the library in Rust? + +If it's not in Rust, it's not ellegible for inclusion. There is a single exception today +(rlm python) but it's very likely this will also be removed in the future. Keeping a single +language helps with testing, but also makes the project more accesible and consistent to +developers. Additionally, features exist in Rust that help to improve quality of the project +from development to production. + +## Is the project going to create a microservice like architecture? + +If the project (such as an external OAuth/OIDC gateway, or a different DB layer) would be used in a tight-knit +manner to Kanidm then it is no longer a microservice, but a monolith with multiple +moving parts. This creates production fragility and issues such as: + +* Differences and difficulties in correlating log events +* Design choices of the project not being compatible with Kanidm's model +* Extra requirements for testing/production configuration + +This last point is key. It is a critical part of kanidm that the following must +work on all machines, and run every single test in the suite. + +``` +git clone https://github.com/kanidm/kanidm.git +cd kanidm +cargo test +``` + +Not only this, but it's very important for quality that running `cargo test` truly tests the +entire stack of the application - from the database, all the way to the client utilities and +other daemons communicating to a real server. Many developer choices have already been made to +ensure that testing is the most important aspect of the project to ensure that every feature is +high quality and reliable. + +Additon of extra projects or dependencies, would violate this principle and lead to a situation +where it would not be possible to effectively test for all developers. + +Why don't you use Raft/Etcd/MongoDB/Other to solve replication? +--------------------------------------------------------------- + +There are a number of reasons why these are generally not compatible. Generally these databases +or technolgies do solve problems, but they are not the problems in Kanidm. + +## CAP theorem + +CAP theorem states that in a database you must choose only two of the three possible +elements: + +* Consistency - All servers in a topology see the same data at all times +* Availability - All servers in a a topology can accept write operations at all times +* Partitioning - In the case of a network seperation in the topology, all systems can continue to process read operations + +Many protocols like Raft or Etcd are databases that provide PC guarantees. They guarantee that +they are always consistent, and can always be read in the face of patitioning, but to accept +a write, they must not be experiencing a partitioning event. Generally this is achieved by +the fact that these systems elect a single node to process all operations, and then re-elect +a new node in the case of partitioning events. The elections will fail if a quorum is not met +disallowing writes throughout the topology. + +This doesn't work for Authentication systems, and global scale databases. As you introduce non-negligible +network latency, the processing of write operations will decrease in these systems. This is why +Google's Spanner is a PA system. + +PA systems are also considered to be "eventually consistent". All nodes can provide reads and writes +at all times, but during a network partitioning or after a write there is a delay for all nodes to +arrive at a consistent database state. A key element is that the nodes perform an consistency operation +that uses application aware rules to allow all servers to arrive at the same state *without* +communication between the nodes. + +## Update Resolutionn + +Many databases do exist that are PA, such as CouchDB or MongoDB. However, they often do not have +the properties required in update resoultion that is required for Kanidm. + +An example of this is that CouchDB uses object-level resolution. This means that if two servers +update the same entry the "latest write wins". An example of where this won't work for Kanidm +is if one server locks the account as an admin is revoking the access of an account, but another +account updates the username. If the username update happenned second, the lock event would +be lost creating a security risk. There are certainly cases where this resolution method is +valid, but Kanidm is not one. + +Another example is MongoDB. While it does attribute level resolution, it does this without the application +awareness of Kanidm. For example, in Kanidm if we have an account lock based on time, we can select +the latest time value to over-write the following, or we could have a counter that can correctly +increment/advance between the servers. However, Mongo is not aware of these rules, and it would +not be able to give the experience we desire. Mongo is a very good database, it's just not the +right choice for Kanidm. + +Additionally, it's worth noting that most of these other database would violate the previous +desires to keep the language as Rust and may require external configuration or daemons which +may not be possible to test. + + diff --git a/kanidm_rlm_python/eap b/kanidm_rlm_python/eap index c9149f37a..b4984de26 100644 --- a/kanidm_rlm_python/eap +++ b/kanidm_rlm_python/eap @@ -24,14 +24,14 @@ eap { # then that EAP type takes precedence over the # default type configured here. # - default_eap_type = md5 + default_eap_type = peap # A list is maintained to correlate EAP-Response # packets with EAP-Request packets. After a # configurable length of time, entries in the list # expire, and are deleted. # - timer_expire = 60 + timer_expire = 90 # There are many EAP types, but the server has support # for only a limited subset. If the server receives @@ -626,7 +626,7 @@ eap { # EAP conversation, then this configuration entry is # ignored. # - default_eap_type = md5 + default_eap_type = mschapv2 # The tunneled authentication request does not usually # contain useful attributes like 'Calling-Station-Id',