paul-synchro/doc.md

Brouillon de notes Recherche documentaire sur les différents concepts en jeu pour l'approvisionnement et la synchronisation des référentiels (dans le cadre de l'authentification et de la gestion des identités)

Stage P.Marillonnet

Compilation :

`markdown doc.md > doc.html

TODOs

• Rédiger au propre les parties suffisamment documentées.
• Scripts création markdown temporaire avec encodage html correct ?? (accents et caractères spéciaux)

Acronymes

• ACL : Access Control List
• AS : Authentication Server
• CAS : Central Authentication Service
• CCTP : Cahier des Clauses Techniques Particulières
• GI : Gestion des Identités
• IDP : Identity provider
• IDM : Identity Manager
• NDS : Novell Directory Services // Vraiment pertinent ici ? Mentionné dans la RFC3384
• OASIS : Organization for the Advancement of Structured Information Standards
• OID : Object IDentifier
• PAM : Pluggable Authentification Modules
• SAML : Security Assertion Markup Language
• SASL : Simple Authentication and Security Layer
• SSHA : Salted SHA
• SOAP : Simple Object Access Protocol [//]: <> (Nécessaire de revoir l'architecture SOAP ? Est-ce vraiment encore utilisé ?)
• SP : Service Provider
• SSO/SLO : Single Sign-on / Single Log-Out
• SVE : Saisie par voie électronique
• SVA : Silence vaut acceptation
• TTLS : Tunnelled Transport Layer Security
• UID : Universak IDentifier

Annuaires

LDAP

Présentation générale

//Standardisation pour description organisationnelle, reprend le format de la norme X500 mais propose une spécification plus légère et plus facile à mettre en place. Les données sont organisées selon un schéma. LDAP spéficie aussi une interface de consultation de l'annuaire pour les clients autorisés (voir les outils client de type ldap-utils) Par définition, les accès les plus fréquents se font en lecture plutôt qu'en écriture. On parle d'annuaire car ce référentiel est plus souvent consulté que modifié. Il est important de remarquer standardise la structure, l'organisation des données stockées dans l'annuaire. Cette standardisation a pour but de garantir l'interopérabilité entre structure organisationnelles.

Le stockage des données de l'annuaire peut se faire sur une BDD ou simplement sur un fichier.

On distingue quatre composantes - ou quatre modèles (cf Understanding and deploying LDAP Directory Services) :

• le modèle de nommage
• le modèle fonctionnel
• le modèle d'information
• le modèle de sécurité

Modèle de nommage

Convention de formation des DC (Domain Components) Identification univoque par utilisation d'un DN (Distinguished Name), ou utilisation du RDN si pas besoin d'identifiant unique.

Modèle fonctionnel

Base portée (scope) : sub, one, base filtres => Revoir les filtres étendus TODO opérations cf liste : 11 opérations à connaître (abandon, add, bind, compare, delete, extended, modify, modify DN, rename, search, unbind). Propriétés modulaires de SASL (délégation de l'authentification à un mécanisme tiers).

URLs Echappement par caractères hexadécimal préfixé par % ldap[s]://<hostname>:<port>/<base_dn>?<attributes>?<scope>?&<filter>?<extensions>

Modèle d'information

DIT (Directory Information tree) DSE (Directory Service Entry)

Pas d'ordre pour les attributs multivalués.

objectClass : structural, auxiliary, abstract

Schémas, attributeType et et OIDs

Modèle de sécurité

On peut aussi choisir de mettre en place une authentification anonyme (en général ce mode d'authentification présente des droits d'accès moindres par rapport à une authentification identifiée).

Deux protocoles principaux pour assurer la sécurité par chiffrement des échanges client-annuaire :

• LADPS a recours a SSL // obsolète, non ?
• StartTLS, qui utilise TLS (successeur de SSL)

Utilisation ACLs après authentification d'un client. cf man slapd.conf(5), fichier de configuration du serveur OpenLDAP. Gestion de droits de façon déclarative, sous la forme : access to <what> [ by <who> <access> <control> ]+

Finalement, l'authentification peut-être laissée à un mécanisme d'authentification forte ou du moins renforcée, à l'aide du protocole SASL.

Fonctionnnalités annexes

Réplication

// cf plus bas LDUP -> TODO reorganiser, expliquer les différentes raisons pour instaurer une redondance de l'annuaire sur plusieurs serveurs

Distribution

Cette fois-ci pas de redondance, mais éclatement de l'annuaire en plusieurs parties sur différents serveurs. On parle de referrals (càd de référencement)

Liens symboliques

Permet au contraire d'éviter la redondance des données par la mise en place d'alias au sein d'un même annuaire. Cf aliasedObjectName (RFC4512LDAP Directory Information Models - Section 2.6 : Alias Entries)

Schémas

Présentation

Défini au format LDIF Standards approuvés par l'IANA Possibilité de modifier (déconseillé) ou d'étendre (préférable) des schémas existant

LDUP

Mécanisme de duplication Pas de synchron à proprement parler ? LDAP Duplication/Replication/Update -- LDAPv3

Différentes configurations prises en charge pour la réplication des données de l'annuaire :

• plusieurs maîtres (multi-master)
• maître - esclave

LDAPv3 Replication requirements (RFC3384)

Concepts fondamentaux :

• Réplication anonyme (anonymous replication) : source et cible sont identifiées mais pas authentifiées
• Zone de réplication (area of replication) : sous-partie de l'arborescence qui subit réplication. (=> Cette réplication ne concerne pas toujours la totalité de l'annuaire)
• Opération atomique : cf théorie de la synchro entre différents process
• Conflits : sur les informations répliquées (par ex deux changements non conciliables concernant la même sous-partie des données répliquées)
• OID Critique : Critique au sens de la réplication. Synchronicité entre modification d'un OID critique et propagation des modifications sur tous les réplicats.
• Mise-à-jour incrémentale (incremental update) : Mise à jour dont le contenu ne concerne que ce qui a été modifié, et non pas les données restées identiques entre les deux modifications
• Réplication à sens unique (one-way replication) -> par opposition à :
• Réplication bidirectionnelle (two-way replication) : changements locaux appliqués dans les deux sens pour parvenir à un état identique ~> 'LDAP merge'
• Réplicat esclave (Slave replica) : exemplaire du LDAP disponible en lecture seule seulement. Ne peut être instigateur de modifications sur son exemplaire local de l'annuaire.

Cas d'usage

TODO

Limites de LDUP

LDUP concerne un seul annuaire, selon un modèle distribué masters/slaves, pas forcément centralisé. Mais en pratique, il n'est pas toujours (voire pas souvent possible) d'avoir un seul annuaire LDAP. Certains outils ne supportent pas ce protocole.

On va donc avoir besoin d'un mécanisme de synchro de référentiels d'identités basés sur des technos hétérogènes.

// TODO Réorganisation des h3, ce n'est pas très clair

Authentication methods for LDAP (RFC2829)

Motivations de la RFC

• Accès frauduleux en lecture ~> Vol de données potentiellement sensibles
• Session hijacking par vol des données d'authentification d'un client légitime obtenue sur l'annuaire
• Accès frauduleux en écriture ~> Corruption des données de l'anuaire
• DoS sur l'annuaire
• Man-in-the-middle avec tout ce que ça implique ~> Dégâts côté client et/ou côté serveur.

Moyens mis en place

• politique d'accès de contrôle (access control policy) il s'agit de régles d'accès au ressources, généralement sous forme de liste. Une telle politique nécessite la définition d'attributs d'accès //TODO

AD

SUPANN

TODO Propre à l'enseignement supérieur ? Calqué sur le modèle organisationnel des univ aux US ?

PABX ?

NIS ?

DNS/Whois ? (pas vraiment de la GI ?)

Mécanismes d'authentification et implémentations

SASL (RFC2222)

TODO Paul

SAML

Basé XML Standardisé par l'OASIS Décrit des formats de données d'échange entre IDP et SP, à des fins d'authentification et d'autorisation des utilisateurs.

Utilisé pour le SSO des navigateurs

Une implémentation pour le SSO au niveau d'internet plus que d'un intranet ( intranet => Cookies seuls permettent d'assurer le SSO, car on sait quels technos Web sont en place dans le réseau interne)

Cf OpenSAML

Définition de rôles TODO explications access control

Méthode d'authentification laissée au choix des concepteurs du service LDAP, RADIUS, AD, délégation à un compte réseau social proposant des services d'authentification, etc.

SAML2.0 depuis 2005

TODO : Récupérer le XML Schema décrivant SAML, se documenter sur XML Encryption

Clauses d'une assertion SAML :

• contenu de l'assertion en elle même ?
• temps d'émission de l'assertion
• émetteur
• sujet de l'assertion
• conditions de validité de l'assertion

Sens (usuel) des assertions : IdP -> SP De ces assertions dépendent les contrôle d'accès défini par le SP pour l'utilisateur venant de s'authentifitier

Types de statements :

• Concernant une authentification
• Concernant un attribut
• Concernant une autorisation auxquels sont associées trois mêmes types de requête provenant du SP

TODO SAML SOAP bindings ?

profils SAML

Profil navigateur/artefact // TODO ?

Profil navigateur/http POST // TODO ?

SAML et sécurité

TLS XML Signature, et XML Encryption //TODO ? Ne spécifie pas de méthode de signature ou de chiffrement en particulier, juste des conventions de formatage pour leséchangés des paramètres de ces deux mécanismes (signature et chiffrement)

Structure des échanges SAML

//TODO cf doc Authentic

Schema de l'attribut SAML LDAP/X.500 'givenName' (extrait doc Authentic) :

<saml:Attribute xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:2.5.4.42" FriendlyName="givenName"> <saml:AttributeValue xsi:type="xs:string" x500:Encoding="LDAP">Mikaël</saml:AttributeValue> </saml:Attribute>

Normé par L'OASIS

OpenID Connect

Utilisé pour la plateforme FranceConnect Plus facile à mettre en place que des solutions basées SAML ?

Kerberos (RFC1510)

TODO bouquin o'Reilly

TODIG

• Mutual Authentication : Le client s'authentifie auprès du serveur, et réciproquement. Cette double authentification limite les risque d'usurpation d'identité (identity spoofing) Trusted Third-Party SESAME's limited delegation

L'algorithme de chiffrement symétrique utilisé par Kerberos est DES.

Notion de principal

Chiffrement des tickets envoyés

Ticket delivery service

Les clés distribuées par le service (de délivrement de tickets) ont une durée limitée dans le temps, ce qui diminue le risque d'attaques de type replay (rejeu frauduleux d'une session par un tiers non autorisé). On parle alors de clé de session.

Recommandations/spécifications de la RFC

Déroulement de la phase d'authentfication :

• Le client envoie une requête d'accès à un service donné,
• Le serveur d'authentification Kerberos renvoie les accès, chiffré avec la clé publique du client. Ces accès contiennent un ticket initial et une clé cde session (clé temporaire).
• Le client va utiliser le ticket pour contacter le serveur. Ce ticket contient l'identité du client et la clé de session chiffrée avec la clé publique du serveur (associé au service demandé par le client).
• La clé temporaire initie l'authentification (pas forcément mutuelle), puis la négociation d'un paramètres de communication chiffrée entre client et serveur.

Accès à l'AS

Deux façons de réaliser la première étape (demande d'accès du client au serveur d'authentification) :

• D'abord un TGT (Ticket-Granting Ticket) pour contacter le TGS (Ticket-Granting Server)
• Sinon, le TGS est un serveur d'application comme les autres, pas de méthode de communication spécifique.

L'accès à la base de données des principaux se fait selon le protocole KADM (Kerberos Administration).

Realms (Royaumes)

A un serveur d'authentification est associé un royaume. Les royaumes représentent donc une unité organisationnelle nécessitant un mécanisme d'authentification pour ses principaux. On remarquera ainsi que le nom du royaume apparaît dans l'identifiant de tout principal de ce royaume.

Il peut cependant être intéressant de mettre en place des mécanismes de communication (et d'authentification) inter-royaume.

//TODO cross-realm operations Ces communications inter-royaumes nécessitant que l'admin sys mette en place des clés prévues à cet effet. Elles permettront les échanes chiffrés entre les royaumes.

Concrètement, le TGS d'un royaume est enregistré en tant que principal du second royaume. Tout client local peut alors contacter le TGS distant à l'aide un TGT classique.

La communication entre deux royaumes peuvent transiter par plusieurs royaumes intermédiaires, pourvu qu'une clé inter-royaume soit disponible pour chaque échange direct. On parle alors de chemin d'authentification (authentication path).

En conséquence, pour des raisons pratiques, on met en place une organisation hiérarchique des royaumes entre eux, selon une structure arborescente. Dans un tel modèle, tout royaume a un père et potentiellement plusieurs fils. Cette hiérarchie est déduite des chemins d'authentification usuels.

TODO Question : comment est mise en place la base de données de principaux ? revoir KADM dans le cas de plusieurs royaumes.

On remarquera enfin que le processus d'authentification n'est par nature pas transparent pour l'application. Elle connaît, à l'aide du ticket, les differents royaumes impliqués dans le chemin d'authentification. Elle peut alors en déduire la fiabilité du processus d'authentification en fonction des différents acteurs mis en jeu.

TODO : Section 1.2 (Environmental Assumptions) mérite d'être détaillée ici

Identity Management

Principes généraux

Approvisionnement

Implémentations

Midpoint IDM

Projet écrit un Java, difficilement interfaçable avec les outils entr'ouvert. Lourd (projet git de taille 230Mo) Multifonctions :

• Automatisation de la création (provisioning) et suppression (deprovisioning) des référentiels d'identité gérés.
• synchro et gestion des conflits (reconciliation)
• Automatisation des processus d'acceptation des requêtes au référentiel d'identité
• Contrôle d'accès défini par les rôles (Role-based access control ou RBAC)
• Outils de monitoring
• utilisation de connecteurs standards pour interfacer les SP en tant qu'IDP TODO Parcourir sources, identifier les modules correspondant aux fonctions proposées

Authentic 2

écrit en Django TODO Installation et déploiement en local TODO Ecriture d'un dummy SP pour tester Authentic ??

TODO Expliquer les particularités de la licence GNU Affero GPL (APGL) TODO Quel intérêt de licencier la documentation sous Creative Commons ?

Documentation

Comprendre l'interaction avec Lasso pour le support SAMLv2

One-time password support ?

Sphinx, génération de la doc Cf structure des fichiers rst

Administration

L'administration d'Authentic 2 se fait de façon classique, à l'aide du module d'administration de Django, lequel propose une interface graphique disponible à la page /admin/ du site. Il faudra cependant veiller à créer un superuser lors de l'initialisation de la base.

Le contrôle d'accès aux ressources Authentic se fait par recours à deux politiques globales appelées 'Default' et 'All'. //TODO reformuler Le mécanisme de politiques d'accès géré par Authentic est extensible : l'administrateur du service peut en définir, en plus des politiques 'Default' et ' All'.

Le niveau de granularité de ces politiques est l'objet : à chaque objet il est possible d'attribuer une politique d'accès. // Au sens de la POO ?

//TODO Pourquoi est-il nécessaire d'appliquer la politique 'All' sur tous les objets ? Quel(s) problème(s) si on ne le fait pas ?

Gestion des attributs SAML2

Il s'agit ici de configurer une politique de gestion des attributs envoyés dans les réponses de succès d'authentification envoyées par Authentic 2 aux SPs.

L'utilisation des attributs SAML2 dans les réponses Authentic varie en fonction des cas d'utilisation, Authentic peut ou on être configuré en tant que SP SAML2.

//TODO Relire attribute_management.rst Ligne 207 : une associe une politique à un SP Cas particulier du SSO Revoir scenario d'utilisation avec mire de connexion

Authentification

Avec LDAP ou laissée à PAM Rappel: la configuration de PAM sous UNIX se fait à l'aide des fichiers situés dans /etc/pam.d

Configuration de la variable AUTHENTICATION_BACKEND du settings.py des sources Django.

SAML2 et croisement des données entre différents compte

Cette possibilité de croisement des données entres les différents comptes liéss à une même identité est au coeur de la fédération d'identité (On parle de account linking consent).

C'est le fournisseur d'identité (IdP) qui gère le consentement des utilisateurs à la liaison de leurs différents comptes. Les données ne sont pas forcément croisées, il peut simplement s'agir de la mise en place d'un mécanisme de SSO.

Dans ce cas, le message SAML AuthnRequest contient un champ indiquant le choix de l'utilisateur quant au croisement des ses comptes.

Si l'IdP manipule des identifiants opaques (transient), alors le consentement de l'utilisateur au croisement des comptes n'est pas nécessaire. //TODO à vérifier

On notera aussi que le fournisseur de service (SP) est en droit de refuser un SSO valide si le consentement de l'utilisateur n'a pas été recueilli. //S'agit-il ici de Authentic en tant que SP ?

Il faut aussi gérer le consentement à la redirection d'attributs (attribute forwarding consent). Dans Authentic 2, cette politique de gestion consiste en un choix parmi trois possibilités :

• Ne pas demander à l'utilisateur son accord
• Recueillir un consentement global pour l'ensemble des attributs ("Tout ou rien")
• Permettre à l'utilisateur de choisir, attribut par attribut, ceux qui peuvent être redirigés

authentic2-ctl

Outil d'administration en ligne de commande

Installation

• AttributeError: 'module' object has no attribute 'PassThroughManager' quand : utilisation de authentic2-ctl pourquoi : incompatibilité sur les versions récentes du module django-model-utils solution : rétrograder le module django-model-utils à une version <= 2.3

virtualenv Python

Le mécanisme de création d'environnements virtuels sous Python permet de faire cohabiter sur un même système des installations disparates. Par exemple, un même module Python peut être présent en différentes versions tant que ces versions se situent dans des environnements virtuels différents.

Les répertoires d'installation des modules Python dans le cadre d'un virtualenv sont seulement locaux à l'environnement créé.

Troubleshooting

Utilisation des tenants du SGBDR

SSO (et SLO)

Synchronisation

Fédération d'identités

Présentation

Concept très propre à la France Contraintes imposées par la Loi Informatique et Libertés (cf CNIL) techno-agnostic côté SP transparence pour l'utilisateur utilisation de la page de login de l'organisme de l'utilisateur pour l'identification et l'authentification sur le site ayant mis en place la fédération d'identités

Interdiction d'un croisement implicite des données, sans en avertir l'utilisateur

Plus grande probabilité de véracité des informations utilisateur Ces infos proviennent de sources sûres et à jour

TODO un SVG à faire ici, expliquant les mécanismes de la FI

TODO Relever les cas d'utilisation dans l'administration, les collectivités, et le monde de l'enseignement supérieur

Standards

Shibboleth

Appli Java Dépendances : Sprint OpenSAML Licence Apache

Mise au point technique

Django

TODO Se documenter sur les templates (modèle MVT) Expliquer philosophie DRY (Don't Repeat Yourself)

Principes généraux

Vues

Modèles

Templates

Langage procédural propre à django à l'intérieur des templates.

Remarques

L'interface Web d'administration et le compte superuser ne sont pas activés par défaut. Page /admin pour la gestion des webapps. Opérations CRUD : Create, Read, Update, Delete

La GUI est générée automatiquement en fonction des modèles de donnée de l'application, pourvu que ceux-ci aient été enregistrés au préalable (méthode admin.site.register())

Champs list_display, list_filter, date_hierarchy, ordering et search_fields de la classe admin.ModelAdmin

Classe Q : requêtes avancées -> à lire Appli ContentType pour les relations génériques

template context processors

custom tags utilisant la fonction render

django.db.models.signals

django.contrib.auth.models.User

Coding style

• keywork linebreaks
• cleaned_data pour les formulaires
• surcharge de __unicode__ et __str__ pour la description textuelle des données et objets Django.

Lecture du code source Authentic

Sources

https://shibboleth.net/

Lues

https://services.renater.fr/federation/introduction/a-quoi-ca-sert https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language https://www.ietf.org/rfc/rfc3384.txt https://www.ietf.org/rfc/rfc3384.txt https://tools.ietf.org/html/rfc2829 http://www.commentcamarche.net/contents/88-kerberos https://www.ietf.org/rfc/rfc1510.txt https://openclassrooms.com/courses/presentation-du-concept-d-annuaire-ldap https://confluence.atlassian.com/kb/how-to-write-ldap-search-filters-792496933.html https://virtualenv.pypa.io/en/stable/

A lire

http://www.journaldunet.com/developpeur/xml/analyse/la-federation-d-identite-au-travers-de-saml.shtml https://www.ietf.org/rfc/rfc4512.txt https://docs.djangoproject.com/en/1.10/howto/custom-template-tags/#thread-safety-considerations