Authentication and authorization server providing tokens for users. Pretty much KISS. Usable by all libipc services.
Go to file
2024-12-02 18:32:58 +01:00
bin Change login policy: accept more characters and don't mind the order. 2024-07-01 20:39:32 +02:00
man Man pages: authd update and new authc documentation. 2024-12-01 12:34:18 +01:00
mk install.mk: add $(Q) + force gzip update of man-pages. 2024-12-02 18:32:58 +01:00
spec Very basic initial spec. 2019-06-29 03:56:06 +02:00
src Fix a few messages + better consistency in naming actions. 2024-12-01 21:32:15 +01:00
.gitignore Compress man-pages before install, remove useless makefile var. 2024-12-01 21:43:52 +01:00
db-password-file initial commit 2018-09-22 17:08:28 +00:00
makefile makefile: LOC envvar. 2024-12-02 15:48:56 +01:00
project.zsh project.zsh: removes useless instructions. 2024-12-01 00:43:05 +01:00
README.md Minor README update (mostly a few links). 2024-12-01 00:41:37 +01:00
shard.yml Next version of DODB, some API changes. 2024-06-01 02:44:53 +02:00
TODO.md TODO: better handling of users's emails. 2024-07-10 17:55:42 +02:00

authd

authd is a token-based authentication micro-service based on libipc.

TODO: explain basic concepts behind authd.

Build

authd is written in Crystal. Youll need the following tools to build it: crystal, shards and make.

make
make install

Run

$ authd --help

TODO: documentation on how to deploy, including with the mail server and tools.

Users storage

The storage directory will default to ./storage.

No SQL database, database management system or other kind of setup is required to run authd and store users.

To migrate an instance of authd, a simple copy of the storage directory will be enough.

Administrating users

TODO: document how to manage users through authc.

APIs

Protocol

authds protocol is still subject to change.

TODO: document messages.

Libraries

TODO: document basic functions in the AuthD::Client class to exchange messages with authd.

A AuthD::Client Crystal class is available to build synchronous clients in Crystal.

Authorization rules

Logged users can:

  • retrieve public data of any user individually
  • change their own data: password, email address, profile entries (except the read-only ones)
  • delete their account
  • check their own permissions

Admins with 'Read' permission on the '*' resource can:

  • list users
  • check permissions of other users

Admins with 'Edit' permission on the '*' resource can:

  • change data of another user

Admins with 'Admin' permission on the '*' resource (or the 'admin' boolean) can:

  • change read-only profile entries
  • change permissions
  • delete a user
  • uprank and downrank admins

Contributing

Pull requests are welcome. For major changes, please open an issue first to discuss what you would like to change.

Please make sure to update tests as appropriate.

WIP: design choices

An user has a number, a login, an email address, a profile (Hash(String, JSON::Any)) and permissions. An admin boolean also tells weither or not the user is an administrator.

Requests work mostly on current user. Some take a UserID to identify another user (its number or its login, both are valid), which often implies admin permissions.

Permissions are: None, Read, Edit, Admin. Plus, the admin boolean value in the AuthD::User class.

TODO: continue explaining design choices.