libipc
services.
bin | ||
spec | ||
src | ||
.gitignore | ||
db-password-file | ||
makefile | ||
project.zsh | ||
README.md | ||
shard.yml | ||
TODO.md |
authd
authd is a token-based authentication micro-service.
TODO: explain basic concepts behind
authd
.
Build
authd
is written in Crystal.
You’ll need the following tools:
- crystal
- shards
- make
To build authd, run the following commands:
make
Deployment
$ 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
authd’s protocol is still subject to change.
TODO: document messages.
Libraries
TODO: document basic functions in the
AuthD::Client
class to exchange messages withauthd
.
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.