mirror of
https://github.com/kanidm/kanidm.git
synced 2025-02-23 20:47:01 +01:00
9aa03906f8
This allows configuration of which attribute is presented during gid/uid resolution, adds home directory prefixing, and home directory name attribute selection.
76 lines
3.1 KiB
Markdown
76 lines
3.1 KiB
Markdown
# Developer Principles
|
|
|
|
As a piece of software that stores the identities of people, the project becomes
|
|
bound to social and political matters. The decisions we make have consequences
|
|
on many people - many who never have the chance to choose what software is used
|
|
to store their identities (think employees in a business).
|
|
|
|
This means we have a responsibility to not only be aware of our impact on our
|
|
direct users (developers, system administrators, dev ops, security and more)
|
|
but also the impact on indirect consumers - many of who are unlikely to be in
|
|
a position to contact us to ask for changes and help.
|
|
|
|
## Ethics / Rights
|
|
|
|
If you have not already, please see our documentation on [rights and ethics]
|
|
|
|
[rights and ethics]: https://github.com/kanidm/kanidm/blob/master/ethics/README.md
|
|
|
|
## Humans First
|
|
|
|
We must at all times make decisions that put humans first. We must respect
|
|
all cultures, languages, and identities and how they are represented.
|
|
|
|
This may mean we make technical choices that are difficult or more complex,
|
|
or different to "how things have always been done". But we do this to
|
|
ensure that all people can have their identities stored how they choose.
|
|
|
|
For example, any user may change their name, display name and legal name at
|
|
any time. Many applications will break as they primary key from name when
|
|
this occurs. But this is the fault of the application. Name changes must
|
|
be allowed. Our job as technical experts is to allow that to happen.
|
|
|
|
We will never put a burden on the user to correct for poor designs on
|
|
our part. For example, locking an account if it logs in from a different
|
|
country unless the user logs in before hand to indicate where they are
|
|
going. This makes the user responsible for a burden (changing the allowed login
|
|
country) when the real problem is preventing bruteforce attacks - which
|
|
can be technically solved in better ways that don't put administrative
|
|
load to humans.
|
|
|
|
## Correct and Simple
|
|
|
|
As a piece of security sensitive software we must always put correctness
|
|
first. All code must have tests. All developers must be able to run all
|
|
tests on their machine and environment of choice.
|
|
|
|
This means that the following must always work:
|
|
|
|
git clone ...
|
|
cargo test
|
|
|
|
If a test or change would require extra requirements, dependencies, or
|
|
preconfiguration, then we can no longer provide the above. Testing must
|
|
be easy and accesible, else we wont do it, and that leads to poor
|
|
software quality.
|
|
|
|
The project must be simple. Any one should be able to understand how it
|
|
works and why those decisions were made.
|
|
|
|
## Languages
|
|
|
|
The core server will (for now) always be written in Rust. This is due to
|
|
the strong type guarantees it gives, and how that can help raise the
|
|
quality of our project.
|
|
|
|
## Over-Configuration
|
|
|
|
Configuration will be allowed, but only if it does not impact the statements
|
|
above. Having configuration is good, but allowing too much (IE a scripting
|
|
engine for security rules) can give deployments the ability to violate human
|
|
first principles, which reflects badly on us.
|
|
|
|
All configuration items, must be constrained to fit within our principles
|
|
so that every kanidm deployment, will always provide a positive experience
|
|
to all people.
|