The representation returned by the routes have a new additional_informations
key that contains an ldap
entry:
{
"id": "string",
"uri": "string",
"label": "string",
"users_uri": "string,
"short_name": "string",
"key": "string",
"project": "string"
"additional_informations": {
"ldap": {
"dn": "cn=developers,ou=groups,dc=tuleap,dc=local",
"label": "Developers",
"synchro_policy": "auto|never"
"bind_option": "bind|preserve_members"
}
}
}
Details of the keys:
-
dn
: is the LDAP/AD Distinguished Name of the group at the LDAP side (it's identifier)
-
ldap
: is the cn
associated to the dn
-
synchro_policy
:
-
auto
: the group membership is synchronized with the LDAP server every day
-
never
: the group membership is never synchronized automatically
-
bind_option
:
-
bind
: when synchronization is done, users are added and removed from Tuleap group to match LDAP group
-
preserve_members
: when synchronization is done, users are only added to the Tuleap group, never removed.
Permissions:
-
ldap
is only available to project_admins
- This information is not available to regular users.
-
dn
is only available to site administrators (either site admin or with "site admin REST read only" permission.
- This is required because project admins don't have the information about the structure of the AD/LDAP and this might leak sensitive information.
Note for developers: the complex part of this story will be the integration REST tests as it will require setup an LDAP server and to pre-fill it with groups and users before running the tests.