Accueil > OpenID Connect OAuth Serveur dédié > Le serveur d’authentification que DnC met à votre disposition

Le serveur d’authentification que DnC met à votre disposition

Avertissement : Le serveur OAuthSD installé à l’adresse oa.dnc.global est un démonstrateur et un outil de développement, il peut être indisponible et les données enregistrées effacées à tout moment. Les développeurs intéressés par une version de production de OAuthSD peuvent s’adresser à i-Tego

OAuthSD a été développé avec trois idées directrices : ce devait être un système sanctuarisé dans le domaine d’une organisation pour une meilleure protection des données, particulièrement adapté à sécuriser l’accès aux données selon l’utilisateur et l’application et permettant donc de mieux identifier les applications.

Dans le cadre des applications que i-Tego développe pour ses clients, nous avons pour ambition d’offrir un serveur d’authentification aux fonctionnalités étendues, et proposant un interface utilisateur pratique complété par une documentation accessible.

Tout en restant conforme au standard OpenID Connect, OAauthSD apporte de nombreuses améliorations fonctionnelles.

OAuth Server by DnC est conforme à La norme OAuth 2.0 (RFC 6749) et s’appuie sur la librairie OAuth2 Server Library for PHP développée par Brent Shaffer (voir : http://bshaffer.github.io/oauth2-se...).

Cette API n’assure pas l’identification de l’utilisateur ni la gestion du consentement et encore moins les fonctionnalités avancées décrites ci-après.

DnC a encapsulé cette bibliothèque dans une application serveur, en apportant les développements suivants :

- Le protocole OpenID est implémenté avec des extensions exclusives :

  • Avec les flux OpenID Connect, le contrôleur Authorize est développé pour assurer la SSO et connexion unique (Single Login Identification, SLI) sur de multiples applications, la ré-authentification silencieuse (Silent Re-Authentication, SRA) et la déconnexion unique (Single Login Out, SLO). Voir : SLI, SSO, SLO et SRA sont dans un bateau : OAuthSD. Alors que la plupart des implémentations exigent des développements du côté des applications clientes, OAUthSD vous offre ces fonctionnalités sans aucune modification de celles-ci, pourvu qu’elles soient compatibles avec OpenID Connect.
  • Le monitoring de l’état de l’authentification permet à l’utilisateur final de visualiser l’état de la session OIDC. L’utilisateur est averti de l’imminence de la fin de session et peut la prolonger.
  • Dans un domaine du réseau local contrôlé par Kerberos, OAuthSD utilise l’authentification Kerberos de sorte que l’utilisateur ayant initié une session locale (avec Active Directory s’agissant du système Windows) n’a pas à s’identifier à nouveau pour accéder aux application clientes du serveur OAuthSD.

- OAuthSD complète le noyau OAuth2 :

  • En offrant une API HTTP REST + TreeQL permettant d’intégrer OAuthSD dans un système de gestion des utilisateurs et des applications ainsi que la définition des privilèges.

- OAuthSD offre un interface d’exploitation et une documentation

  • Un interface utilisateur convivial (comme sur ce site web) permet de configurer le serveur et offre une documentation détaillée pour sa mise en œuvre ainsi que pour l’adaptation de vos applications.
  • Des dizaines d’événements différents sont suivis à la microseconde et sont présentés dans des graphes et tableaux interactifs permettant d’identifier avec précision les erreurs et les anomalies significatives d’abus ou de tentative d’intrusion.
  • L’administrateur du serveur est alerté par e-mail des tentatives d’intrusion et des utilisations abusives.
  • Un rôle d’Administrateur d’applications s’ajoute aux rôles définis par la norme : ceux-ci créent et gèrent sur ce serveur les applications clientes dont ils délèguent l’authentification, et dont ils sont donc propriétaires. Ils peuvent également documenter sur le site web du serveur les aspects particuliers du processus d’authentification de leurs applications (ils sont Auteurs au sens de SPIP).
  • Le modèle d’application est étendu avec des données qui permettront de gagner la confiance de l’utilisateur en l’informant avec précision sur l’identité de l’administrateur de l’application, le fonctionnement de l’application et l’utilisation des données personnelles.
  • Alors que le paramètre State est facultatif dans la définition du protocole OAuth, ce paramètre est obligatoire pour OAuthSD afin de renforcer la sécurité.
  • Lors de la procédure d’autorisation, le mot de passe de l’utilisateur final n’est pas entré au clavier, mais à la souris dans une grille aléatoire (GhostKeys). Ainsi, les mots de passe n’ont pas d’existence physique, sont cryptés dès la saisie, et ne peuvent donc être interceptés par un pourriciel. Mieux encore : avec NoPassConnect, il n’y a plus de mot de passe !

Avec OAuthSD, les mot de passe ne peuvent être interceptés au moment de leur saisie, ne circulent pas sur Internet, ne sont enregistrés nulle part !

L’engagement d’i-Tego à ne pas divulguer les données est un moyen pour les entreprises de se protéger de la concurrence. C’est aussi un avantage concurrentiel que les entreprises peuvent faire valoir auprès de leur clients et utilisateurs finaux.

 

Pour entrer rapidement dans le sujet, voyez :
- SLI, SSO, SLO et SRA sont dans un bateau : OAuthSD,
- Exemples complets du flux d’Autorisation,
- OpenID Connect : Lier une application cliente au serveur OAuthSD.

Pour tester le serveur OAuthSD avec vos applications :
- Inscrivez-vous comme auteur d’applications
- Lier une application cliente au serveur OAuthSD