Skip to content
Snippets Groups Projects
Commit 9b45682a authored by kaiyou's avatar kaiyou
Browse files

Update hiboo admin docs

parent 719ef5e5
No related branches found
No related tags found
No related merge requests found
......@@ -2,8 +2,84 @@
title: hiboo
---
# Objectifs
## Contexte
# Projet
L'authentification est l'une des clés de voûte de la sécurité en ligne,
pourtant les technologies associées ont peu évolué en apparence depuis 50
ans : l'utilisateur dispose d'un identifiant et d'un mot-de-passe.
# Historique
\ No newline at end of file
L'authentification, en particulier en entreprise, a toutefois vu les
familles d'implémentation évoluer :
- historiquement, chaque application embarquait une base d'authentifiants,
multipliant le stockage, souvent du même mot de passe bien qu'il y soit
possible de disposer de mots de passe distincts ;
- des annuaires centralisés, de type LDAP par exemple, ont permis aux
applications de recevoir et de déléguer la vérification du mot de passe,
simplifiant le stockage mais créant autant de points de faiblesse comme
toutes les applications accèdent au mot de passe ;
- des systèmes de jetons permettent aujourd'hui à un service
d'authentification tiers de générer des jetons à usage limité que
l'utilisateur envoie à l'application.
CAS, Kerberos et SAML comptent parmis les systèmes de jetons les plus
populaires, mais ils sont complexes de mise en place et aujourd'hui très peu
implémentés dans l'auto-hébergement sur Internet, au profit des deux
approches plus classiques.
Les protocoles modernes pour le Web tels que OAuth2 et OpenID Connect
disposent d'implémentations plus faciles, et sont supportés par un nombre
grandissant d'applications. Leur implémentation au profit d'un fournisseur
public présente toutefois ses risques : un mot de passe faible et toutes
les applications sont impactées, un utilisateur pourrait ne pas souhaiter
apparaître partout avec une identité unique, etc.
hiboo vise à construire un service de gestion d'identité supportant OpenID
Connect (et SAML2) à destination des fournisseurs publics tels que les
hébergeurs associatifs. Il met l'accent sur la simplicité de déploiement
et la grande souplesse offerte à l'utilisateur, qui peut s'inscrire ou pas à
certaines applications, voire utiliser des comptes multiples et des pseudonymes
sur certaines.
## Projet
hiboo est conçu non pas comme un fournisseur d'identité unique, mais comme
une plateforme de gestion d'hébergeur, où chaque application est configurée
et constitue un fournisseur d'identité à part entière.
L'utilisateur est libre de s'inscrire sur hiboo, puis de :
- s'inscrire à la vollée sur les applications ouvertes, y compris en
choisissant son pseudonyme ;
- inscrire de nouveaux comptes sur les mêmes applications dans les limites
indiquées, puis de choisir le compte désiré à chaque connexion ;
- demander des comptes sur les applications où l'inscription est
supervisée par un administrateur ;
- supprimer ses comptes, voire ordonner la suppression de ses données
personnelles.
hiboo embarque en outre des outils à destination des modérateurs et administrateurs,
afin de gérer les applications, y compris en s'interfaçant avec les API des
logiciels les plus répandus pour y bloquer, supprimer, ou valider des comptes.
Le projet consiste à développer un logiciel déployable et la documentation associée,
qui embarque la logique de base d'un fournisseur d'identité multi-applications,
et les patrons de conception et d'interactions avec les logiciels les plus répandus
chez les fournisseurs de services.
## Symbolique
Le projet est nommé « hiboo », conformément à la convention de nommage de ACIDES,
et en référence au hibou, qui veille sur la forêt.
Le logo du projet est un hibou dessiné selon la convention graphique de ACIDES.
## Historique
Le projet hiboo a débuté en septembre 2019 afin de centraliser l'authentification
de l'hébergement proposé par l'association TeDomum. Il a d'abord supporté
l'authentification Gitlab, Grafana et Synapse, avant de supporter fin 2020
l'authentification sur une dizaine de services différents.
Les fonctionnalités et les concepts ont évolué, en particulier les notions de
« compte » et de « profil », pour se stabiliser fin 2020.
---
title: Architecture
---
\ No newline at end of file
---
## Architecture applicative
Hiboo est une application monolotithique, il ne possède pas de système d'extension ou de plugin. Il embarque donc l'ensemble des fonctionnalités, pour tous les protocoles supportés et tous les logiciels supportés, sans possibilité de restreindre ces fonctionnalités.
Ce parti pris alourdit légèrement l'application dans son ensemble mais facilite sa maintenance à l'échelle du projet, comme le nombre de contributeurs ne permet pas de maintenir un écosystème dynamique avec des interfaces d'extensions.
## Concepts
### Service et application
Dans hiboo, un « service » représente un service tel qu'il est mis à disposition par l'hébergeur employant hiboo. Le service hiboo est confondu avec la notion de *Service Provider* lorsqu'il emploi l'authentification SAML2 ou de *client* lorsqu'il emploie l'authentification OpenID Connect.
Une application est un modèle de service implémentant les spécificités des logiciels supportés par hiboo. Il existe ainsi des applications génériques, définissant la configuration d'un service SAML2 ou OpenID Connect sans présager du logiciel employé et laissant libre l'administrateur ; et des applications spécifiques (par exemple Gitlab, Mastodon, etc.) dont l'implémentation précise l'interaction entre hiboo et le logiciel en question.
Une application peut implémenter les spécificité de l'authentification sur le logiciel, du cycle de vie des profils utilisateur, mais également des fonctions à destination des utilisateurs ou administrateurs. En outre, une application peut embarquer de la documentation spécifique pour faciliter l'intégration de hiboo avec le logiciel visé.
Chaque service précise quelle application il emploie et la configuration spécifique éventuellement associée. Un service est donc en quelque sorte une instance d'application. Hiboo étant conçu et distribué de façon monlithique, les applications sont codées en dur et non stockées dans la base de données, tandis que chaque service dispose d'une entrée spécifique en base de données.
### Compte et profil
Dans hiboo, un utilisateur dispose d'un unique « compte », qui lui permet de s'authentifier sur hiboo. Ce compte est caractérisé par un nom d'utilisateur et une configuration d'authentification (hiboo support actuellement uniquement une authentification par mot-de-passe).
Un utilisateur dispose également de « profils » par service, qui lui permettent de s'authentifier auprès du service. Chaque profil est caractérisé par un nom de profil, transmis à l'application, qui n'est pas nécessairement identique au nom d'utilisateur. En fonction de la configuration du service, un utilisateur peut disposer de multiples profils sur un même service, auquel cas il doit choisir à chaque authentificaiton le profil à employer.
Lorsque la configuration le permet, à la première connexion d'un utilisateur à un service, hiboo propose donc la création d'un profil, en employant un nom de profil si possible identique au nom d'utilisateur.
### Etats
Les profils dans hiboo disposent d'un état (`status`), soumis à une machine à état décrite sur la page [cycles de vie](lifecycles.md). Le comportement des états d'un profil dépendent de la logique générale de la machine à état et de la logique spécifique de l'application employée par le service auquel le profil est rattaché.
\ No newline at end of file
......@@ -2,7 +2,7 @@
title: Environnement de tests
---
Tester Hiboo nécessite le déploiement de multiples composants pour simuler des
Tester hiboo nécessite le déploiement de multiples composants pour simuler des
applications interagissant avec. La configuration suivante permet de
déployer localement :
......@@ -10,6 +10,8 @@ déployer localement :
- un serveur Mastodon
- un serveur Writefreely
L'environnement de tests ne contient pas d'instance de hiboo. Il est nécessaire d'employer votre environnement de développement hiboo en complément.
# Installer Docker et Compose
Installer Docker depuis la configuration sur Docker CE :
......@@ -23,10 +25,10 @@ par exemple les dépôts de la distribution.
# Préparer le lab
Récupérer le projet de lab dans un dossier `lab` :
Récupérer le projet de tests :
```
git clone https://forge.tedomum.net/acides/hiboo-lab lab
git clone https://forge.tedomum.net/acides/hiboo/lab
cd lab
```
......@@ -63,12 +65,18 @@ docker-compose run --rm writefreely db init
# Démarrer et arrêter les serveurs
Pour démarrer le tout :
Pour démarrer l'ensemble des services :
```
docker-compose up -d
```
Ou bien démarrer simplement `hiboo` et `synapse` :
```
docker-compose up -d hiboo synapse
```
Pour stopper le tout :
```
......@@ -77,9 +85,15 @@ docker-compose down
# Accéder aux serveurs
Idéalement, remplacez 127.0.0.1 par l'adresse LAN de votre carte réseau.
Afin d'accéder aux services et de les configurer dans hiboo, il est nécessaire d'employer non pas `127.0.0.1` mais l'adresse hôte de la carte virtuelle Docker, afin que le navigateur utilisateur, hiboo et les applications puissent se joindre à une adresse unique. Pour cela, remplacez dans les URL à suivre `<address>` par l'adresse de la carte virtuelle Docker.
- Synapse : `http://<address>:8008`
- Element : `http://<address>:8009`
- Mastodon : `http://<address>:3000`
- Writefreely : `http://<address>:8080`
- Synapse : http://127.0.0.1:8008
- Element : http://127.0.0.1:8009
- Mastodon : http://127.0.0.1:3000
- Writefreely : http://127.0.0.1:8080
\ No newline at end of file
Afin de démarrer Hiboo localement, employez l'adresse de votre carte virtuelle Docker :
```
flask run --host <address>
```
\ No newline at end of file
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment