• API Authentic
• API Documentation
• Attributes New Generation
• CAS
• Configuration de la création de compte et de l’authentification par numéro de téléphone mobile
• Configuration en tant que ServiceProvider
• Configuration pour les Google Apps
• Fournisseur d'identité OIDC
• Freeipa
• MSP connection
• No shared state IdP with external user directory
• OldHomepage
• SP PHP OAuth2
• Tickets faciles
• Validation des courriels
• Wiki

API Authentic¶

• Contenu
• API Authentic
  • Notes de version
  • Disclaimer
  • Aperçu
  • Transport
  • Style de l'interface
  • Authentification
  • Contrôle d'accès
    • Contrôle sur les attributs
  • Liste/recherche un compte
    • Paramètres
    • Format retour
    • Exemple cas-passant
    • Cas non-passant
    • Pagination des résultats
  • Création d'un compte
    • Format entrée
    • Exemple
    • Retour passant
    • Retour non-passant
    • Extension get-or-create et update-or-create
  • Lecture d'un comptes
    • Retour passant
    • Retour non-passant
  • Modification d'un comptes
    • Retour passant
    • Retour non-passant
  • Suppression d'un compte
    • Retour passant
    • Retour non-passant
  • Forcer le changement de mot de passe à la prochaine connexion
    • Retour passant
    • Retour non-passant
  • Tests d'existence des comptes en masse
    • Retour passant
    • Retour non-passant
  • Supprimer une fédération FranceConnect
    • Retour passant
    • Retour non-passant
  • Envoyer un jeton pour reinitialisation de mot de passe
    • Retour passant
    • Retour non-passant
  • Envoyer un jeton pour modifier l'email
    • Retour passant
    • Retour non-passant
  • Demande de validation de compte
    • Retour passant
    • Retour non passant
  • Lister les demandes de validation
    • Paramètres
    • Retour passant
    • Retour non passant

Notes de version¶

Disclaimer¶

Il s'agit d'un travail en cours. Certaines des fonctionnalités présentées peuvent ne pas être encore disponibles dans authentic mais uniquement dans authentic2-cut.

Aperçu¶

Cette API offre la possibilité de créer, lire, modifier et rechercher et supprimer (CRUD) des utilisateurs.

Transport¶

HTTP obligatoire

Style de l'interface¶

REST/JSON

Authentification¶

L'authentification se fait via un login et un mot de passe en utilisant le mode d'authentification HTTP Basic.

Contrôle d'accès¶

En utilisant la fonctionnalité des rôles affectés aux utilisateurs techniques il est possible d'autoriser ou non les différentes actions: créer, modifier, rechercher, supprimer.

Contrôle sur les attributs¶

La valeur d'un champs de téléphone peut débuter par un '+'. Elle ne doit ensuite contenir que des chiffres, maximum 20.

Les champs nom et prénoms de naissance sont limités à 64 caractères.

Les autres champs sont limités à 256 caractères.

Liste/recherche un compte¶

Paramètres¶

Format retour¶

Le document retour est un objet/dictionnaire JSON, les résultats sont toujours paginés, chaque page a une taille de 100, le lien vers la page suivante est dans la propriété next et celui vers la page précédente dans la propriété previous. La propriété results contient la liste des résultats.

Les résultats contiennent les propriétés suivantes:

Exemple cas-passant¶

GET /api/users/ HTTP/1.1
Authorization: Basic xxx

200 Ok
Content-Type: application/json
Content-Length: xxxx

{
    "next": "https://cresson.entrouvert.org/api/users/?cursor=XYZ",
    "previous": null,
    "results": [
        {
            "address_city": "",
            "address_complement": "",
            "address_country": "",
            "address_fc": {
                "country": "France",
                "formatted": "26 rue Desaix, 75015 Paris",
                "locality": "Paris",
                "postal_code": "75015",
                "region": "Ile-de-France",
                "street_address": "26 rue Desaix" 
            },
            "address_number": "",
            "address_street": "",
            "address_zipcode": "",
            "birthcountry": "FRANCE",
            "birthcountry_insee": "99100",
            "birthdate": "1981-06-23",
            "birthdepartment": "",
            "birthplace": "GIF-SUR-YVETTE",
            "birthplace_insee": "91272",
            "comment": null,
            "creation_domain": null,
            "creation_mode": null,
            "creation_partner": null,
            "date_joined": "2017-07-25T08:41:40.998793Z",
            "email": "eric.mercier@france.fr",
            "email_verified": true,
            "family_name": "Mercier",
            "first_name": "Eric",
            "gender": "male",
            "given_name": "Eric",
            "home_mobile_phone": "",
            "home_phone": "",
            "is_active": true,
            "last_name": "Mercier",
            "modified": "2017-08-31T15:16:29.690864Z",
            "phone_number_fc": null,
            "preferred_givenname": "",
            "preferred_username": null,
            "professional_mobile_phone": "",
            "professional_phone": "",
            "sub": "YTIBAQB9-fZcwZKt7k28P_towGlszsW0uDvxq5hd_zQOJhGBJ1qP3FYajF-JUY6ug_Ekw8k",
            "title": "Monsieur",
            "validated": "True",
            "validation_context": "FC",
            "validation_date": "2017-08-31" 
        },
        ...
    ]
}

Cas non-passant¶

Pagination des résultats¶

La réponse d'un cas passant contient au maximum 100 comptes. Si le résultat est supérieur à 100 comptes, le résultat se découpe en plusieurs pages et la réponse à la requête initiale ne contient que les 100 premiers comptes de la liste. Il faut ensuite parcourir les pages suivantes en interrogeant l'url spécifiée dans le champs next de la réponse et cela jusqu'à ce que le champs next soit à null.

Par exemple :

GET /api/users/ HTTP/1.1
Authorization: Basic xxx

200 Ok
Content-Type: application/json
Content-Length: xxxx

{
    "next": "https://moncompte.grandlyon.com/api/users/?cursor=XYZ",
    "previous": null,
    "results": [
        {
...

Le champs next indique qu'il y a une autre page de résultat que l'on obtient par la requête :

GET /api/users/?cursor=XYZ HTTP/1.1
Authorization: Basic xxx

200 Ok
Content-Type: application/json
Content-Length: xxxx

{
    "next": null,
    "previous": "https://moncompte.grandlyon.com/api/users/?cursor=ABC",
    "results": [
        {
...

Création d'un compte¶

Format entrée¶

Le document en entrée est un object/dictionnaire JSON avec les propriétés suivantes:

Les valeurs null ne sont pas autorisées.

La validité INSEE des champs birthplace, birthplace_insee, birthcountry et birthcountry_insee, ainsi que la cohérence entre birthplace et birthplace_insee et entre birthcountry et birthcountry_insee, est à la charge du client.

Exemple¶

POST /api/users/ HTTP/1.1 
Content-Type: application/json
Authorization: Basic xxxx
Content-Length: xxx

{
    "email": "john.doe@example.com",
    "first_name": "John",
    "last_name": "Doe",
    "gender": 1,
    "email": "john.doe@example.com",
    "birthdate": "1981-06-01",
    "birthplace": "Marseille",
    "birthcountry": "France",
    "preferred_username": "john",
    "address_city": "New-York",
    "send_registration_email": "True",
    "send_registration_email_next_url": "http://www.entrouvert.com" 
}

Retour passant¶

201 Created
Content-Type: application/json
Content-Length: xxx

{
        "sub": "8e7f200b4bb447fa8a91cd03c0f0ade3",
        "first_name": "john",
        "given_name": "john",
        "last_name": "doe",
        "family_name": "doe",
        "email": "john.doe@entrouvert.com",
        "modified": "2017-03-20T13:16:44.991343Z",
        "birthplace_insee": null,
        "gender": "1",
        "birthcountry_insee": null,
        "title": null,
        "birthdate": "1981-06-01",
        "birthplace": "Marseille",
        "birthcountry": "France",
        "preferred_username": "john
        "preferred_givenname": null,
        "address_number": null,
        "address_street": null,
        "address_complement": null,
        "address_zipcode": null,
        "address_city": "New-York",
        "address_country": null,
        "birthdepartment": null,
        "comment": null,
        "validated": null,
        "validation_date": null,
        "validation_context": null,
        "home_phone": null,
        "home_mobile_phone": null,
        "professional_phone": null,
        "professional_mobile_phone": null
}

Retour non-passant¶

HTTP/1.1 400 BAD REQUEST
Content-Type: application/json
Content-Length: xxxx

{
    "errors": {
        "last_name": [
            "Ce champ est obligatoire." 
        ]
    },
    "result": 0
}

Extension get-or-create et update-or-create¶

• si aucun utilisateur n'est trouvé la création a lieu normalement,
• si un utilisateur est trouvé :
  • pour get_or_create, l'utilisateur est retourné avec un code 200 Ok au lieu de 201 Created mais aucune modification ne lui est apporté, les données postées sont ignorées,
  • pour update_or_create, l'utilisateur est mis à jour avec les données postées puis retourné avec un code 200 Ok,
• si plusieurs utilisateurs sont trouvés l'opération échouera avec une erreur.

Exemple (email dans l'URL doit être écrit littéralement, il ne faut pas indiquer un courriel ou une variable)

POST /api/users/?get_or_create=email HTTP/1.1 
Content-Type: application/json
Authorization: Basic xxxx
Content-Length: xxx

{
    "email": "john.doe@example.com",
    "first_name": "John",
    "last_name": "Doe",
    "gender": 1,
    "email": "john.doe@example.com",
    "birthdate": "1981-06-01",
    "birthplace": "Marseille",
    "birthcountry": "France",
    "preferred_username": "john",
    "address_city": "New-York",
    "send_registration_email": "True",
    "send_registration_email_next_url": "http://www.entrouvert.com" 
}

200 Ok
Content-Type: application/json

{
        "sub": "8e7f200b4bb447fa8a91cd03c0f0ade3",
        "first_name": "john",
        "given_name": "john",
        "last_name": "doe",
        "family_name": "doe",
        "email": "john.doe@examle.com",
        "modified": "2017-03-20T13:16:44.991343Z",
}

Exemple avec clé multiple :

POST /api/users/?update_or_create=first_name&update_or_create=last_name HTTP/1.1 
Content-Type: application/json
Authorization: Basic xxxx
Content-Length: xxx

{
    "email": "john.doe2@example.net",
    "first_name": "john",
    "last_name": "doe",
}

200 Ok
Content-Type: application/json

{
        "sub": "8e7f200b4bb447fa8a91cd03c0f0ade3",
        "first_name": "John",
        "given_name": "Doe",
        "last_name": "doe",
        "family_name": "doe",
        "email": "john.doe2@examle.com",
        "modified": "2017-03-20T13:16:44.991343Z",
}

Lecture d'un comptes¶

GET /api/users/<id_compte>/ HTTP/1.1
Authorization: Basic xxxx

Retour passant¶

200 Ok
Content-Type: application/json
Content-Length: xxxx

{
        "sub": "8e7f200b4bb447fa8a91cd03c0f0ade3",
        "first_name": "john",
        "given_name": "john",
        "last_name": "doe",
        "family_name": "doe",
        "email": "john.doe@example.com",
        "modified": "2017-03-20T13:16:44.991343Z",
        "birthplace_insee": null,
        "gender": "1",
        "birthcountry_insee": null,
        "title": null,
        "birthdate": "1981-06-01",
        "birthplace": "Marseille",
        "birthcountry": "France",
        "preferred_username": "ben",
        "preferred_givenname": null,
        "address_number": null,
        "address_street": null,
        "address_complement": null,
        "address_zipcode": null,
        "address_city": "New-York",
        "address_country": null,
        "birthdepartment": null,
        "comment": null,
        "validated": null,
        "validation_date": null,
        "validation_context": null,
        "home_phone": null,
        "home_mobile_phone": null,
        "professional_phone": null,
        "professional_mobile_phone": null
}

Les propriétés sans valeur sont à null.

Retour non-passant¶

voir plus haut

Modification d'un comptes¶

PATCH /api/users/<id_compte>/ HTTP/1.1 
Content-Type: application/json
Authorization: Basic xxxx
Content-Length: xxx

{
    "validated": "True",
    "validation_date": "2016-11-23",
    "validation_context": "FC" 
}

L'action PUT nécessite que first_name et last_name (obligatoires) soient dans le document JSON. S'ils ne sont pas renseignés, une erreur 400 est retournée.

La validité INSEE des champs birthplace, birthplace_insee, birthcountry et birthcountry_insee, ainsi que la cohérence entre birthplace et birthplace_insee et entre birthcountry et birthcountry_insee, est à la charge du client.

Attention : gender, family_name et given_name sont des alias des attributs title, last_name et firstname, avec gender où Madame est traduit en female et Monsieur en male. Lorsque l'on souhaite modifier ces attributs, cela doit porter sur les attributs title, last_name et firstname et non sur gender, family_name et given_name.

Attention : l'attribut email n'est pas modifiable par ce service. Sa modification nécessite l'utilisation d'un "service dédié au changement d'email":#Envoyer-un-jeton-pour-modifier-lemail

Retour passant¶

200 Ok
Content-Type: application/json
Content-Length: xxx

{
        "sub": "8e7f200b4bb447fa8a91cd03c0f0ade3",
        "first_name": "john",
        "given_name": "john",
        "last_name": "doe",
        "family_name": "doe",
        "email": "john.doe@example.com",
        "modified": "2017-03-20T13:16:44.991343Z",
        "birthplace_insee": null,
        "gender": "1",
        "birthcountry_insee": null,
        "title": null,
        "birthdate": "1981-06-01",
        "birthplace": "Marseille",
        "birthcountry": "France",
        "preferred_username": "ben",
        "preferred_givenname": null,
        "address_number": null,
        "address_street": null,
        "address_complement": null,
        "address_zipcode": null,
        "address_city": "New-York",
        "address_country": null,
        "birthdepartment": null,
        "comment": null,
        "validated": "True",
        "validation_date": null,
        "validation_context": null,
        "home_phone": null,
        "home_mobile_phone": null,
        "professional_phone": null,
        "professional_mobile_phone": null
}

Retour non-passant¶

HTTP/1.1 400 BAD REQUEST
Content-Type: application/json
Content-Length: xxxx

{
    "errors": {
        "last_name": [
            "Ce champ est obligatoire." 
        ]
    },
    "result": 0
}

Suppression d'un compte¶

DELETE /api/users/<id_compte>/ HTTP/1.1
Authorization: Basic xxx

Retour passant¶

204 No content

Retour non-passant¶

Forcer le changement de mot de passe à la prochaine connexion¶

POST /api/users/<id_compte>/force-password-reset/ HTTP/1.1
Authorization: Basic xxx

Retour passant¶

204 No content

Retour non-passant¶

Tests d'existence des comptes en masse¶

Ce web-service doit être utilisé pour la propagation des suppressions de compte. L'appel peut-être fait soit au moment de la détection d'une collision (compte nouveau arrivant avec un email existant), avec envoi du sub du compte existant, soit en masse régulièrement, avec envoi en plusieurs fois (par paquet de 100) de la totalité des subs connus.

POST /api/users/synchronization/ HTTP/1.1
Authorization: Basic xxx
Content-Type: application/json
Content-Length: xxxx

{
    "known_uuids":["e46d46ebcb1d4d6bac4571159b542389", "1234567890"],
}

Retour passant¶

200 Ok
Content-Type: application/json
Content-Length: xxxx

{
    "unknown_uuids":["1234567890"],
    "result":1
}

Retour non-passant¶

400 BadRequest
Content-Type: application/json
Content-Length: xxxx

{    
    "detail":"JSON parse error - Expecting ',' delimiter: line 1 column 53 (char 52)" 
}

Supprimer une fédération FranceConnect¶

DELETE /api/users/<id_compte>/fc-unlink/ HTTP/1.1
Authorization: Basic xxx

Retour passant¶

204 No content

Retour non-passant¶

Envoyer un jeton pour reinitialisation de mot de passe¶

POST /api/users/<id_compte>/password-reset/ HTTP/1.1
Authorization: Basic xxx

Retour passant¶

204 No content

Retour non-passant¶

Envoyer un jeton pour modifier l'email¶

POST /api/users/<id_compte>/email/ HTTP/1.1
Authorization: Basic xxx

{"email": "nouvelemail@example.com"}

Retour passant¶

200 No content
Content-Type: application/json

{"result": 1}

Retour non-passant¶

Demande de validation de compte¶

Pour éviter les problématiques de validation des pièces jointes, seul le format JPEG est autorisé au niveau de l'API portée par le compte. Charge aux clients de l'API de convertir d'autres formats en JPEG.

POST /api/users/<id_compte>/validate/ HTTP/1.1
Authorization: Basic xxx
Content-Type: application/json

Le champ external_id représente l'identifiant de la demande dans le SI du demandeur, il permet d'empêcher les doublons. Le couple (id_compte, external_id) doit être unique, sinon la création de la demande est rejetée.

{
    "justificatifs": [{
       "b64_content": "..." 
    }],
    "external_id": "XYZ1234" 
}

Le champs justificatifs est une liste de dictionnaire contenant une unique clé b64_content. Chaque dictionnaire représente une page du justificatif, jusqu'à 2. Chaque page doit peser moins de 300Ko, sinon la demande est rejetée, et doit être un fichier JPEG encodé en base64 dans une chaîne JSON.

Retour passant¶

201 Created
Content-Type: application/json

{
   "result": 1,
   "status": "received",
   "sub": "xyz1234543534535",
   "external_id": "32423424324",
   "id": 123
}

Retour non passant¶

À noter qu'il est interdit de créer plusieurs demandes pour un même external_id pour un partenaire donné mais que plusieurs demandes pour un même id_compte (même usager) peuvent être créée. C'est au partenaire de décider dans son système s'il autorise cela.

400 Bad Request
Content-Type: application/json

{
   "result": 0,
   "errors": [
       {
          'code': 'justificatifs-bad-format',
          'page': 0,
          'accepted': ['image/jpeg'],
       },
       {
          'code': 'justificatifs-too-big',
          'page': 0,
          'max-size': '300000',
       }
       {
          'code': 'already-exists',
       }
   ]
}

Lister les demandes de validation¶

La liste est paginée (comme pour le listing des compte), par groupe de 100. L'ordre est l'ordre croissant de la date de création. Voir cette "section":#Pagination-des-r%C3%A9sultats pour l'utilisation de la pagination.

Les demandes traitées ayant plus d'un mois sont purgées.

La version avec l'id_compte ne liste que les demandes concernant cet ID compte.

Paramètres¶

Retour passant¶

200 OK
Content-Type: application/json

{
    "next": null,
    "previous": null,
    "result": 1,
    "results": [
        {
            "created": "2018-04-24T06:49:37.371577Z",
            "external_id": "7",
            "id": 9,
            "reason": "",
            "status": "received",
            "sub": "YTIBAQCbZndVIpit-Eog-Y-33sFBf9hTbHYa4YVxDfqW6kwmJWo3_5glGQtGbzQI7FajXtw",
            "validated": null
        },
        ...
        {
            "created": "2018-04-23T17:03:16.791785Z",
            "external_id": "4",
            "id": 6,
            "reason": "",
            "status": "accepted",
            "sub": "YTIBAQCbZndVIpit-Eog-Y-33sFBf9hTbHYa4YVxDfqW6kwmJWo3_5glGQtGbzQI7FajXtw",
            "validated": "2018-04-23T17:06:52.623275Z" 
        },
        {
            "created": "2018-04-23T17:01:46.458133Z",
            "external_id": "3",
            "id": 5,
            "reason": "underaged",
            "status": "refused",
            "sub": "YTIBAQCbZndVIpit-Eog-Y-33sFBf9hTbHYa4YVxDfqW6kwmJWo3_5glGQtGbzQI7FajXtw",
            "validated": "2018-04-23T17:04:52.121961Z" 
        },
        {
            "created": "2018-04-23T16:59:24.773830Z",
            "external_id": "2",
            "id": 4,
            "reason": "unreadable",
            "status": "refused",
            "sub": "YTIBAQCbZndVIpit-Eog-Y-33sFBf9hTbHYa4YVxDfqW6kwmJWo3_5glGQtGbzQI7FajXtw",
            "validated": "2018-04-23T17:01:02.989202Z" 
        },
        {
            "created": "2018-04-23T16:44:24.223940Z",
            "external_id": "1",
            "id": 3,
            "reason": "invalid",
            "status": "refused",
            "sub": "YTIBAQCbZndVIpit-Eog-Y-33sFBf9hTbHYa4YVxDfqW6kwmJWo3_5glGQtGbzQI7FajXtw",
            "validated": "2018-04-23T16:57:50.874902Z" 
        },
        ...
    ]
}

• received pour les nouvelles demande non encore traitées,
• accepted pour les demandes acceptées,
• refused pour les demandes refusées, la raison se trouvant dans le champ reason qui est une chaîne de texte.

Lorsqu'une demande passe du statut "received" à "accepted" ou "refused", la date de la transition est conservée dans le champs validated. Le fait de filtrer à l'aide de validated__gt ne renvoie que des demandes validées ("status": "accepted" ou "status": "refused"), donc dont le champs validated n'est pas null.

Retour non passant¶

API Doc¶

• Contenu
• API Doc
  • Aperçu
  • Transport
  • Style de l'interface
  • Authentification
  • Contrôle d'accès
  • Liste/recherche un Utilisateur
    • Paramètres
    • Format retour
    • Exemple cas-passant
    • Cas non-passant
  • Création d'un Utilisateur
    • Format entrée
    • Exemple
    • Retour passant
    • Retour non-passant
  • Lecture d'un Utilisateur
    • Retour passant
    • Retour non-passant
  • Modification d'un Utilisateur
    • Retour passant
    • Retour non-passant
  • Suppression d'un Utilisateur
    • Retour passant
    • Retour non-passant
  • Forcer le changement de mot de passe à la prochaine connexion
    • Retour passant
    • Retour non-passant
  • Tests d'existence des comptes en masse
    • Retour passant
    • Retour non-passant
  • Envoyer un jeton pour reinitialisation de mot de passe
    • Retour passant
    • Retour non-passant

Aperçu¶

Cette API offre la possibilité de créer, lire, modifier et rechercher et supprimer (CRUD) des utilisateurs dans l'annuaire du Utilisateur.

Transport¶

HTTP obligatoire

Style de l'interface¶

REST/JSON

Authentification¶

L'authentification se fait via un login et un mot de passe en utilisant le mode d'authentification HTTP Basic.

Contrôle d'accès¶

En utilisant la fonctionnalité des rôles affectés aux utilisateurs techniques il est possible d'autoriser ou non les différentes actions: créer, modifier, rechercher, supprimer.

Liste/recherche un Utilisateur¶

Paramètres¶

Format retour¶

Le document retour est un objet/dictionnaire JSON, les résultats sont toujours paginés, chaque page a une taille de 100, le lien vers la page suivante est dans la propriété next et celui vers la page précédente dans la propriété previous. La propriété results contient la liste des résultats.

Les résultats contiennent les propriétés suivantes:

Exemple cas-passant¶

GET /api/users/ HTTP/1.1
Authorization: Basic xxx

200 OK
Coneent-Type: application/json
Content-Length: xxxx

{
    "next": null,
    "previous": null,
    "results": [
        {
            "date_joined": "2017-08-21T14:28:00Z",
            "email": "john.doe@example.com",
            "email_verified": false,
            "first_name": "John Kevin Eric",
            "id": 4,
            "is_active": true,
            "is_staff": false,
            "is_superuser": false,
            "last_login": null,
            "last_name": "Doe",
            "modified": "2017-08-21T14:47:34.102909Z",
            "ou": "default",
            "password": "pbkdf2_sha256$20000$crynWolm1hVD$SpcKEw0W6HNjDdex6RcKrGPB5N5eBwjCRT+KaFWFATA=",
            "username": "jdoe",
            "uuid": "73e62dc8de25486e901753d127309eef" 
        }
    ]
}

Cas non-passant¶

Création d'un Utilisateur¶

Format entrée¶

Le document en entrée est un object/dictionnaire JSON avec les propriétés suivantes:

Les valeurs null ne sont pas autorisées.

Exemple¶

POST /api/users/ HTTP/1.1
Content-Type: application/json
Authorization: Basic xxxx
Content-Length: xxx

{
    "email": "john.doe@example.com",
    "first_name": "John",
    "last_name": "Doe",
    "email": "john.doe@example.com",
    "username": "jdoe",
    "password": "toto" 
}

Retour passant¶

201 Created
Content-Type: application/json
Content-Length: xxx

{
    "date_joined": "2017-08-21T14:28:00.194032Z",
    "email": "",
    "email_verified": false,
    "first_name": "John",
    "id": 4,
    "is_active": true,
    "is_staff": false,
    "is_superuser": false,
    "last_login": null,
    "last_name": "Doe",
    "modified": "2017-08-21T14:28:00.470957Z",
    "ou": "default",
    "password": "pbkdf2_sha256$20000$crynWolm1hVD$SpcKEw0W6HNjDdex6RcKrGPB5N5eBwjCRT+KaFWFATA=",
    "username": "jdoe",
    "uuid": "73e62dc8de25486e901753d127309eef" 
}

Retour non-passant¶

HTTP/1.1 400 BAD REQUEST
Content-Type: application/json
Content-Length: xxxx

{
    "errors": {
        "last_name": [
            "Ce champ est obligatoire." 
        ]
    },
    "result": 0
}

Lecture d'un Utilisateur¶

GET /api/users/<uuid>/ HTTP/1.1
Authorization: Basic xxxx

Retour passant¶

200 Ok
Content-Type: application/json
Content-Length: xxxx

{
    "date_joined": "2017-08-21T14:28:00Z",
    "email": "john.doe@example.com",
    "email_verified": false,
    "first_name": "John",
    "id": 4,
    "is_active": true,
    "is_staff": false,
    "is_superuser": false,
    "last_login": null,
    "last_name": "Doe",
    "modified": "2017-08-21T14:34:15.669381Z",
    "ou": "default",
    "password": "pbkdf2_sha256$20000$crynWolm1hVD$SpcKEw0W6HNjDdex6RcKrGPB5N5eBwjCRT+KaFWFATA=",
    "username": "jdoe",
    "uuid": "73e62dc8de25486e901753d127309eef" 
}

Les propriétés sans valeur sont à null.

Retour non-passant¶

voir plus haut

Modification d'un Utilisateur¶

PATCH /api/users/<uuid>/ HTTP/1.1
Content-Type: application/json
Authorization: Basic xxxx
Content-Length: xxx

{
    "first_name": "John Kevin" 
}

L'action PUT nécessite que first_name et last_name (obligatoires) soient dans le document JSON. S'ils ne sont pas renseignés, une erreur 400 est retournée.

Retour passant¶

200 Ok
Content-Type: application/json
Content-Length: xxx

{
    "date_joined": "2017-08-21T14:28:00Z",
    "email": "john.doe@example.com",
    "email_verified": false,
    "first_name": "John Kevin",
    "id": 4,
    "is_active": true,
    "is_staff": false,
    "is_superuser": false,
    "last_login": null,
    "last_name": "Doe",
    "modified": "2017-08-21T14:34:15.669381Z",
    "ou": "default",
    "password": "pbkdf2_sha256$20000$crynWolm1hVD$SpcKEw0W6HNjDdex6RcKrGPB5N5eBwjCRT+KaFWFATA=",
    "username": "jdoe",
    "uuid": "73e62dc8de25486e901753d127309eef" 
}

Retour non-passant¶

HTTP/1.1 400 BAD REQUEST
Content-Type: application/json
Content-Length: xxxx

{
    "errors": {
        "last_name": [
            "Ce champ est obligatoire." 
        ]
    },
    "result": 0
}

Suppression d'un Utilisateur¶

DELETE /api/users/<uuid>/ HTTP/1.1
Authorization: Basic xxx

Retour passant¶

204 No content

Retour non-passant¶

Forcer le changement de mot de passe à la prochaine connexion¶

POST /api/users/<uuid>/force-password-reset/ HTTP/1.1
Authorization: Basic xxx

Retour passant¶

204 No content

Retour non-passant¶

Tests d'existence des comptes en masse¶

POST /api/users/synchronization/ HTTP/1.1
Authorization: Basic xxx
Content-Type: application/json
Content-Length: xxxx

{
    "known_uuids":["73e62dc8de25486e901753d127309eef", "1234567890"],
}

Retour passant¶

200 Ok
Content-Type: application/json
Content-Length: xxxx

{
    "unknown_uuids":["1234567890"],
    "result":1
}

Retour non-passant¶

400 BadRequest
Content-Type: application/json
Content-Length: xxxx

{
    "detail":"JSON parse error - Expecting ',' delimiter: line 1 column 53 (char 52)" 
}

Envoyer un jeton pour reinitialisation de mot de passe¶

POST /api/users/<uuid>/password-reset/ HTTP/1.1
Authorization: Basic xxx

Retour passant¶

204 No content

Retour non-passant¶

Attributes New Generation¶

This page describe a new attribute engine for authentic having simpler articutaled concepts and being more powerful.

It's largely based on a reading of Shibboleth IdPAddAttribute wiki page but with a larger setting than an only SAML 1.0 / SAML 2.0 compliant identity provider.

There are 3 functional concepts: the attribute sources, the attribute engine and the attribute encoders.

Attribute sources:¶

• a description name,
• a slug (an identifier without spaces),
• dependencies upon other sources, i.e. this source can only be called after another source has been called, for example a script source working upong LDAP attributes must be executed after the LDAP attributes have been retrieved,
• a boolean parameter if the source should always produce its result or only if one of its attributes is requested (present in wanted_attributes attribute describe later in get_attributes() method of the attribute engine)
• source type related informations:
  • location of the source (LDAP url, SCIM REST endpoint, SQL alchemy URL),
  • how to map existing attributes to a search request (LDAP search or SQL select statements, with variables),
  • the list of attributes to extracts. They can be defined through settings ou models, or any other methods.

List of type of sources to have¶

• an LDAP source using python-ldap
• an SQL source using python-sqlalchemy
• a SCIM source using python-scim
• implicit sources based on authentication backends:
  • LDAP authentication provides an LDAP source
  • OAuth 2.0 authentication provides an user-info web-service source
  • SAML 2.0 authentication provides an assertion attributes source
• a python expression source: it contains two fields:
  • a name for the attribute
  • a python expression, a variable named attributes is available as a local variable

Configuration¶

Each source is responsible to finding its configuration, there is no global definition of how the configuration should look like, where it is stored, etc... Available attribute source types are found using the list of installed applications by looking for a contained module named attribute_backend containing a class named AttributeBackend, i.e. if the saml application want to define an attribute source there should be file named saml/attribute_backend.py which contains a classe named AttributeBackend.

Interface¶

• get_instances(ctx)

  Return a list of (source, instance) for this source. It's used by the attribute engine to list all attribute source instances.

• get_dependencies(instance, ctx)

  Return the list of attributes this instance requires. It's used by the attribute engine to order the attribute source instances before running them.

• get_attribute_names(instance, ctx)

  Return the list of attribute names produced by this instance.

• get_attributes(instance, ctx)

  Return a dictionnary of the attributes produced for this instance given the context ctx.

Attribute engine¶

A singleton object, there is one instance for the global application. The default implementation is found using the A2_ATTRIBUTE_ENGINE which should be a Python class path. A default one is provided.

Interface¶

• get_attribute_names(ctx)

  It calls every sources and returns the aggregated list of defined attributes, defined does not mean that the attributes are available. For example if you have two ldap sources ldap1 and ldap2 against which people can be authenticated. If an user is authenticated against the ldap1 sources, the attributes from ldap1 will be defined and available (not all of them as an LDAP search can return a partial response), but the attributes from ldap2 will be defined but not available at all.

• get_attributes(ctx):

  It is responsible for calling every sources in order to aggregate attributes. The ctx argument is used to initialize the ctx argument passed to the first source called. Each source instance decides each time to produce or not some attributes, i.e if its dependencies have not produced the needed attributes, it can decide to do nothing. The engine is authorized to cache the list of instances between calls and the topological sort done based on the dependencies attributes. If a cyclical dependency is found an exception is raised. Each source is called only one time. If you want a source to be run again (if there is an implicit cyclical dependency), then call get_attributes() again.

  Some attribute names have special meaning:

  • wanted_attributes:
    It must be a list of attribute names, it list the attributes expected by the requestor. For example a service provider could list the attributes referenced by some of its attribute encoders.
  • session:
    The request.session object, if available.
  • request:
    The Django request object, if available.
  • user:
    The Django request.user object, if available.

TBD¶

• How to remember that a source has already been called ? Maybe it's the job of each to store an attributes identifer.last_call with a timestamp, to determine previous call and freshness.
• Maybe linking get_attributes to the request object is too limiting. Maybe we should just pass request.session.pop('attributes', {}) then overwrite it with the return value, which would permit to use the engine in other contexts than a Django HTTP request.
• What to do on source errors ? i.e the LDAP raise an error or the script source fails on an undefined variable.

Attribute encoders¶

They are objects linked to attribute recipients, usually service providers in the Authentic2 setting. They define which and how attributes should be transmitted. They can be defined through the setting file or ORM models, this is undefined. Their interface is also undefined as it depends upon the identity provider calling them. They are not really part of the attribute engine but clients of it. Each identity provider backend is responsible for calling them. They are the clients of the attribute engine interfaces, and are here only to see how the attribute engine interfaces will be used.

Examples¶

• The SAML 2.0 identity provider could define the following encoders:
  • SAML2SimpleAttributeEncoder:
    • Its definition contains:
      • an attribute name from the list given by @Engine.get_attribute_names(),
      • parameters to build a saml:Attribute element, i.e a Name, NameFormat and FriendlyName
    • For ease of use the IHM interface could provide templates, using the current mapping.py file.
  • SAML2PersistentNameID: generate the NameID from a persistent storage,
  • SAML2TargetedIdEncoder: takes the NameID and create an attribute from it.
  • SAML2XMLAttributeEncoder: take the value of the attribute, try to cast it as an XML fragment and use it as the content of the attribute.

• The OAuth 2.0 identity provider could define the following encoders:
  • UserInfoWebServiceEncoder: it contains
    • the URL name of the user_info rest endpoint
    • a Django template which should produce a Django document. It can refers to attributes from the attribute engine.

CAS 1.0 and 2.0¶

• Specification

How it works in authentic ?¶

• /cas/login
• /cas/validate
• /cas/serviceValidate
• /cas/proxy
• /cas/proxyValidate

Still missing is a way to limit use of the service for specific endpoints and to control use of the proxying ticket by services.

The configuration page is on /admin/settings/cas.

Configuration de la création de compte et de l’authentification par numéro de téléphone mobile¶

• Disposer d’un service d’envoi de SMS.
  Dans Publik, cela se fait par l’ajout d’un connecteur SMS dans Passerelle, puis de la déclaration des paramètres d’envoi dans la page Hobo prévue à cet effet (/sms/).
  Alternativement, si l’on souhaite redéfinir seulement pour Authentic ces paramètres d’envoi (par exemple si Authentic doit passer par un connecteur SMS à part), il faut poser les settings SMS_SENDER et SMS_URL dans la configuration du tenant.

• Activer le feature flag.
  Cela se fait via la setting A2_ACCEPT_PHONE_AUTHENTICATION. Un exemple de fichier de configuration JSON minimale de tenant :
  

  {
    "A2_ACCEPT_PHONE_AUTHENTICATION": true
  }
  

• Adaptation des démarches prévues pour le courriel seul.
  Sur l’instance concernée, il faut identifier et corriger les démarches basées sur l’hypothèse d’une adresse courriel nécessairement définie pour l’usager connecté.
  Des utilisateurs ne déclarant aucun courriel peuvent désormais soumettre des démarches réservées aux usagers connectés.
  Si un champ de profil usager porte l’identifiant "phone", c’est celui-ci parmi les champs de profil qui va recueillir le numéro de téléphone identifiant l’usager, et il peut être utilisé comme option de pré-remplissage des champs de formulaire.
  Ce pré-remplissage reste compatible avec la validation de champ "Numéro de téléphone" et "Numéro de téléphone (France)".

Configuration en tant que ServiceProvider¶

Génération de la paire de clés:¶

Dans le répértoire du tenant

openssl req -x509 -sha256 -newkey rsa:2048 -nodes -keyout publik-sp.key -out publik-sp.crt -batch -subj '/CN=connexion.demarches.ville.fr' -days 3652

Pour Authentic multitenant, copier les fichiers générés dans le répértoire du tenant:

cp sp-saml.key /var/lib/authentic2-multitenant/tenants/<connexion.demarches.ville.fr>/
cp sp-saml.crt /var/lib/authentic2-multitenant/tenants/<connexion.demarches.ville.fr>/

Métadonnées du fournisseur d'identités:¶

Télécharger le fichier des métadonnées, ou si pas accessible directement via HTTP, le demander au client.

Pour Authentic multitenant copier le fichier dans le répértoire du tenant:

cp idp-metadata.xml /var/lib/authentic2-multitenant/tenants/<connexion.demarches.ville.fr>/

Settings¶

Pour Authentic multitenant créer le fichier settings.json dans le répértoire /var/lib/authentic2-multitenant/tenants/<connexion.demarches.ville.fr>/ avec le contenu suivant:

{
  "A2_AUTH_SAML_ENABLE": true,
  "MELLON_PUBLIC_KEYS": ["/var/lib/authentic2-multitenant/tenants/<connexion.demarches.ville.fr>/publik-sp.crt"],
  "MELLON_PRIVATE_KEY": "/var/lib/authentic2-multitenant/tenants/<connexion.demarches.ville.fr>/publik-sp.key",
  "MELLON_PROVISION": true,
  "MELLON_IDENTITY_PROVIDERS": [
    {
      "A2_ATTRIBUTE_MAPPING": [
        {
          "attribute": "email",
          "mandatory": true,
          "saml_attribute": "email" 
        },
        {
          "attribute": "last_name",
          "mandatory": false,
          "saml_attribute": "last_name" 
        },
        {
          "attribute": "first_name",
          "mandatory": false,
          "saml_attribute": "first_name" 
        },
        {
          "action": "toggle-role", <= si besoin d'affecter un rôle aux comptes en provenance du fournisseur
          "role": {
            "name": "Agent" 
          }
        }
      ],
      "SLUG": "my-idp",
      "LOOKUP_BY_ATTRIBUTES": [
        {
          "user_field": "email",
          "saml_attribute": "email" 
        }
      ],
      "METADATA": "/var/lib/authentic2-multitenant/tenants/<connexion.demarches.ville.fr>/idp-metadata.xml" 
       ou bien
      "METADATA_URL": "https://annuaire.ville.fr/.../metadata.xml",
    }
]
}

Dans le cas ou le fournisseur d'identité est un serveur ADFS, les noms des attributs usagers peuvent être des URIs: exemple

Communiquez les métadonnées aux clients pour qu'il puisse faire la configuration de son coté¶

https://connexion.demarches.ville.fr/accounts/saml/metadata/

Configuration pour les Google Apps¶

Chez Google¶

• Aller sur le panneau d'administration du domaine Google Apps
• Cliquer sur Outils avancés
• Cliquer ensuite sur "Configurer le SSO"
• Définir les options suivantes:
  • Activer le SSO: cocher la case
  • Sign-in page URL: https://YOURDOMAIN.COM/idp/saml2/sso
  • Sign-out page URL: https://YOURDOMAIN.COM/idp/saml2/slo
  • Change password URL: https://YOURDOMAIN.COM/accounts/password/change/
  • Verification certificate: Ouvrir l'URL https://YOURDOMAIN.COM/idp/saml2/metadata dans un navigateur, rechercer la balise X509Certificate, copier-coller son contenu en ajoutant avant la première ligne

    -----BEGIN CERTIFICATE-----
    

    et après la dernière ligne

    -----END CERTIFICATE-----
    

Sur authentic¶

• Créer un nouveau fournisseur de service avec les métadonnées suivantes:

  <EntityDescriptor entityID="google.com" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
      <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  
          <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>
  
          <AssertionConsumerService index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
              Location="https://www.google.com/a/YOURDOMAIN.COM/acs" />
      </SPSSODescriptor>
  </EntityDescriptor>
  

• Appliquer une politique de fournisseur de service pour celui-ci avec l'option "Format de NameID par défaut" avec la valeur "Identifiant utilisateur"

Fournisseur d'identité OIDC¶

Générer et configurer les clés RSA du fournisseur¶

$ apt install python-jwcrypto
$ python
Python 2.7.8 (default, Oct 18 2014, 12:50:18) 
[GCC 4.9.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from jwcrypto import jwk
>>> k = jwk.JWK.generate(kty='RSA', size=2048)
>>> s = jwk.JWKSet()
>>> s['keys'].add(k)
>>> s.export()
'{"keys":[{"d":"Y9GJV37oeFlqz2vuZZDsBVfu4u6YLGbMR7ONhedvn3YTMvFxzmeSwjHd2pdoY05TBjgNbDk6QaCKVtqRrHsbbrmYN_6aRIoZk9KiZqLPvnrRUbe0_lLaozJxZjPa4urb8-vsq_Y040DhUEiBog0xjq2RDg7qtcpi5nf0NRNhXbEm2dzIutH22e8WDoUMma8b64NeZgciSmvdu24UUG_eoAt7fsy8xfL81nxA6qk0mWFrjyCpvxmjEotuCBQ79JLzStWeiKkBx80mokNnMTD3bZm-coJRXEPTcKzmtG_NTmNGi1_IZwZslr5cB6F3cyMIsA1y4mYgYu46JNVvUlwIYQ","dp":"OSokOYunlOqOFxOXuMNfdxTyxi2itS5dW2M4S0PBzwlfOU-fD7JWft94sRTOXCP65No_vmw-V2AHnRRj-GgcHdjyIgHkMV4bgtgUkV7HtAmsC_VAdYwnEWOfeaq-izl34DRUt-qN_m6HzNVziC2JtiPum2ifFuS2vrvO4FTPMgE","dq":"QwnEqx3W1MOa5dRhboSwPu4_J5vgwqofjeKrQD1OmEjeowwzJmj5aYiRysZW6IzV5L7XpW081EdxDXI6ddBGWRq-QFlpF9hGxGYQ9qmmohz_ZcVuw5qUdoF113tUA_9aPujG3LPV7S9Jt-R1piN8b7HGUkz_DSVMLzgArlQ4F8k","e":"AQAB","kty":"RSA","n":"yDIt_sOfAY7h5kcyQLimct2R-4PF5K6Fb90xtEAQmZiXzfW2LzhUX4Uow-XLU_shMrAwixAqc-P8A_Sg-IpCHqvcEaIt0tylGThaguN6e6kJxgTU22Oqx4QBCgejm9xMW9kNf15OvudBiuxn5vveR8VFts_pWU-wCNwBw1AHx67E6dszP0C2G7ZN_7v9AI3f3fTj9S1AGzaJHX5bu9aSRFkmVk-K_VBOyovJYYXb3rhFoy16fJWGsxSTLHD9LS_OvpN3_EIj82ziTB2pEAhMAN4uuB8QmhYvevBin96TbECNMCuIbxenbZYyn1FslXWn29-UA03f8-jau5PubcyEDQ","p":"-Rh3WQ2i3ona_U4kKMR_XGYF6JXwQJAcfUlSfkx6VBI3mmW5uXzWWj8KFgRZEklhGoEq57GCyPWiRARgFOdLRHGQzJidvZaNFqpWw96oFP5eDaOdmLmtthr59l6kUqfQgUwRF_QeHEOlgQrmXBG7-j2hNt0L-YdQIHO0OUEU0Fk","q":"zb67UTECBXKtRfrDoyOvxOc1g7FcUSwGI15Qc_VXIG8ktRtJtj-6ZsnHymO3MXYE3L0ucjxmivj9ow6yVvj6C9uMLmo8AUNhzzF6_FCgHTMERu7pNeRU5ArLMMJA-A5dcMyLCPnGCVFKxhMCEbVeAMs0DfJA6CW1Gk4E61GfOtU","qi":"d4R9BfJKsnOA3ZHpTXtn7mR0uvxPK-mGiYVVLmk0Ko7OSCQxjzYscfle8L3d0iwTPXVVVhazT5ZUN-jOEzmtJ4XQxnfgYqdfxgAXIwducaoz4aptW3GOWcwK9sK_q89IdV3HRQdeJhwUG4IJINBtC7QYvwE9FNhWvC9DsB5VAEo"}]}'
>>> 

Recopier la chaîne contenant le document JSON dans le fichier /etc/authentic2/config.py ou le settings.json du tenant, comme ceci:

A2_IDP_OIDC_JWKSET = {"keys":[{"d":"Y9GJV37oeFlqz2vuZZDsBVfu4u6YLGbMR7ONhedvn3YTMvFxzmeSwjHd2pdoY05TBjgNbDk6QaCKVtqRrHsbbrmYN_6aRIoZk9KiZqLPvnrRUbe0_lLaozJxZjPa4urb8-vsq_Y040DhUEiBog0xjq2RDg7qtcpi5nf0NRNhXbEm2dzIutH22e8WDoUMma8b64NeZgciSmvdu24UUG_eoAt7fsy8xfL81nxA6qk0mWFrjyCpvxmjEotuCBQ79JLzStWeiKkBx80mokNnMTD3bZm-coJRXEPTcKzmtG_NTmNGi1_IZwZslr5cB6F3cyMIsA1y4mYgYu46JNVvUlwIYQ","dp":"OSokOYunlOqOFxOXuMNfdxTyxi2itS5dW2M4S0PBzwlfOU-fD7JWft94sRTOXCP65No_vmw-V2AHnRRj-GgcHdjyIgHkMV4bgtgUkV7HtAmsC_VAdYwnEWOfeaq-izl34DRUt-qN_m6HzNVziC2JtiPum2ifFuS2vrvO4FTPMgE","dq":"QwnEqx3W1MOa5dRhboSwPu4_J5vgwqofjeKrQD1OmEjeowwzJmj5aYiRysZW6IzV5L7XpW081EdxDXI6ddBGWRq-QFlpF9hGxGYQ9qmmohz_ZcVuw5qUdoF113tUA_9aPujG3LPV7S9Jt-R1piN8b7HGUkz_DSVMLzgArlQ4F8k","e":"AQAB","kty":"RSA","n":"yDIt_sOfAY7h5kcyQLimct2R-4PF5K6Fb90xtEAQmZiXzfW2LzhUX4Uow-XLU_shMrAwixAqc-P8A_Sg-IpCHqvcEaIt0tylGThaguN6e6kJxgTU22Oqx4QBCgejm9xMW9kNf15OvudBiuxn5vveR8VFts_pWU-wCNwBw1AHx67E6dszP0C2G7ZN_7v9AI3f3fTj9S1AGzaJHX5bu9aSRFkmVk-K_VBOyovJYYXb3rhFoy16fJWGsxSTLHD9LS_OvpN3_EIj82ziTB2pEAhMAN4uuB8QmhYvevBin96TbECNMCuIbxenbZYyn1FslXWn29-UA03f8-jau5PubcyEDQ","p":"-Rh3WQ2i3ona_U4kKMR_XGYF6JXwQJAcfUlSfkx6VBI3mmW5uXzWWj8KFgRZEklhGoEq57GCyPWiRARgFOdLRHGQzJidvZaNFqpWw96oFP5eDaOdmLmtthr59l6kUqfQgUwRF_QeHEOlgQrmXBG7-j2hNt0L-YdQIHO0OUEU0Fk","q":"zb67UTECBXKtRfrDoyOvxOc1g7FcUSwGI15Qc_VXIG8ktRtJtj-6ZsnHymO3MXYE3L0ucjxmivj9ow6yVvj6C9uMLmo8AUNhzzF6_FCgHTMERu7pNeRU5ArLMMJA-A5dcMyLCPnGCVFKxhMCEbVeAMs0DfJA6CW1Gk4E61GfOtU","qi":"d4R9BfJKsnOA3ZHpTXtn7mR0uvxPK-mGiYVVLmk0Ko7OSCQxjzYscfle8L3d0iwTPXVVVhazT5ZUN-jOEzmtJ4XQxnfgYqdfxgAXIwducaoz4aptW3GOWcwK9sK_q89IdV3HRQdeJhwUG4IJINBtC7QYvwE9FNhWvC9DsB5VAEo"}]}

Ajouter un client OIDC¶

• Pointer votre navigateur sur http://idp/admin/authentic2_idp_oidc/oidcclient/
• Cliquer sur Ajouter un oidc client
• Choisir un identifiant et un identifiant court
• Modifier éventuellement le client_id généré pour utiliser l'identifiant court
• Choisir le schéma d'autorisation:
  • authorization code flow : schéma pour les applications web classique, le code d'authentification est récupéré directement par le serveur est résolu en access token
  • implicit flow : l'access token est directement passé à l'application sans résolution d'un code en s'authentifiant via le client-secret, adapté pour les applications mobiles ou pure JS-client,
• Définir les URIs de redirection, i.e. la liste des URLs sur lesquelles l'IdP redirigera l'utilisateur après l'authentification, attention ce doit être l'URL exacte passée dans le paramètre redirect_uri de la requête d'authentification aucune variation n'est permise (même dans la query string), la norme exige que cette URL utilise HTTPS, mais authentic ne force pas ce comportement
• Définir les URIs de redirection après déconnexion: idem que la précédente mais pour le point d'accès de déconnexion,
• Éventuellement définir une URI d'identifiant de secteur, voir plus loin,
• Définir la politique des identifiants :
  • identifiant unique : retourne l'UUID des utilisateurs dans authentic (unique donc pour tous les services),
  • par paire : un identifiant unique est généré par service en faisant le hash d'un identifiant de secteur (s'il n'y a qu'une URL de redirection c'est le nom de domaine de cette URL, sinon c'est celui de l'URI de l'identifiant de secteur, cela permet de partager les mêmes identifiants uniques entre des services différents), de l'uuid de l'utilisateur et d'une clé secrète (settings.SECRET_KEY, qui doit donc être sauvegardé précieusement),
  • Choisir un algorithme de signature pour les IDToken (= assertions OIDC), soit RSA qui utilisera la clé générée plus haut, soit HMAC qui utilisera le client_secret de chaque service.

Fonctionnement du consentement et de la génération des subs¶

• choisir un identifiant global comme email ou uuid
• choisir pairwise irreversible avec consentement par RP et une même URI d'identifiant de secteur soit consentement par OU et mettre les RPs dans la même OU
• idem avec pairwise reversible

Freeipa¶

Raccordement à Mon-Service-Public.fr¶

Entr'ouvert fournit des prestations pour le raccordement à MSP

La situation¶

Pour les collectivités territoriales ou les organismes publics proposant des services en ligne nécessitant une authentification des utilisateurs, l'authentification unique apporte une grande simplification pour des utilisateurs qui possèdent de plus en plus d'identifiants. Une possibilité est d'utiliser l'un des nombreux fournisseurs d'identités privés sur Internet - Google et Facebook entre autres - une autre est de s'appuyer sur une acteur public incontournable.

Depuis 2009, le portail Internet des administrations françaises propose en Mon-Service-Public.fr - MSP - un service d'authentification unique à destination des collectivités et administrations françaises basé sur les normes ID-FF 1.2 et SAML 2.0 issues du projet Liberty Alliance, et maintenant OAUTH 2.0. Le raccordement d'un service à Mon-Service-Public.fr passe par un accord de raccordement pris avec la Direction de l'information légale et administrative - DILA - en charge du projet MSP et de l'implémentation des normes SAML 2.0 et OAUTH 2.0 dans le service.

Sur mesure¶

Entr'ouvert propose concernant le projet d'un raccordement à MSP des prestations complètes de maîtrise d'ouvrage :

• définition du besoin,
• accompagnement de la relation avec la DILA,
• déclaration CNIL,
• conduite du changement dans vos équipes projets et auprès des utilisateurs,

et de maîtrise d'œuvre :

• développement ad-hoc,
• configuration de vos serveurs,
• intégration au sein de votre SI, ou en collaboration avec vos prestataires, des logiciels nécessaires aux raccordements ;

mais aussi de formation :

• formation à OAUTH 2.0, SAML 2.0, ID-WSF 1.0 ou n'importe quel autre protocole de gestion d'identité,
• formation sur notre bibliothèque Lasso pour C, PHP, Python, Perl ou Java,
• formation sur notre fournisseur d'identité Authentic pour l'adapter à vos besoin ou l'administrer.

Notre expérience particulière sur ce sujet est exemplaire:

• par nos logiciels sont utilisés au sein du projet MSP, dont l'élément principal, le fournisseur d'identité qui utilise notre bibliothèque Lasso en son sein,
• par l'accompagnement que nous avons apporté à un partenaire initial du projet, la Caisse des Dépôts et Consignations.

Schéma type des flux entre votre service, l'usager et MSP suite au raccordement¶

Via une prestation de service (service hébergé par Entr'ouvert)

Entr'ouvert propose aussi un service d'authentification externe hébergé :

• via www.identity-hub.com,
• via une déclinaison en marque blanche de notre fournisseur d'identité.

Ce service peut lui même être raccordé par simple configuration à MSP pour une mise en place en un clic. Nous pouvons ensuite convertir cette authentification vers un protocole d'authentification plus simple et déjà employé par votre application :

• CAS
• OpenID
• OAuth

Si vous choisissiez cette solution pour vos authentifications, nous pouvons dans un même projet fournir en plus de l'authentification MSP d'autres types d'authentifications tels que celles fournies par des acteurs majeurs d'internet tel que Google ou Facebook, ou via des protocoles standardisés tel qu'OpenID 2.0 utilisé par exemple par Google.

Porte-document

Notre expertise ne se limite pas qu'à l'authentification nous pouvons aussi vous aider dans l'utilisations des fonctionnalités suivantes de la plateforme MSP :

• récupération de fichiers dans le porte document d'un utilisateur MSP
• communication via le portail MSP, i.e. envois de messages qui s'affichent dans la page d'accueil des utilisateurs du portail, usuellement pour le suivi d'une procédure,
• dépôt de fichiers, éventuellement signés, dans le porte document de l'utilisateur qui pourra les réutiliser dans d'autres procédures.

Nous proposons ces fonctionnalités soit dans une prestation sur mesure mais aussi via notre service mandataire dans le cas d'une prestation de service, ce qui simplifie grandement leur utilisation. En effet dans le cas de l'utilisation de notre mandataire pour les interactions avec MSP nous pouvons convertir un protocole REST très simple vers les protocoles aux noms barbares utilisés par MSP, tel qu'ID-WSF 1.0.

Entr'ouvert fournit des prestations pour le raccordement à MSP

No shared state IdP with external user directory¶

• We start with the SAML 2.0 IdP
• We first added a deterministic NameID generation mode, by adding a new NameID format setting, called eduPersonTargetedId. In this mode the NameID is computed as hex(sha1(username+entity_id+django_secret_key)).
• Next step is to define a a deterministic way of generating Session Indexes as hex(sha1(NameID+django_session_key)). Lasso is automatically generating a session index when the service provider has a logout endpoint, a session should be generated using the deterministic algorimth (after the call to lasso_login_build_assertion) only if Lasso has also set one.
• Final step will be to store the list of SP for which a session is open in the django session and not in models, method to modify are saml.common.load_session and saml.common.save_session. Session index should only be saved if there is one.

OldHomepage¶

A versatile identity management server.

Features¶

• SAML 2.0 Identity and service provider
• OpenID 1.0 and 2.0 identity provider
• Server CAS 1.0 and 2.0 using a plugin
• Standards authentication mechanisms:
  • Login/password through internal directory or LDAP
  • X509 certificate over SSL/TLS
• Protocol proxying, for instance between OpenID and SAML
• Support of LDAP v2 and v3 directories
• Support of the PAM backend
• One-time password (OATH and Google-Authenticator) using a plugin
• Identity attribute management
• Plugin system

Multiprotocol¶

Originally focused on the SAML protocols, Authentic has evolved to become a trully multiprocol Identity provider : LDAP, SAML 2.0, OpenID, CAS, SSL... are all supported (to different extends). And it keeps evolving to integrate the most used standards.

Additionally it has several extra features; for example it can act as a proxy identity provider, redirecting requests from service providers to other identity providers; or help in forwardig identity attributes to service providers managing attribute namespaces.

Performance¶

The underlying components are quite fast and Authentic doesn't slow things down. There are no hard measure yet but a quick benchmark using autobench yielded more than 300 requests per second on a simple laptop.

Roadmap¶

• multiple user referentials: you can plug authentic to many LDAP, RADIUS, SQL servers without fear of collisions; user can federate their accounts;
• management of all kind of relying parties (CAS, SAML 2.0, WS-Federation, OpenID, etc..) using an unique interface; administrators will not be exposed to peculiarities of the protocols;
• addition of an authorization policy management tool based on RBAC and ABAC, supporting the SAML 2.0 and XACML Authorization requests;
• addition of an authenticating reverse proxy to integrate legacy application and simplify integration, with session management at the reverse proxy level;

SAML 2.0 conformance¶

Authentic implements SAML 2.0 through the use of Lasso, which has been certified as conformant to SAML 2.0 in december 2006.

Install¶

from source
from debian packages
from git repository (Browse)

Documentation¶

Administration guide (PDF version)

Discuss¶

Authentic's developpers and users hangs on the mailing list authentic@listes.entrouvert.com

Reports¶

You want to use but it does not work as you would like; you found a bug; you have a remark submit your remark or your bug ! Developers will work on it !

Principes d'ajout d'un fournisseur de service (SP) via PHP-OAuth2¶

On imagine une application PHP qui désire obtenir des utilisateurs depuis le fournisseur OAuth2 d'Authentic2.
L'application est disponible sur https://application.example.net
Authenitc2 est installé sur https://idp.example.net

Installer le module PHP-OAuth2¶

Source : https://github.com/adoy/PHP-OAuth2/

Créer un fichier https://application.example.net/oauth2.php¶

... ou n'importe quel autre nom, avec ce code :

<?php

require('Client.php');
require('GrantType/IGrantType.php');
require('GrantType/AuthorizationCode.php');

const REDIRECT_URI           = 'https://application.example.net/oauth2.php';      //  URL définitive à transmettre à Entr'ouvert
const AUTHORIZATION_ENDPOINT = 'https://idp.example.net/idp/oauth2/authorize/';
const TOKEN_ENDPOINT         = 'https://idp.example.net/idp/oauth2/access_token/';
const USER_INFO              = 'https://idp.example.net/idp/oauth2/user-info/';

const CLIENT_ID     = 'xxxxxxxxx';             // à demander à Entr'ouvert
const CLIENT_SECRET = 'yyyyyyyyyyyyyyyyyyyy';  // à demander à Entr'ouvert

$client = new OAuth2\Client(CLIENT_ID, CLIENT_SECRET);

if (!isset($_GET['code'])) {
  $auth_url = $client->getAuthenticationUrl(AUTHORIZATION_ENDPOINT,
REDIRECT_URI);
  header('Location: ' . $auth_url);
  die('Redirect');
} else {
  $params = array('code' => $_GET['code'], 'redirect_uri' => REDIRECT_URI);
  $response = $client->getAccessToken(TOKEN_ENDPOINT, 'authorization_code',
$params);
  $info = $response['result'];
  $client->setAccessToken($info['access_token']);
  $response = $client->fetch(USER_INFO);
  $compte_citoyen = $response['result'];

  // ... et ici se placera la construction ou la mise à jour de l'utilisateur
  // local, puis de la session, etc... dépendant de l'application.

  var_dump($compte_citoyen); // debug...
}

?>

Indiquez à Entr'ouvert l'URL du fichier¶

Par exemple ici https://application.example.net/oauth2.php, et placez bien cette valeur dans la variable REDIRECT_URI du code PHP.

Entr'ouvert vous fera alors parvenir un "CLIENT_ID" et un "CLIENT_SECRET"¶

Ces "CLIENT_ID" et "CLIENT_SECRET" devront être copiés dans le code PHP.

Cliquer sur https://application.example.net/oauth2.php¶

Vous devez être envoyé sur l'IdP : logez-vous et vous reviendrez sur l'application avec un compte.

Tickets prioritaires et/ou faciles¶

• #39406: Fournir dans le backoffice (/manage/) des écrans de configuration de la gestion et de la fourniture des identités
  • je commencerai par FC le plus simple, faut commencer par introduire un modèle père générique (AuthenticationSource) dans l'application authentic2
• #45061: éviter les erreurs multiples en cas de souci de base dans un cron
• #41919: champs adresse avec autocomplétion; pris par Manu mais ça pourrait changer
• #45064: baser les imports/exports sur eo_utils.ods http://git.entrouvert.org/eo-utils.git/tree/README

Validation des courriels¶

• un secret connu uniquement du service, S,
• l'adresse de courriel à valider C
• un identifiant pour l'objet lié à ce courriel, I,
• la période entre deux notifications de validation du mail, pN,
• la durée de validité du compte sans validation du mail, dV,
• une URL pour la page de validation, U.

1. 1. La page d'enregistrement collecte l'adresse de courriel. Cette adresse est marqué comme non validé bien que rattaché à l'objet I et deux tâches de fond sont configurés, toutes deux identifiées par la paire (I, C):
   • une tâche périodique d'envoi de notification à début immédiat, et périodicité pN envoyant un lien L formaté de la sorte à l'adresse de courriel C:
     

     Q = "id=" + urlencode(_I_) + email=" + urlencode(_C_) + "&notOnOrAfter=" + urlencode(iso8601(now + _dN_))
     _L_ = _U_ + "?" + Q + "&signature=" + base64(hmac-sha1(_S_, Q))
     

   • une tâche ponctuelle de suppression du compte invalide à la date now+dN

1. 2. L'utilisateur reçoit le courriel de notification et clique sur le lien de validation
2. 2.a. Il a cliqué avant la date limite: les paramètre d'URL sont validés, l'adresse de courriel C est marqué comme valide dans son rattachement à l'objet I. Toutes les tâches de fond liés à la paire (I, C) sont supprimés.

1. 2.b. Il a cliqué après la date limite, la validation des paramètres d'URL par la signature hmac-sha1 échoue, un message d'erreur est affiché expliquant le dépassement du délais.

1. 3. La date now+dN advient sans qu'aucune validation n'ai été effectuée. Le rattachement du courriel C à l'objet I est défait et les tâches liés à cette invalidation sont effectués (suppression du compte par exemple), toutes les tâches liés à la paire (I, C) sont supprimées.

Durant toute la période now - now+dN, l'application pourra se servir de l'adresse C sans problème.

Authentic¶

Authentic aims at being a multiplexer of a maximum of authentication and security protocols, in order to improve interoperability between free softwares and ease identity management for little organizations. KISS is our moto.

Authentic vise à établir des passerelles entre un maximum de technologies d'authentification et de sécurité pour améliorer l'interopérabilité entre logiciels libre et facilité la gestion des identités dans les petites organisations. KISS est notre mot d'ordre.

White sheet / Fonctionnalités¶

• SAML 2.0 Idp/SP
• OpenIDConnect OP/RP
• CAS 1.0 & 2.0 IdP
• LTPA IdP
• Local database authentication
• LDAP authentication
• SSL authentication
• Kerberos (HTTP Negotiate) authentication
• Role Based Access Control (RBAC)

Documentation¶

• Fournisseur d'identité OIDC
• API Authentic
• Configuration en tant que ServiceProvider
• Configuration de la création de compte et de l’authentification par numéro de téléphone mobile

R&D projects for interns / Projets pour stagiaires/contributeurs¶

• a simple cookie + key/value storage non-federated SSO like LemonLDAP::NG | un mode de SSO non fédéré basé sur des cookies et une base clé/valeur

Related links / Liens connexes¶

• Authentication and identification By Stephen Downes
• Laws of identity by Kim Cameron
• Guide to authorization on www.owasp.org