Produits Entr'ouvert » Authentic 2

La mise à jour d'une instance d'Authentic en version 4.82-1~eob110+1 vers 5.21-1~eob110+1 à casser les accès à une application utilisant l'IDP CAS : le ticket est bien généré, mais au moment de sa validation, j'ai l'erreur suivante :

Jan 24 17:25:13 sso-preprod-02 authentic2[1646195]: 192.168.3.67 - r:7FEEBBA37EB0 ERROR unable to compute an identifier for user 'XXXX' and service XXXX
Jan 24 17:25:13 sso-preprod-02 authentic2[1646195]: 192.168.3.67 - r:7FEEBBA37EB0 WARNING validation failed service: 'XXXX' code: INTERNAL_ERROR

Ce service utilise l'attribut LDAP "mail" comme identifiant de l'utilisateur et en ajoutant un peu de debug dans le code (/usr/lib/python3/dist-packages/authentic2_idp_cas/views.py, ligne 267), je constate que l'attribut LDAP est effectivement manquant :

Jan 24 17:31:15 sso-preprod-02 authentic2[1658829]: 192.168.3.67 - r:7FB6055697F0 ERROR unable to compute an identifier for user 'XXXX' and service XXXXXX (attribute = mail, attributes = {'request': <WSGIRequest: GET '/idp/cas/serviceValidate?service=XXXXXX&ticket=ST-AieWsxHXYsjMDOCyawYkIKdINj'>, 'user': <User: 5775 (95df72)>, 'service': <Service 'XXXXXX'>, '__wanted_attributes': ['mail'], 'django_user_id': 6066, 'django_user_password': 'XXXX', 'django_user_last_login': datetime.datetime(2024, 1, 24, 16, 31, 8, 213521, tzinfo=<UTC>), 'django_user_uuid': '95df726dd34d48eb8bae9a57da2d3258', 'django_user_username': '5775', 'django_user_first_name': 'XXXXXX', 'django_user_last_name': 'XXXXX', 'django_user_email': 'support@easter-eggs.com', 'django_user_email_verified': True, 'django_user_email_verified_date': datetime.datetime(2017, 8, 18, 17, 11, 50, 898526, tzinfo=<UTC>), 'django_user_email_verified_sources': [], 'django_user_is_superuser': True, 'django_user_is_staff': True, 'django_user_is_active': True, 'django_user_date_joined': datetime.datetime(2017, 8, 18, 17, 11, 50, 898526, tzinfo=<UTC>), 'django_user_modified': datetime.datetime(2019, 4, 2, 16, 44, 14, 328022, tzinfo=<UTC>), 'django_user_ou_uuid': '0430bd21fae5460fa7852d12f2bff24c', 'django_user_ou_slug': 'default', 'django_user_ou_name': 'Collectivité par défaut', 'django_user_first_name:verified': False, 'django_user_last_name:verified': False, 'django_user_groups': [], 'django_user_group_names': [], 'django_user_domain': '', 'django_user_identifier': '5775', 'django_user_full_name': 'easter-eggs Support', 'a2_role_slugs': <RoleQuerySet []>, 'a2_role_names': <RoleQuerySet []>, 'a2_role_uuids': <RoleQuerySet []>, 'a2_service_ou_role_slugs': <RoleQuerySet []>, 'a2_service_ou_role_names': <RoleQuerySet []>, 'a2_service_ou_role_uuids': <RoleQuerySet []>})

En grattant un peu le sujet, j'ai compris que le problème venait du fait qu'on tentait de récupérer les attributs de l'utilisateur à partir d'un objet User en non pas un objet LDAPUser. En remontant à la source de la récupération des attributs, j'ai pu constater que dans la méthode ValidateBaseView.get_attributes de la version 4.82-1~eob110+1, l'objet user passer dans le contexte à la méthode authentic2.attributes_ng.engine.get_attributes était récupéré à l'aide de authentic2.utils.misc.get_user_from_session_key quand dans la version 5.21-1~eob110+1 on utilise directement l'utilisateur issu de la base et récupéré à partir du Ticket.

user = get_user_from_session_key(st.session_key)
assert user.pk  # not an annymous user
assert st.user_id == user.pk  # session user matches ticket user
st.attributes = get_attributes(
    {
        'request': request,
        'user': user,
[...]

VS:

st.attributes = get_attributes(
    {
        'request': request,
        'user': st.user,
[...]

En faisant un rollback à ce sujet, tout refonctionne comme avant.

Je ne sais pas ce qui a motivé ce changement, mais cela introduit une régression et cela me fait dire qu'il doit manquer un test unitaire à ce sujet.