Implements #49, revive directmemberships if possible on revive. As items that are deleted are able to maintain and preserve their directmembership from MO, this allows a way to back-create group memberships when we revive a user from the recycle bin.
Note that if the group was itself deleted and revived, this breaks the relationship because it causes ref int to remove all the references. This could be a reason to change the refint policy to allow keeping dead-references, but I think I want to think about that more before I change that policy too quickly.
Saying this, most groups are long lived, we are really wanting to handle the case where you delete and revive a user, or delete and revive a group to restore consistency. Deletenig and reviveng groups and users at the same time will lead to some hairy-complex cases.
Implements #133, limit password generators to distict human readable characters. This removes the common confusions such as I,l, 1, 0, O, o, m,rn, etc . This in mind, they may not all have been found, but it should be easier now to improve upon.
Implements #29 password badlist and quality checking. This checks all new passwords are at least length 10, pass zxcvbn and are not container in a badlist. The current badlist is a preprocessed content of rockyou from seclists, but later wwe'll update this to the top 10million badlist which when processed is about 70k entries..
Implements #23 gidnumber generation. This automatically creates gid numbers for posixaccounts and posixgroups based on the UUID of the object. Alternately, these can be provided if manual allocation is desired. This is an important step in posix attribute support.
Implements #88, acp_enable becomes optional. This is important with regard to migrations. When we migrate, if an attribute is present in the migration we always set the value in the case of a single-value attribute (multivalues interleave). This means an admin who may set acp_enable to false on default shipped access controls would have them forcefully re-activated on each server restart. This change makes acp_enable optional, and removes it from the migration. If NOT present on an ACP, it's considered "true", so that when an admin overrides this value to false, we will permanently respect that choice.
Implements #127 and #125. This adds domain_info support, and spn types and generation. It also correctly handles domain renaming, and has tooling to support this. It "should" work on an upgrade, due to the correct bump of index version, but I plan to test this from a backup of my production instance soon.
Implements #134 Client Builder Pattern. This makes it much easier to build a client by making the configuration of the client lib follow a builder pattern. The error management needs a lot of work still, but for now it's rough and it works.
Implemnt SSH public key management
This implements ssh public key distribution for kanidm, enforcing that
valid ssh public keys are placed into the ssh_publickey attribute, adds
management tools so that accounts can self-service manage their keys,
and finally adds an authorized keys command helper suitable for
sshd_config to utilise.
Implements #100. This refactors our error types to be deserialiseable, and exposes these through the clienterror type with the status codes. There is probably still a lot of improvements here to be made, but they'll be shaken out as the client libs develop I think and we start to see what errors should be exposed.
Implements #6 - create, modify and delete. These are the raw/lowlevel db commands which are really useful for administrators. They aren't intended for normal day to day use though.
This also adds a basic getting started, fixes a missing privilege, adds support for reseting another accounts password, and for server side password generation.
It's likely I'm going to reformat some of the current REST api though to use our higher level internal types.
This adds rest endpoints for schema, group, account listing and individual item getting, client lib to call these end points, and tests for all of these.
Draft of the idm server rest api layout. This is no means a final representation of what this API will look like, but it's important that the ideas and direction, as well as capabilities were documented and discussed.
Partially Implements #6 - add ability for accounts to self set password. This is good for now, as I get closer to a trial radius deployment, but I think I'm finding the rest api probably needs a better plan at this point, as well as probably the way we do the proto and the communication needs some more thoughts too.
* Implement #90 - allow self write to name, displayname, and legalname.
This is an important aspect to respecting peoples autonomy and identities
so that they can change their name when appropriate to them. Limit self read/write to live accounts, and prevent anonymous self-write
This adds the fundamentals of the basic IDM layout. It contains the needed design document, and is designed such that the default admins while powerful, still have some limits upon them.
