i-Tego >  Documentation >  Authentification > OpenID Connect OAuth Serveur dédié > Développer > Démarrer

Installation, Configuration, Création des auteurs-concepteurs des applications, Tests, Inscription des applications, Adaptation des applications.

Installation du serveur OAuthSD

  publié le par DnC

L’installation d’un serveur OAuthSD se fait dans un environnement Linux décrit dans cet article.

Bien que faisant appel à Composer, cette installation est en partie manuelle, ainsi que la configuration du serveur et le chargement d’un jeu initial de données.

Prérequis

- hôte Linux : CentOs 6.5 ou 7 (préféré), CloudLinux 6 ou 7, RHEL 6 ou 7, [1]. Voir les détails au paragraphe : "Environnement matériel et logiciel du serveur".

Pour installer et administrer la configuration décrite ci-dessous, il sera utile de disposer d’un "panneau d’administration" pour la gestion de l’hôte et des serveurs. WHM/cPanel est un bon choix [2]. On peut également utiliser Webmin.

- serveur Apache 2.x [3]. La sécurité de fonctionnement d’OIDC exige une installation sur un domaine sécurisé par TLS (protocole https://).
- PHP 5.6 ou 7.x (7.x obligatoire si /crud/api.php est installé) [4].
- serveur de base de données MySQL ou équivalent [5] + phpMyAdmin (ou équivalent)
- serveur sshd/sFTP,
- client SSH (console et sFTP), accès par l’user root.

Installation d’OAuthSD

1. Installer le code d’OAuthSD

- Télécharger le code depuis GitHub : https://github.com/bdegoy/oauthsd, -> ’Clone or download" -> "Download ZIP.
- Installer le contenu dé-zippé dans le répertoire web du domaine(web document root) [6] .

2. Installer et exécuter Composer

Voir : Installer (ou mettre à jour) OAuthSD avec Composer .

- Ouvrir un client SSH,
- se déplacer dans le répertoire web du domaine, exemple pour CentOS :
user@mon.site.com [~]# cd public_html

- Si le code d’OAuthSD comporte le fichier /composer.phar et le dossier /composer/, alors Composer est déjà téléversé sur l’hôte pour une utilisation locale. En cas de doute, vous pouvez vérifier l’installation de Composer en suivant les indications de cet article : Installer (ou mettre à jour) OAuthSD avec Composer .

- Sinon, se reporter à l’installation de Composer. Le plus simple est une installation locale (dans le répertoire web du domaine).

- Exécuter user@mon.site.com [~]# composer install.

A l’issue, les packages utilisés par OAuthSD se trouvent installés dans le dossier /vendor.

3. Initialiser les données
- avec le client SSH, accéder au serveur MySQL et exécuter le contenu du fichier : /install/data.sql.

4. Configuration initiale

- Connexion à la base de données : ouvrir le fichier /commons/keepsecret/database.php ; dans la fonction make_credentials, inscrire les valeurs correctes pour dmname, host, driver, port et prefix.

- Si la version téléchargé inclut l’API HTTP REST + TreeQL (répertoire http.api), il convient d’adapter les valeurs du fichier de configuration /http.api/api_configure.php.

- Options et réglages : les valeurs par défaut suffisent dans la plupart des cas. Pour plus d’information, voir Paramétrage d’OAuthSD.

5. Créer un répertoire pour les sessions d’OAuthSD
- créer un répertoire "sessions_oauthsd" un niveau au dessus du répertoire web du domaine.
- attribuer à ce répertoire le même user/group et les mêmes permissions que le répertoire web du domaine.

6. Programmer une tâche Cron

Le script cron.php doit être appelé toutes les minutes afin d’exécuter différentes tâches dont l’élaboration de synthèses statistiques (table oidc_stats).

Une tâche cron est programmée pour exécuter toutes les minutes la commande suivante (exemple pour Linux) :
wget -O /dev/null https://<serveur-url>/cron/cron.php >/dev/null 2>&1

Environnement matériel et logiciel du serveur

Connexion au réseau : routeur et firewall
Un serveur OIDC est sensible aux attaques par déni de service. On évitera de router les paquets TCP entrants à l’aide d’une DMZ. On préfèrera configurer un filtrage de port au niveau du routeur/firewall et une règle de routage NAT/PAT pour lier le port entrant (443) à l’IP fixe du serveur sur le réseau local.
Un Pare-feu à états (stateful inspection firewall) serait favorable pour faire face aux attaques de type DDOS. Un routeur/firewall dédié à la connexion du serveur serait favorable à l’adoption de paramètres de filtrage adaptés.

Matériel, RAM et Disques
Un serveur OIDC doit répondre rapidement à de nombreuses requêtes. Une machine dédiée à OAuthSD serait favorable. Le processeur doit être performant (2 à 4 cœurs), la mémoire suffisante ; un disque SSD serait favorable.
RAM : 4 GB minimum.
Partition / : 40GB minimum.
Partition swap : même taille que la RAM.

Sauvegarde
Il faut prévoir un disque interne dédié à la sauvegarde ainsi qu’une sauvegarde externe. Les sauvegardes pourront être réalisées à l’aide du panel d’administration du serveur. La capacité du disque de sauvegarde interne sera égal à 3 fois au moins la capacité du disque principal.

Administration à distance
Il est utile de disposer d’un tunnel SSH ou VPN pour accéder au panneau d’administration ainsi qu’au serveur sshd à l’aide d’une console distante.

Connexion Internet pour les tests
Certains tests nécessitent la connexion du serveur au réseau Internet. Il en est ainsi par exemple des tests décrits dans la rubrique Tests et certification. Cette connexion peut-être fermée par la suite si le serveur doit fonctionner dans un réseau local ou privé.

Avertissement quant aux proxies
Si un proxy doit être installé en amont du serveur ( par ex. un répartiteur de charge), il est important qu’il ait une IP fixe vu du serveur OAuthSD et qu’il transmette l’IP de la requête d’origine par la déclaration HTTP_X_FORWARDED_FOR.
Voir Vérification de l’origine de la requête reçue par un serveur de ressource.

Notes

[1] Désactiver SELinux.

[2] Offrant notamment le stateful firewall CSF-LFD, l’outil de configuration EasyApache, des outils de sécurité avec un audit très complet et permettant de configurer facilement un certificat SSL/TLS pour un fonctionnement en https://.

[3] Nginx incompatible. Ne pas configurer de proxy inverse

[4] Autoriser allow_url_fopen dans php.ini.

[5] PostGres SQL incompatible.

[6] C’est à dire le répertoire /public_html (dans le cas de CentOS). Notez que OAuthSD comprend un répertoire /public_html/web/ : ne pas confondre !

Paramétrage d’OAuthSD

  publié le par DnC

Configuration obligatoire au démarrage

L’adaptation du fichier /commons/keepsecret/database.php est la seule configuration obligatoire lors d’un nouveau déploiement du serveur OAuthSD.


- fichier /commons/keepsecret/database.php.
Il permet de définir la connexion à la base de données et doit contenir le code suivant :

  1. /** Database
  2. * $dsn is the Data Source Name for your database, for example "mysql:dbname=my_oauth2_db;host=localhost"
  3. */
  4. $connection = array(
  5. *        'dsn' => 'mysql:dbname=...;host=localhost',  // MySQL
  6. *        'username' => '...',
  7. *        'password' => '...'
  8. *    );

Télécharger

Options TFA par SMS

Si l’identification à deux facteurs avec SMS est activée (constante ’TFA_PROVIDER’ = ’checkbysms’), le fichier /commons/keepsecret/sms.php doit contenir les identifiants de connexion à l’API OVH SMS :

  1. define('OVHSMSAPI_APPLICATIONKEY','...');    
  2. define('OVHSMSAPI_APPLICATIONSECRET','...');
  3. define('OVHSMSAPI_CONSUMER_KEY','...');
  4. define('OVHSMSAPI_ENDPOINT','ovh-eu');
  5. define('OVHSMSAPIUSER', 'OAUTHSD');

Télécharger

Vous devez avoir un compte valide sur l’API SMS d’OVH. Les identifiants sont obtenus avec la requête suivante :

https://api.ovh.com/createToken/index.cgi?GET=/sms&GET=/sms/*&PUT=/sms/*&DELETE=/sms/*&POST=/sms/*

Autres options

Les fichiers /commons/configure_oauth.php et /commons/configure_oidc ne nécessitent pas de modification pour une première configuration. On se reportera aux titres et commentaires des constantes.

Installer (ou mettre à jour) OAuthSD avec Composer

  publié le par DnC

Lancer un client SSH avec l’utilisateur du domaine

Il ne faut pas exécuter composer en root.
Pour accéder à notre serveur, on configure un terminal SSH avec les identifiants de l’utilisateur du domaine. Dans notre exemple, le domaine est "domain" et l’utilisateur est "username".

Note :
- les exemples de code correspondent à CentOS.
- Il faut vérifier que cet utilisateur appartient au groupe "wheel" des sudoers. Si ce n’est pas le cas, exécuter (en root) :
root@mon.site.com [~]#usermod -aG wheel username

On se place dans le cas d’une installation locale de Composer, c’est à dire dans le dossier racine des documents web (web document root).

username@domain [~]# cd public_html

1° Méthode : avec le script go_xxx.sh

Il existe (à l’heure actuelle) deux scripts, selon que l’on installe OAuthSD avec une base de données PostgreSql ou MySQL : go_pgsql.sh et go_mysql.sh.

Prérequis

- un domaine nommé "domain"
- un utilisateur nommé "user" est propriétaire du domaine avec le mot de passe "user_pswd"

Contrairement à go_mysql.sh (pour MySQL), le script go_pgsql.sh n’installe pas
PostgreSQL ety ne crée pas la base de données ni l’utilisateur. Il faudra donc :

- Installer PostgreSQL
- créer une base de données avec les identifiants suivants (exemple) :
Nom de la base de données "database" (oauthsdc_data)
Utilisateur : "database_user" (oauthsdc_user)
Mot de passe : "database_user_pswd" (oautW...!)

Procédure d’installation avec go_xxx.sh

La procédure est la suivante :
- dans le répertoire des documents du serveur web du domaine (document root), créer un répertoire /install et y recopier le fichier go_xxx.sh.
- 1 - Copier le script go_pgsql.sh dans un répertoire /install à la racine web.

2 - ouvrir un client SSH sur "domain" avec l’utilisateur "user" et le mot de passe "user_pswd".

3 - lancer go_pgsql.sh :
@ [ ]# sh public_html/install/go_pgsql.sh
(le script fait appel à Composer pour installer le code depuis GitHub)

Si tout va bien, vous devez obtenir quelque chose comme :

"Composer is installed
>>> Updating Composer
You are already using composer version 1.9.0 (stable channel).
>>> Installing OAuthSD
Clearing cache (cache-vcs-dir): /home/oauthsdc/.composer/cache/vcs
Clearing cache (cache-repo-dir): /home/oauthsdc/.composer/cache/repo
Clearing cache (cache-files-dir): /home/oauthsdc/.composer/cache/files
Clearing cache (cache-dir): /home/oauthsdc/.composer/cache
All caches cleared.
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
 - Installing bdegoy/oauthsd-c (0.1.0): Cloning master from cache
Writing lock file
Generating autoload files
OK"

2° Méthode : installation manuelle

Vérifier l’installation de Composer

Exécuter :
username@domain [~/public_html]# composer diagnose

Retourne :

Checking composer.json: WARNING
Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: OK
Checking https connectivity to packagist: OK
Checking github.com rate limit: OK
Checking disk free space: OK
Checking pubkeys: FAIL
Missing pubkey for tags verification
Missing pubkey for dev verification
Run composer self-update --update-keys to set them up
Checking composer version: OK
Composer version: 1.9.0
PHP version: 5.6.40
PHP binary path: /opt/cpanel/ea-php56/root/usr/bin/php

Nous avons un problème avec les clés publiques de Composer. Lançons :
username@mon.site.com [~/public_html]# composer self-update --update-keys

Comme indiqué, il faudra naviguer à l’URL https://composer.github.io/pubkeys.html pour copier ces clés et les coller comme demandé :

Open https://composer.github.io/pubkeys.html to find the latest keys
Enter Dev / Snapshot Public Key (including lines with -----): -----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAnBDHjZS6e0ZMoK3xTD7f
...
wSEuAuRm+pRqi8BRnQ/GKUcCAwEAAQ==
-----END PUBLIC KEY-----
Stored key with fingerprint: 4AC45767 E5EC2265 2F0C1167 CBBB8A2B  0C708369 153E328C AD90147D AFE50952
Enter Tags Public Key (including lines with -----): -----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA0Vi/2K6apCVj76nCnCl2
...
TzCFWGk/HM6a4f0IzBWbJ5ot0PIi4amk07IotBXDWwqDiQTwyuGCym5EqWQ2BD95
RGv89BPD+2DLnJysngsvVaUCAwEAAQ==
-----END PUBLIC KEY-----
Stored key with fingerprint: 57815BA2 7E54DC31 7ECC7CC5 573090D0  87719BA6 8F3BB723 4E5D42D0 84A14642
Public keys stored in /home/user/.composer

Nous pouvons vérifier à nouveau Composer :

username@domain [~/public_html]# composer diagnose
Checking composer.json: OK
Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: OK
Checking https connectivity to packagist: OK
Checking github.com rate limit: OK
Checking disk free space: OK
Checking pubkeys:
Tags Public Key Fingerprint: 57815BA2 7E54DC31 7ECC7CC5 573090D0  87719BA6 8F3BB723 4E5D42D0 84A14642
Dev Public Key Fingerprint: 4AC45767 E5EC2265 2F0C1167 CBBB8A2B  0C708369 153E328C AD90147D AFE50952
OK
Checking composer version: OK
Composer version: 1.9.0
PHP version: 5.6.40
PHP binary path: /opt/cpanel/ea-php56/root/usr/bin/php

Cette fois-ci c’est bon.

Mettre à jour de Composer

username@domain [~/public_html]# composer self-update
Si Composer était à jour, on obtient :
You are already using composer version 1.9.0 (stable channel).

Installer le code d’OAuthSD ou vérifier l’installation

L’installation ou la vérification se fait en exécutant :
username@mon.site.com [~/public_html]# composer install

Si OAuthSD est déjà installé et complet, on obtient :

Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Nothing to install or update
Generating autoload files

"Installing dependencies (including require-dev) from lock file" signifie qu’une installation avait déjà été effectuée. La mise à jour conserve les versions des composants (inscrites dans le fichier composer.lock) de la version courante d’OAuthSD. C’est important pour assurer la cohérence de l’ensemble du code par rapport à la dernière version stable.

Mettre à jour le code d’OAuthSD

Attention ! une mise à jour du code avec les dernières versions des composants n’est pas recommandée à moins qu’une nouvelle version stable d’OAuthSD ait été notifiée comme prête pour la mise à jour.

La mise à jour se fait en exécutant :
username@domain [~/public_html]# composer update

Notre application était à jour des derniers développements, ainsi que les composants. On obtient donc :

Loading composer repositories with package information
Updating dependencies (including require-dev)
Nothing to install or update
Generating autoload files

"Updating dependencies (including require-dev)" signifie que les composants auraient été mis à jour dans leur dernière version. Un nouveau fichier composer.lock est créé.

Après l’installation

4 - ouvrir en édition /commons/keepsecret/database.php et inscrire les identifiants
de connexion à la base de données.

5 - Initialiser les données avec le contenu du fichier /install/data.sql

6 - tester le fonctionnement avec https://"domain"/oidc/tests/essai1.php

Echec avec les messages : "remote : Invalid username or password

Ceci signifie que :
- Le repository GitHub est privé,
- les clés SSH sont manquantes ou erronées.

Se connecter sur le compte GitHub.
- Dans Settings -> SSH and GPG Keys, vérifier qu’il existe une SSH Key pour le domaine oauthsd-c
Si c’est le cas :
- vérifier qu’il existe un dossier /home/oauthsdc/.ssh/ et contrôler que la clé
publique id_rsa_pub est identique au champ Key (ce n’est probablement pas le cas).
Si ce n’est pas le cas :
- Installer une paire de clés dans /home/oauthsdc/.ssh/ (fichiers id_rsa, id_rsa.pub et known_hosts)
générer les clés :
- ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
Enter file in which to save the key (/home/oauthsdc/.ssh/id_rsa) : etc...
- ouvrir le fichier id_rsa.pub, copier son contenu
- côté GitHub, actionner "New SSH Key"
- coller le contenu dans le champ Key
- Dans le champ Title, indiquer le nom du serveur et le domaine (ex : vpsxxx-domain)