Skip to content

Nested custom attributes handled inconsistently in LDAP property mapper #7088

@silicht

Description

@silicht

Describe the bug
I would like to migrate from an OpenLDAP + Keycloak setup to Authentik, but I have identified a problem with the LDAP property mapper. The mapper does not handle nested object fields like attributes.firstlevel.secondlevel as expected.

To Reproduce
Steps to reproduce the behavior:

  1. Configure a LDAP property mapping with a nested object field like attributes.firstlevel.secondlevel
  2. Let the LDAP sync run
  3. Check the generated user attributes

Expected behavior

firstlevel:
  secondlevel: value

Current behaviour

firstlevel.secondlevel: value

This behaviour is the opposite of how prompts handle nested object fields. A prompt with a configured field key attributes.firstlevel.secondlevel creates a nested yaml structure like described in the "expected behaviour" section above.

This inconsistency makes it difficult to migrate from OpenLDAP to Authentik if a large number of attributes are to be migrated from LDAP to Authentik in a structured way.

Version and Deployment (please complete the following information):

  • authentik version: 2023.8.1
  • Deployment: docker-compose

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions