Index par titre

Configurer celeryd pour gérer les agents

sudo /etc/init.d/celeryd restart

Configurer l'agent wcs

From here to there

Plus tard

Jupiter and Beyond the Infinite

Faire en sorte que hobo couvre le déploiement des tenants.

On intègre du code dans hobo

Ça donnerait ça :

hobo

le serveur de déploiement : gestion de l'environnement dans le /manage et envoi du hobo.json correspondant dans celery

hobo.multitenant

reprendre entrouvert.djommon.multitenant (fait avec conservation de l'historique, dans la branche wip/merging-multitenant de hobo, #6468)

hobo.agent

réception du hobo.json dans le celery, déploiement de tous les services correspondant via l'appel de commandes de ce genre :
sudo -u service /usr/lib/service/manage.py hobo_deploy www.example.net < hobo.json

hobo.agent.authentic2

ne contient que la commande de management hobo_deploy dédiée au déploiement d'un tenant authentic2 :

hobo.agent.common

ne contient que la commande de management hobo_deploy dédiée au déploiement d'un SP mellonisé :

hobo.middleware.settings.mellon

configuration des settings.MELLON* depuis les données de tenant/www.example.net/metadata_idp_0.xml et le hobo.json si besoin

hobo.middleware.settings.authentic2

configuration des settings.SAML* depuis saml.crt et saml.key

hobo.middleware.context.vars

création des templatesvars depuis le hobo.json du tenant

Processus de création d'un tenant

Le celery client reçoit un environnement hobo.json. Pour chaque tenant de chaque service listé dans cet environnement, il lance la commande de déploiement du service. Pour un service djangoisé, c'est typiquement :

sudo -u service /usr/lib/service/manage.py hobo_deploy www.example.net < hobo.json

Ce "hobo_deploy" va lancer la commande de management programmée dans hobo/agent/<service>/management/commands/hobo_deploy.py

Processus de mise à jour d'un tenant

Le processus de création est configurer pour gérer un tenant qui existe déjà, et ne rien faire dans ce cas, juste mettre à jour le hobo.json, et s'il est différent mettre à jour les métadonnées, etc. Ces mises à jour sont prises en compte aussitôt par le tenant via les middlewares.

Notes de RER que bof

hobo pourrait fournir: from hobo.helper.settings.mellon import * # config de base MELLON ouaip bon bofff

Profil utilisateur

Cette page reprend les différents endroits où la définition des champs d'un profil utilisateur s'établit.

(infos tirées de Vincennes)

Authentic

first_name, last_name et email sont des champs standards, définis dans les sources.

Les autres sont définis dans l'admin, /admin/authentic2/attribute/ (correct ?)

Les types des attributs sont définis dans les settings (sinon il n'y a qu'un seul type "chaîne"):

A2_ATTRIBUTE_KINDS = [
        {
            'label': u'Civilité',
            'name': 'title',
            'field_class': forms.ChoiceField,
            'kwargs': {
                'choices': [
                    ('monsieur', u'Monsieur'),
                    ('madame', u'Madame'),
                ],
            }
         },
        {
            'label': u'Date de naissance jj/mm/aaaa',
            'name': 'birthdate',
            'field_class': forms.RegexField,
            'kwargs': {
                'regex': r'^\d\d/\d\d/\d\d\d\d$'
            }
         }
 ]

Dans la config, il y a aussi des infos pour la page d'édition et d'enregistrement de compte:

    "A2_PROFILE_FIELDS": [ "username", "email", "civilite", "first_name",
        "last_name", "date_de_naissance", "telephone", "mobile", "adresse_numero_voie", "adresse_type_voie",
        "adresse_nom_voie", "adresse_complement", "code_postal", "ville", "pays" ],
    "A2_REGISTRATION_FIELDS": [ "username", "email", "civilite", "first_name",
        "last_name", "date_de_naissance", "telephone", "mobile", "adresse_numero_voie", "adresse_type_voie",
        "adresse_nom_voie", "adresse_complement", "code_postal", "ville", "pays" ],
    "A2_REGISTRATION_REQUIRED_FIELDS": [ "first_name", "last_name" ],

Cela permet de définir l'ordre, la présence et la nécessité (pour la page d'enregistrement) des champs.

Des attributs peuvent aussi venir d'un serveur LDAP si une authentification LDAP est configurée:

LDAP_AUTH_SETTINGS = [
        {
            'url': 'ldapi:///',
            'basedn': 'dc=entrouvert,dc=org',
            'transient': False,
            'username_template': '{uid[0]}@{realm}',
            'external_id_tuples': (('dn:noquote',), ('uid','entryUUID'), ),
            'lookups': ('external_id',),
            'update_username': False,
            'attributes': ['uid', 'cn'],
        }
]

Ici seront extraits les attributs uid, cn et entryUUID. Les champs qui définissent les attributs à extraire sont attributes, external_id_tuples, email_field (valeur par défaut email), fname_field (valeur par défaut givenName) et lname_field (valeur par défaut sn).

SAML2

Les attributs à partager doivent être définis dans la page de configuration du fournisseur SAML, ne pas oublier de transférer la liste des noms de groupe dans l'attribut 'role' pour les droits d'administration dans les applications.

OAuth2

Les attributs à partager doivent être définis dans la page de configuration du client OAuth2, ne pas oublier de transférer la liste des noms de groupe dans l'attribut 'role' pour les droits d'administration dans les applications.

Portail citoyen

Quatre attributs sont attendus du web-service user_info de l'IdP:

Ils sont utilisés tel quels pour retrouver l'utilisateur ou le créer (via username) et le pré-remplir.

Pour provisionner les super administrateur on définir le paramètre ALLAUTH_A2_ADMIN_ROLE qui devra être une valeur reçue via l'attribut role.

w.c.s.

Fiche d'un utilisateur, /admin/settings/users/fields/

Correspondance des attributs, /admin/settings/identification/idp/idp/https-connexion.vincennes.fr-idp-saml2-metadata/edit

Dans la page de correspondance il faut aussi définir les attributs qui donne les droits d'administration, par exemple role -> Administrateur.

Wiki

Profil utilisateur
Configurer celeryd pour gérer les agents
From here to there