create a new macro with a form similar to try_audit!(audit, result, "message, <format args ...>);
This will help save code reuse instead of using a match statement every time we need to check if a result from a function call that is just going to return Ok(()) or log the error and return Err()

Support password-less authentication to the anonymous user account.

The current design is an actix web front end that transform proto -> requests. These requests go to the query server threads that then dispatch them to a "backend", which then accesses the (incorrectly named) backend of the idl layer.

The query server actors should choose the backend, and we should move the current query server logic to "backend". Then after that, we should move the current 'backend" for idl parts to a proper idl component.

The idea is to allow re-use of the backend in other applications (such as the client tools which may need a cache type), and to then have the front end actix-web + requests layer able to use a different backend such as ldap via a translation layer.

After the uuid is generated, if the class supports uidnumber/gidnumber, we should template these based on the uuid that was generated.

Support mschapv2 for radius, along with an rlm module for freeradius to operate with.

Support idlset indexing for eq/pres/sub on all attributes.

Today we serialise the server Entry struct to the DB, but this serialises some extra fields as part of the state machine for Entry correctness. To avoid this, we should have a seperate DBEntry type which has into/from Entry, and means we avoid the generics being serialised when they shouldn't be.

This is probably a good chance to switch to cbor in the db records, and to add entry versioning to the db records, given the desire to add value labels. Another possible improvement here is to have uuid from proto-entry split to a real field on the entry/db-entry, but still indexed.

Some places use cowcell, when they should use the concread tree type. This relies on concread's tree being developed, but after that we should check all uses of cowcell, and ensure they match our expectations, potentially opting to cowtree instead. An example is schema which is current a cowcell hashmap, which means the hashmap is cloned every write.

It's common that applications (like email, imap etc), need passwords and can't supply 2fa. Allow generation of passwords for these services, and allow them to have constrained rights related to their operations and interactions.

There are a number of todo's in the code, as well as some unwraps and other code hygiene issues. Make sure these are resolved. The only acceptable place for unwrap is is tests, and really, that should be .expect anyway to help test failure diagnosis

There are a number of use cases for a "shadow" entry type. For example, in webauthn, we need to store and search based on credentials. We could have ssh-keys that only apply to certain tagged types such as an admin-group (and the admin group references the shadow object as the member, but the shadow inherits the parents other attributes).

This is an alternate to the "tagging" value api option.

This should be considered along with auth use cases.

It's likely a shadow entry api would need references types to split to weak and hard, where hard references are deleted on the referent deletion where a weak reference would just remove the reference. Consider shadow -> item, and you delete item, we want to remove shadow, but group -> item, on delete of item we don't want to delete group.

For production deployments we need more config options setup and available, like timeouts and thread options. These should be cli options or autodetected if possible.

Create an integration test that does stress and load testing of the implementation (that is optionally run)

Allow the ability to tag values in an attribute. This will have many future uses, such as seeing which memberOf is direct/indirect, allowing ssh-keys to have security labels assigned (IE a host may only want certain key labels), passwords to have metadata attached.

Some decisions about the correct way to do the labeling, and structure are needed, probably based on use cases. At the moment my current thinking is:

struct AVA {
    attr: String,
    value: Vec<Value>
}

struct Value{
    data: String
    label: Vec<String>
}

Some other considerations are how we manage security of tags/labels and this will depend on the use cases we come up with.

At the moment, in a create references are resolved in isolation as we do the protoEntry -> Entry translation. However, one can easily imagine situations where we create a user and a group containing the user in the same operation, which would fail in this case.

Implement travis CI for the project for PR's and external contributors.

Delete should be re-worked to actually mark objects as "deleted" rather than actually deleting them. This would allow "recovery" of accidentally deleted objects. A major consideration to this is that filters should default inject a "AndNot(class=deleted)" into all searches (unless we are specifically requesting recycled objects).

To achieve this add a new plugin hook for "revive", and trigger refint, then memberof, where memberof will take directmemberof, and will re-add the memberships that remain.

Implement webauthn (which could be consumed from cli tool clients!)

Claims are an important modern security concept, allowing ephemeral, or scoped privileges for each session of authentication or token. Examples are that you may have a claim for interactive logins that allows changing your own displayname, but your "email" token does not have this claim so can not change your name. Another example is the github style "sudo" mode which is a time limited claim allowing modification of passwords or 2fa tokens.

This means claims should:

• Be inherited from groups to "allow" access of the claim
• The claim is "associated" to a credential, IE interactive pw + mfa, or a api password type.
• The claim is added to the userAuthToken
• The claim is processed into the current Entry during an operation for auth filters to be applied.
• The claim associated on the credential must be indexed/searchable to allow memberof style removal if you are removed from the group.

In some cases we want to record audit events on objects for transparency. For example, on failed authentication we want to write to the object about the failed authentication. We want to audit account impersonations, password changes, etc.

For some events, these should imply a write to the object itself that allows the object to self-read it's audit information about what has happened and who is using the account.

Currently schema is generated from internal objects. We should leave this as the "minimal", and then have the ability to load schema from the backend at startup to allow custom schema to be created and referenced. We likely need to use migrations to ensure the schema in the db (at least system schema) is "as we expect".

We should support a filter type of "self", which from protoFilter -> Filter translates to eq(uuid, uuid_value).

Additionally, consider how this value could work with acp, because that will require the self type to exist in the future.

There are a number of places in memberof that could be more effecient, avoiding clones and detecting more precisely when MO items change to avoid resolutions. These should be implemented to save cycles on the write path.

We have a concurrently readable structure for in progress authentications. However, we should clean up expired sessions after a period of time. This requires an associated heap that can show us the "next" expiring structure for GC.

We should support proptesting on certain parts of the interface, especially the lower level concepts like filter.

We currently have all attr-values as (String, Vec), however we need to support more complex data types - for example, credentials for IDM will require a complex struct type containing a set of claims, time limits, the credentials themself and more.

However, decoding this from string all the time via b64 cbor would be costly - instead, we should have AVA's support proper "Value" type with an enum, that can return the correct types, and allow encoding more information, doing value-aware operations in replication and more. We can also use this to encode things like CSNs and more.

Finally, this also means we would reduce the need to access schema on compare operations, and we can have more complex indexing outputs IE 1 ava -> many index outputs.

This will be a huge change but it's critical for credential storage and more to support this.

Implement support for TOTP in the authentication system

The server is designed to have a http protocol, an actor protocol, and a query server event system. Each of these are related, but subtely different. However, I have allowed some types to leak between all three. This should be cleaned up.

We should allow a folder of "email: pw" from online account compromises to be read and scanned over the server to check for account compromises. In the same function, we should store a permanent list of passwords that have been compromised so they can never be set by that account, and return a specific error in this case.

By adding ephemeral TLS support, we can have our config use the proper security options in development, not just in production.

It's important we have proper native reference types that we can use in memberof/member.

It would be beneficial to deployments to have an automated/scheduled backup system in the server, to avoid the need to trigger a db backup before you perform a filesystem backup.

Ensure the code and the repo has proper copyright documentation provided

MemberOf adds reverse group membership data to objects. This needs to likely have a way to resolve uuid -> name (to store uuid on the target), group members probably need to store uuid too.

We'll need a way to translate "reference" fields to names in searches, and potentially have derference available. MemberOf should be able to generate and change these reverse-references on updates.

We should create at least a base framework of client tools. This should be:

• pam client
• nsswitch client
• create/modify/delete/search admin tool for users/groups etc
• generic object modification tool
• whoami
• ssh-key tool for ssh key reading

Support authenticating with passwords to accounts

We need to provide backup/restore tooling so that we cane import/export data and give a proper admin experience around this topic.

The sled db project plans to add mvcc as an option. We require this style of transactions so if they support mvcc, we should change from sqlite to sled in our idl layer.

Support a docker deployment, with proper documentation and examples of how to perform tasks (like backups!).

Due to the design of reference types, referential integrity is required as part of the server core to make sure we don't have dangling references.

The server could be built in such a way as to allow a "generic" DB to be built (with some work to split out plugins). To help, the IDM specific migrations should be moved to the IDMServer component, rather than in the QS component, to properly seperate these intents.

Implement account and credential policy, as well as soft lockouts for credentials. This includes potentially auditing logins and credential usages.

To make tests more robust, we should have an inner plugin error type for OperationError::Plugin() so we can assert the correct area of the code did indeed, fail.

At the moment, the query server uses actors as a simple thread pool, but it should be split so that there is a single write actor, multiple read actors, and split idm actors.

Implement access control profiles that can limit creation, modification and delete actions. It's likely a design document should be produced as part of this.

Similar to the entry state machine that is type enforced, we should do the same to filter to distinguish a schema validated filter from a non-validated filter.

There is a large amount of special handling related to the value of UUID: IT would make more sense to make this in protoentry an Option on the struct, and in Entry, on Valid state an Option or String type. This way we avoid many of the get_ava and asserts around checking there is trurly a single value. By using Rust's type system here, we make the code simpler, losing no robust-ness around uuid handling. It would change the entry serialisation format, so this is better to do sooner.

We should have a label or class that prevents (some) modifications, deletions of objects. It should also not be used during creates. This is so that we can mark types as protected to prevent accidental damage.

A consideration is with dynamic schema, we need uses to be able to edit must/may, but not the schema elements themself, so this could be achieved with a system protected access profile, then use that access profile over the schema types.

Perhaps an approach is a self-referring access control that prevents this kind of change?