KDE Identity is the single sign-on system for KDE websites. It consists of an LDAP server and a custom web application for signup and account management. KDE developers and users only need to register once at KDE Identity, and they can use that account to login to most KDE websites.
To sign up, users enter their email address, and the website sends a confirmation link. After clicking the confirmation link, they enter a username and password. Login is then done with the username. Usernames are unique, and cannot be changed by users (sysadmins can change a username, but currently it takes lots of manual work to do it).
To login to an Identity-enabled website, users simply enter their KDE Identity username and password on the website itself, which verifies the credentials via LDAP.
Identity is currently hosted on orbi.
There are Ansible playbooks to do all the setup of Apache, MySQL, PHP, LDAP, and the website code. The playbooks are complete enough to replicate the environment locally.
To easily install a local clone of Identity, to work on either the deployment or the web code:
git clone https://invent.kde.org/sysadmin/kde-ansible git clone https://invent.kde.org/websites/identity-kde-org cd identity-kde-org vagrant up
You can now access the Identity website at localhost:8080. All emails the website sends (such as confirmation links when creating an account) will be captured by Mailhog; you can go to localhost:8025 to read them.
To access the ldap server from the host machine:
ldapsearch -H ldap://localhost:50389 -x -D uid=site-admin,ou=people,dc=kde,dc=org -w '(replaceme)' -LLL -b "dc=kde,dc=org" "uid=site-admin"
Services using Identity¶
Several Wordpress and Drupal instances use Identity too; need to track those down.
The websites and services that are currently integrated with KDE Identity login are:
MediaWiki (via Phabricator OAuth)
Jenkins (via Phabricator OAuth)
Events platform (events.kde.org)
Conference management (conf.kde.org)
Akademy volunteer management
Website statistics (stats.kde.org)
Mailserver (sending email through mail.kde.org)
Ballot (KDE eV voting)
Notable services that don’t use Identity (have independent accounts):
The server runs OpenLDAP.
Debian/Ubuntu by default installs OpenLDAP
with settings stored in a
in ldif format, where changes are made through ldapadd/ldapmodify.
We disabled this and changed it back to
The LDAP daemon listens only on localhost; it’s not accessible over the Internet. Servers running Identity-enabled websites connect to LDAP via an SSH tunnel.
There is a custom KDE LDAP schema,
adding the object classes
and their attributes.
They are under the registered OID
Users are stored with LDAP object class
Members of KDE eV additionally have the
kdeEvMember object class,
Groups have both
groupOfNames object classes.
Groups list all their members as usernames in
memberUid attributes (
and as DNs in
member attributes (
Users also have a
pointing back at the group name.
A few groups grant additional permissions within LDAP, via ACLs in slapd.conf:
All users belong to this group
Active members of the KDE sysadmin team. They get permissions to modify everything.
KDE developers with commit access. Developers can have SSH public keys in their profile. Their basic info (username, name, email) can be seen by everyone. They can see detailed info about other developers. Group membership here is synchronized into access to kde/* in GitLab.
Developers who had their commit access disabled (usually on their request). They can still have SSH public keys, but they have no effect. They get no permissions on GitLab. Everything else is the same as
developers(eg. public email addresses).
Members of KDE e.V (including inactive). They can see information about other eV members. They have memberStatus and evMail attributes, and they can change their own evMail.
Board members of KDE e.V. Board members can edit the
ev-boardgroups, can see and change every ev-members’ evMail and memberStatus, and can see basic info about every user (so that they can add any user to ev-members).
People who can give Identity tech support. They can see info about every user, in order to deal with user requests about forgetting username, etc.
All other groups have no effect on LDAP attribute permissions or other behavior of Identity itself. They are only used by other services to manage their own permissions. For example, access to website statistics or to some Nextcloud shared folders is controlled via these groups.
SSH keys in LDAP aren’t used anymore; developers upload their keys to GitLab. Above docs need fixing to reflect that. Perhaps the Neon git repositories do still use them; need to investigate.