Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/unistra/jwt-server
https://github.com/unistra/jwt-server
Last synced: 10 days ago
JSON representation
- Host: GitHub
- URL: https://github.com/unistra/jwt-server
- Owner: unistra
- License: apache-2.0
- Created: 2020-10-29T09:48:45.000Z (about 4 years ago)
- Default Branch: develop
- Last Pushed: 2024-09-06T13:19:24.000Z (2 months ago)
- Last Synced: 2024-09-06T15:08:47.080Z (2 months ago)
- Language: Python
- Size: 999 KB
- Stars: 0
- Watchers: 8
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# JWT server
Serveur de JSON web token à partir de tickets CAS.
## Objectifs
- Proposer un service de JWT
- Permettre d'accéder à quelques données individuelles supplémentaires## Fonctionnement
### Clés
Le serveur utilise des clés RSA, qui doivent être présentes dans un répertoire `keys` à la racine.
- `myKey.pem` : clé privée, utilisée pour signer les tokens
- `myPublic.pem` : clé publique, utilisée pour vérifier les tokensLe mot de passe de la clé est déclaré dans le paramètre `RSA_PASSWORD`
### Déclaration de service
Les services doivent être déclarés pour pouvoir obtenir un token.
À l'aide de l'interface d'admin ou dans la BDD, il faut renseigner
le champ `data` de la table `AuthorizedService` avec
un *JSONField* de la forme :
```json
{
"fields": {
"username": "uid",
"affiliations": [
"eduPersonPrimaryAffiliation",
"eduPersonAffiliation"
],
"directory_id": "udsDirectoryId",
"organization": "supannEtablissement"
},
"service": "127.0.0.1:8000",
"conditions": {
"ldap_filters": [],
"ldap_must_exist": false
}
}
```Le token généré contient alors :
```json
[
{
"typ": "JWT",
"alg": "RS256"
},
{
"token_type": "access",
"exp": 1593528195,
"jti": "ead170f3a3dd4c8eb1d10b21f23b4e63",
"user_id": "not.a.real.uid",
"iss": "127.0.0.1:8000",
"sub": "not.a.real.uid",
"nbf": 1593520995.627925,
"username": "not.a.real.uid",
"affiliations": [
"employee",
"member",
"faculty"
],
"directory_id": "01234",
"organization": "UDS"
}
]
```- `service` correspond à l'adresse autorisée à faire appel aux token
- `fields` permet de définir les champs remontés depuis le LDAP :
- la clé est le nom utilisé dans le token, la valeur correspond au champ attendu depuis le LDAP
- on peut utiliser un champ unique ou la composition de plusieurs champs
### Personnalisation de l'émetteurIl est possible de surcharger l'emetteur du token (champ `iss` du token) en introduisant une clé `issuer` dans le champ `data`.
### Ajout de conditions d'accès
Il est possible d'ajouter des conditions supplémentaires en rajoutant un clé `conditions` au champ `data` du service.
La clé `conditions` peut avoir une sous-clé `ldap_filters` qui est une liste de filtres supplémentaires ajoutés à
la requête LDAP.Par exemple :
```json
{
"conditions": {
"ldap_filters": ["memberOf=cn=group-name,ou=groups,o=org"]
}
}
```
Donnera la requête : `(&(uid=username)(memberOf=cm=group-name,ou=groups,o=org)`Par défaut, si aucune entrée n'est trouvée dans le LDAP, un token sera tout de même généré.
La condition `"ldap_must_exist": true` génèrera une réponse `403 Forbidden`.
### Vérification de fonctionnement
Une route `/api/service/` permet de générer un token.
En local, vous devriez donc avoir une réponse sur [http://127.0.0.1/api/service/](http://127.0.0.1/api/service/)
## Développement
### Exemple de fichier `bin/postactivate`
```shell script
#!/bin/zsh
# This hook is sourced after this virtualenv is activated.
export DJANGO_SETTINGS_MODULE=jwtserver.settings.devexport RSA_PASSWORD='iamnotarealpassword'
export JWT_ACCESS_LIFETIME='120'
export JWT_REFRESH_LIFETIME='1'export LDAP_SERVER='ldap.example.none'
export LDAP_USER='ou=toto,o=annuaire'
export LDAP_PASSWORD='stillnotarealpassword'export DB_HOST="localhost"
export DB_USER="jwt"
export DB_PWD="jwt"
export DB_NAME="postgres"
```