Authentic

Doc officielle (en partie obsolète) : https://authentic2.readthedocs.io/en/latest/

Pour cela, il faut accéder à l'interface d'admin d'Authentic : https://connexion.exenple.fr/admin/ (par exemple)

Puis, aller dans : Authentic2_Idp_Cas / Applications / Ajouter et renseigner le formulaire comme suit :

• Nom : FQDN de l'application par exemple, c'est juste pour l'affichage
• Identifiant court : une version abrégée est auto-complété automatiquement, mais vous pouvez l'ajuster : il ne doit pas contenir que des lettres, des chiffres ou des tirets.
• Collectivité : choisir le plus souvent Collectivité par défaut qui sera l'unique choix
• URLs : renseigner l'URL de service : il s'agit de l'URL passée dans le paramètre GET service lors de la redirection de l'utilisateur vers le serveur CAS pour connexion. Plusieurs URLs peuvent être renseignées en les séparant par des retours à la ligne
• Nom de l'attribut : sélectionner l'attribut qui doit être envoyé comme étant le login de l'utilisateur. Le plus souvent, il faudra sélectionner identifiant (django_user_username) correspondant à l'attribut LDAP considéré comme le login de l'utilisateur dans sa version synchronisée dans la base de données d'Authentic. Pour certaines applications, il pourra être utile dans sélectionner un autre, comme l'adresse email (courriel (django_user_email)).
• Mandataire : pour des cas particuliers uniquement, lorsque l'application est accédée au travers une autre application agissant en tant que proxy CAS
• Déconnexion / URL : renseigner l'URL de déconnexion de l'application. Il faut faire attention ici que l'URL de déconnexion ne provoque pas dans la foulée une reconnexion, car la déconnexion ne fonctionnera pas dans ce cas.
• Utiliser une iframe au lieu d’un tag img pour la déconnexion : peut-être coché si l'application ne supporte pas l'appel de cette URL dans une balise HTML <img>. Le plus souvent, tester sans et cocher la case si cela ne fonctionne pas correctement. Remarque : l'inclusion dans une iframe peut également être bloqué par l'application cliente, notamment via l'entête HTTP X-Frame-Options.
• Temps d’expiration pour les iframe de déconnexion (en ms) : à ajuster en fonction de la lenteur de prise en compte d'une déconnexion par l'application cliente. Il s'agit d'un timeout, donc mieux vaut prévoir assez large si l'application est un peu lente.
• Attributs pour les tickets : on renseigne ici les attributs qui seront transmis à l'application en plus du login de l'utilisateur (sélectionné ci-dessus). Il faudra renseigner ici, pour chaque attribut :
  • Identifiant court : le nom de l'attribut, tel que communiqué à l'application cliente
  • Nom de l'attribut : sélectionner le nom de l'attribut correspondant. On distingue ici trois types d'attributs en fonction de ce qu'il y a entre parenthèses après leur nom :
    • django_* : il s'agit des attributs synchronisés régulièrement (et à chaque connexion) depuis l'annuaire LDAP et stockés en base de données par Authentic. Il est préférable de les utiliser en priorité lorsqu'il existe. Note : attribut mono-valué uniquement pour le monent du fait d'un bug.
    • LDAP : attributs récupérés directement depuis l'annuaire LDAP qui peuvent être mono-valués ou multi-valués.
    • pas de suffixe entre parenthèses : il s'agit le plus souvent d'attributs générés à la voler par Authentic, soit en fonction d'une méthode issue de la configuration (voir paramètre ATTRIBUTE_SOURCES), soit d'attributs standard prévus par Authentic.

Authentic permet d'écrire soi-même la méthode de génération d'attributs qui seront ensuite diffusables aux services utilisant le SSO. Pour cela, il faut les déclarer dans la variable de configuration ATTRIBUTE_SOURCES comme suit :

def generate_fullname(ctx):
    return ctx['user'].attributes.first_name + " " + ctx['user'].attributes.last_name
 
ATTRIBUTE_SOURCES = [
    ('function', {
        'name': 'fullname',
        'dependencies': ['user'],
        'function': generate_fullname
    }),
]

attrs = ctx['user'].get_attributes(None, ctx)
return attrs.get('edupersonaffiliation', [])

Exemple complet pour la génération de l'attribut eduPersonScopedAffiliation :

import logging
 
log = logging.getLogger('config')
 
def generate_eduPersonScopedAffiliation(ctx):
    attrs = ctx['user'].get_attributes(None, ctx)
    if 'edupersonaffiliation' not in attrs:
        log.warning('generate_eduPersonScopedAffiliation: no edupersonaffiliation attribute found')
        return []
 
    domain = os.environ.get('EDU_SCOPED_AFFILIATION_DOMAIN')
    if not domain:
        log.warning('generate_eduPersonScopedAffiliation: EDU_SCOPED_AFFILIATION_DOMAIN not found in env')
        return []
 
    log.debug('generate_eduPersonScopedAffiliation: edupersonaffiliation = %s / domain = %s', attrs['edupersonaffiliation'], domain)
    return ["%s@%s" % (aff, domain) for aff in attrs['edupersonaffiliation']]
 
ATTRIBUTE_SOURCES = [
    ('function', {
        'name': 'eduPersonScopedAffiliation',
        'dependencies': ['user'],
        'function': generate_eduPersonScopedAffiliation
    }),
]

Sous Debian Jessie, erreur au démarrage d'authentic :

  File "/usr/lib/python2.7/dist-packages/authentic2/settings.py", line 82, in <module>
    MIDDLEWARE_CLASSES = plugins.register_plugins_middleware(MIDDLEWARE_CLASSES)
  File "/usr/lib/python2.7/dist-packages/authentic2/plugins.py", line 84, in register_plugins_middleware
    for plugin in get_plugins(group_name):
  File "/usr/lib/python2.7/dist-packages/authentic2/plugins.py", line 38, in get_plugins
    raise PluginError('unable to load entrypoint %s' % entrypoint, e) PluginError: ('unable to load entrypoint authentic2-idp-saml2 =
authentic2.idp.saml:Plugin', VersionConflict(django-import-export 0.2.7.4.g7225dff (/usr/lib/python2.7/dist-packages), Requirement.parse('django-import-export>=0.2.7')))

Cela viens du fait que le paquet python-setuptools proviens des backports et n'apprécie pas la syntaxe des numéros de version des librairies python fournis avec Authentic.

Utilisé l'outil en ligne : http://rnd.feide.no/simplesaml/module.php/saml2debug/debug.php

Authentic dispose d'une fonctionnalité de rôle permettant de restreindre à des fonctionnalités d'Authentic et/ou à l'accès à des services utilisant le SSO.

Pour mettre en œuvre un rôle “Salariés” synchronisé depuis un groupe du même nom dans l'annuaire, il faut :

• Créez le groupe dans l'annuaire LDAP
• Créez le rôle dans Authentic :
  • Dans l'interface /manage/, allez dans Rôles puis cliquez sur le bouton Ajouter un rôle :
    • Nom : Salariés
    • Description : Rôle synchronisé depuis le groupe “Salaries” de l'annuaire LDAP
  • Cliquez sur le bouton Sauvegarder
  • Récupérez l'identifiant court (=slug) du rôle (dans notre cas salaries)
• Éditez le fichier de configuration d'Authentic (/etc/authentic2/config.py le plus souvent)
  • Dans la configuration LDAP (LDAP_AUTH_SETTINGS), pour chaque bloc concerné, ajoutez une entrée dans la clé group_to_role_mapping :

    LDAP_AUTH_SETTINGS=[
        {
            "realm": "ldap_users",
            [...]
            "group_to_role_mapping": [
                ('cn=salaries,ou=dyngroups,o=enercoop', ['salaries']),
            ],
        },
        [...]
    ]

• Pour prise en compte à la prochaine connexion d'un utilisateur, rechargez la configuration du service :

  service authentic2 reload

authentic2-manage sync-ldap-users

Il est ensuite possible par exemple de restreindre l'accès à un service :

• Dans l'interface /manage/, aller dans Services puis sélectionner le service de votre choix
• Sous Rôles autorisés à se connecter à ce service / Ajouter un rôle, sélectionnez un rôle et cliquer sur le bouton Ajouter