---

title: TPA-RFC-86: Identity and Access Management affected users: tor-internal deadline: September 22nd, 2025 status: proposed discussion: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41839

---

Summary: implementation of identity and access management, as well as single sign on for web services with mandatory multi-factor authentication, replacing the legacy userdir-ldap system.

[[TOC]]

Background

As part of the Tails Merge roadmap, we need to evaluate how to merge our authentication systems. This requires evaluating both authentication systems and establishing a long-term plan that both infrastructures will converge upon.

Multiple acronyms will be used in this document. We try to explain them as we go, but you can refer to the Glossary when in doubt.

Tails authentication systems

Tails has a role-based access control (RBAC) system implemented in Puppet that connects most of its services together, but provides little access for users to self-service. SSH keys, PGP fingerprints, and password hashes are stored in puppet, by means of encrypted yaml files. Any change requires manual sysadmin work, which does not scale to a larger organisation like TPO.

Tails' Gitlab and gitolite permissions are also role-based. The roles and users there can be mapped to those in puppet, but are not automatically kept in sync.

Tails lacks multi-factor authentication in many places, it is only available in Gitlab.

TPA authentication systems

TPA has an LDAP server that's managed by a piece of software called userdir-ldap (ud-ldap), inherited from Debian.org and the Debian sysadmins (DSA). This system is documented in the howto/ldap page, and is quite intricate. We run a fork of the upstream that's customized for Tor, and it's been a struggle to keep that codebase up to date and functional.

The overview documents many of the problems with the system, and we've been considering replacement for a while. Back in 2020, a three-phase plan was considered to migrate away from "LDAP":

1. stopgap: merge with upstream, port to Python 3 if necessary
2. move hosts to Puppet, replace ud-ldap with another user dashboard
3. move users to Puppet (sysadmins) or Kubernetes / GitLab CI / GitLab Pages (developers), remove LDAP and replace with SSO dashboard

The proposal here builds on top of those ideas and clarifies such a future plan.

TPA has historically been reticent in hooking up new services to LDAP out of a (perhaps misplaced) concern about the security of the LDAP server, which means we have multiple, concurrent user database. For example Nextcloud, GitLab, Discourse and others all have their own user database, with distinct usernames and passwords. Onboarding is therefore extremely tedious and offboarding is unreliable, at best, and a security liability at worse.

We also lack two-factor authentication in many places: some services like Nextcloud and GitLab enforce it, some don't, and, again, each have their own enrolment. Crucially, LDAP itself doesn't support 2FA, a major security limitation.

There is no single-sign on, which creates "password fatigue": users are constantly primed to enter their passwords each time they visit a new site which makes them vulnerable to phishing attacks.

Proposal

This RFC proposes major changes in the way we do Identity and Access Management. Concretely, it proposes:

• implementing rudimentary identity management (IdM)
• implementing single sign on (SSO)
• implementing role based access control (RBAC)
• switching mail authentication
• removing ud-ldap
• implementing a self-service portal

This is a long-term plan. We do not expect all of those to be executed in the short term. It's more of a framework under which we will operate for the coming years, effectively merging the best bits and improving upon the TPA and Tails infrastructures.

Architecture

This will result in an architecture that looks like this:

This diagram was rendered using PlantUML with this source file, for editing use the online editor.

Identity Management

The implementation of Identity Management (IdM) is meant to ensure our userbase matches the people actually involved in our organisation. It will automate parts of the on- and off-boarding process.

Our IdM will consist of a number of scripts that pull identity data from sources (e.g., the core contributor membership list, the HR spreadsheet, at some point our future human resources (HR) system, etc.) and verify if the known identities based on our sources match the userbase we have in our LDAP. In case of any mismatch, an issue will automatically be created in Gitlab, so TPA can manually fix the situation. A mismatch could be a user existing in LDAP but not in any of the sources or vice versa. It could also be a mismatch in attribute data, for instance when someone's surname differs between HR and LDAP or a nickname differs between HR and the core contributor membership list.

For this to work, identity sources need to be machine readable (this could be as simple as a YAML file in a git repository) and include a unique ID for every identity that can be used to match identities across sources and identities. This will prevent issues when people change names, PGP keys, email addresses, or whatever other attribute may be misassumed to be immutable.

Apart from identity data, sources may also (explicitly as well as implicitly) provide group membership data. For instance, a user can be part of the 'core contributors' group because they are included in the core contributor membership list. Or the employee group because they are marked as employee in our HR system. These group memberships are considered attribute data (the memberOf attribute in LDAP) and treated as such for determining mismatches.

Finally, some systems cannot lookup user data from LDAP and their userbase needs to be manually maintained. For these systems the IdM scripts will also monitor whether group data in LDAP matches the userbase of certain destination systems. For instance, all members of the employee group in LDAP should be members of the tor-employees mailing list, etc.

Considering the cost of maintaining custom software like this and security considerations regarding automated access to our LDAP, resolving mismatches will not be automated. The IdM system merely monitors and creates Gitlab issues. The actual resolving will still be done by humans.

Next to the IdM scripts, we will enforce auditability on all changes to user data. This means sources must leave an audit log (either an application log or something like the history from a git repository, preferably with signed commits) and our LDAP server will maintain a transaction log.

The IdM scripts should be written in such a way to reduce future technical debt. The scripts should be written with best practices in mind, like test driven development (ideally with 100% test coverage), good linting coverage (e.g. mypy --strict if Python). Exceptions can be made for rare exceptions where churn from APIs outside our control will cause too much work.

Single Sign On

Single Sign On is meant to replace the separate username/password authentication on all our web services with one centralised multifactor login. All our web services are to use OIDC or SAML to authenticate to our Identity Provider. The Identity Provider will authenticate to LDAP for password authentication, as well as demand a second factor (WebAuthn) for complete authentication. For each service, the Identity Provider only allows access if the user is fully authenticated and is member of an appropriate group, de facto implementing RBAC.

The most likely candidate for implementing Single Sign On seems to be lemonldap-ng, which provides all the functional requirements (OIDC support, SAML support, MFA, LDAP backend, group-based access control) and is packaged in debian.

Centralising all our separate username/passwords into one login comes with the security concern that the impact of a password leak is far higher, since that one password is now used for all our services. This is mitigated by mandatory MFA using WebAuthn.

For SSO authentication to succeed, users must exist on the services we authenticate to. To ensure this is the case, for each service we will have to choose between:

• Synchronising the userbase with LDAP. Some services (e.g., Nextcloud) provide the ability to synchronise their users with an external LDAP server. This is the preferred approach.
• Just In Time (JIT) provisioning. Some services provide the ability to automatically create an account if it does not yet exist upon successful authentication. This requires our IdM scripts to monitor the userbase, since users that have left the organisation may keep lingering.
• Manually create and remove users. This requires our IdM scripts to monitor the userbase.

Some webservices may not natively support SSO, but most can delegate authentication to the webserver. For these cases, we can use mod-auth-openidc or mod-auth-mellon to have Apache perform the SSO authentication and pass the user data on to the backend using HTTP headers.

We will connect the following services:

Service	Native SSO support	User Provisioning
Nextcloud	OIDC and SAML	LDAP-based
Mailman	OIDC	Manual
LimeSurvey	No, use webserver	JIT
Metrics	No, use webserver (but keep it accessible for bots)	?
Gitlab	OIDC and SAML	JIT, no need for deprovisioning
Forum	OIDC and SAML	JIT, no need for deprovisioning
RT	SAML	?
CiviCRM	OIDC and SAML, additional web server authentication	LDAP-based
Weblate	OIDC and SAML	JIT, no need for deprovisioning
Jenkins	OIDC and SAML, additional web server authentication	Manual?
Hedgedoc	OIDC	JIT, no need for deprovisioning
Remote.com	SAML	?

TPA will need to experiment which protocol is easier to implement and maintain, but will likely default to using OIDC for authentication. There are, however, services that only support SAML and vice versa.

Servers with "additional web server authentication" mean that those servers will have authentication at the application level (e.g. CiviCRM doing OIDC) and web server level (e.g. Apache with mod-auth-oidc).

BTCPayServer cannot be connected to SSO and will continue with separate username/password authentication, albeit with an IdM-monitored userbase.

Chat and SVN are left out of scope for this proposal. Their future is too unclear to plan ahead for these services.

Role Based Access Control

Role Based Access Control (RBAC) is meant to ensure that authorisation happens based on roles (or group membership), which match actual organisational roles. This prevents long access control lists with numerous individuals that are hard to manage and even harder to audit. It also prevents pseudo-solutions like roles called 'nextcloud-users'. An individual changing roles within the organisation should be a matter of changing their group membership and all the required/no longer required access should be granted/revoked based on that.

For our webservices, our SSO will restrict access based on group membership. Access control within the services are left out of scope for this proposal, but service admins are encouraged to adopt RBAC (the user's roles will be provided by as memberOf attributes by the Identity Provider).

For access to servers, TPA will adopt the puppet-rbac module that Tails already uses. All UNIX users, sudo rights, and ssh-based access will be managed using this module. Instead of using ud-ldap, puppet will read the user and group data from LDAP and create the appropriate resources. SSH keys will be stored in LDAP and distributed through puppet. Password authentication for sudo will be done through pam-ldap, but we will not be using LDAP for NSS. This means that sudo authentication will be based on the same LDAP password as your SSO login and people will no longer have separate password for separate servers. It also means users' SSH keys providing access will be the same on every server. While this may be a slight regression security-wise, it vastly simplifies administration. In cases where security requirements really call for separate SSH keys or passwords for specific server access, a separate identity could be created to facilitate this (similar to the -admin accounts we have on Gitlab).

As mentioned before, some group memberships are based on data from the identity source. All other groups will have a manager (typically a team lead), who will be able to manage the group's members.

Mail authentication

Currently people can set an emailPassword in ud-ldap, which is synced to a file on the mailserver. This password can be used to configure their mail client to send mail from @torproject.org addresses. This doesn't fit easily into our SSO setup: mail clients generally do not support SSO protocols or MFA and because this password will be stored in configuration files and/or on phones, we don't want to use people's regular LDAP password here.

Sadly, LDAP doesn't have proper ways to deal with users having multiple passwords. Instead of recreating a ud-ldap-like mechanism of synchronising ldap attributes to a local file on the mailserver, we should store password hashes in an SQL database. Users can then manage their email passwords (tokens may be a better name) in the selfservice portal and dovecot-sasl can authenticate to the SQL database instead of a local file. This has the advantage that multiple tokens can be created, one for each mail client, and that changes are active immediately instead of having to wait for a periodic sync.

We introduce a new (SQL) database here because LDAP doesn't handle multiple passwords very well, so implementing this purely in LDAP would mean developing all sorts of complicated hacks for this (multiple entries, description fields for passwords, etc).

usedir-ldap retirement

We will retire ud-ldap entirely. Host and user provisioning will be replaced by puppet. The machines list will be replaced by a static web page generated by puppet.

The Developers LDAP search will be removed in favour of Nextcloud contacts.

The self-service page at db.torproject.org will be replaced by a dedicated self-service portal.

Self-service Portal

We will extend the lemonldap-ng portal to provide a self-service portal where users will be able to log in and manage:

• their password
• their MFA tokens
• their mail access tokens
• their external e-mail address
• personal data like name, nickname, etc.

Users will initially also be able to request changes to their SSH and PGP keys. These changes will be verified and processed by TPA. In the future we may be able to allow users to change their keys themselves, but this requires a risk assessment.

Furthermore, group managers (e.g., team leads) should be able to use this portal to edit the members of the groups they manage.

Goals

• Identity Management
• Aggregation of all identities from their sources (HR, Core Contributor membership, etc.)
• Verification of and alerting on userbase integrity (are LDAP accounts in sync with our identity sources)
• Partial verification of and alerting on group memberships (does the employee LDAP group match the employees from the HR system)
• Audit logs for every change to an identity
• RBAC
• Authorisation to all services is based on roles / group membership
• Groups should correspond to actual organisational roles
• Audit logs for every change in group membership
• SSO
• Web-based services authenticate to an Identity Provider using OIDC or SAML
• The Identity Provider verifies against LDAP credentials and enforces FIDO2
• Self-service Portal
• Users can change their password, MFA tokens, mail tokens, and possibly other attributes like displayname and/or SSH/PGP keys
• Team leads can manage membership of their team-related roles
• ud-ldap retirement

Must have

• auditable user database
• role based access to services
• MFA

Nice to have

• lifecycle management (i.e., keeping track of an accounts end-date, automatically sending mails, keeping usernames reserved, etc.)

Non-Goals

• Full automation of user (de-)provisioning
• RBAC within services
• Solutions for chat and SVN
• Improvements in OpenPGP keyring maintenance

Tasks

IdM

• make HR and CC sources machine readable and auditable
• ensure the HR system maintains an audit log
• ensure the HR system has a usable API
• convert the CC membership list into a YAML file in a git repository or something similar
• introduce UUID's for identities
• design and update processes for HR and the CC secretary (and anyone else updating identity sources) to ensure they use the same UUID (a unique quasi-random string) for everyone
• create attribute mappings
• define which attributes in which identity source correspond to which LDAP attributes and which LDAP attributes are needed and correspond to which attributes in our services and systems
• role/group inventory
• make an inventory of all functional roles within the organisation
• for all roles, determine whether they are monitored through IdM scripts and who their manager is
• for all roles, determine to which systems and services they need access
• design and implement the IdM scripts

LDAP

• manage LDAP through puppet
• make an inventory of what needs LDAP access and adjust the ACL to match the actual needs
• adjust the LDAP schema to support all the required attributes
• ensure all LDAP connections use TLS
• set up read-only LDAP replicas for high availability across our entire infrastructure, ensuring each point of presence has at least one replica.
• replacing ud-ldap with puppet:
• replace host definitions and management in LDAP with puppet-based host management
• have puppet generate a machine list static HTML file on a webserver
• expand the puppet LDAP integration to read user and group data
• replace ud-ldap based user creation with puppet-rbac
• replace ud-ldap based ssh access with puppet-rbac
• configure nss-ldap for SSH authentication
• configure pam-ldap for sudo authentication
• sift through our puppet codebase and replace all privileges assigned to specific users with role-based privileges
• remove ud-ldap

SSO

• deploy lemonldap-ng
• configure SAML and OIDC
• configure the LDAP backend
• configure MFA to enforce FIDO2
• connect services:
• configure attribute mappings
• restrict access to appropriate groups/roles
• configure service to use OIDC/SAML/webserver-based authentication
• set up user provisioning/deprovisioning
• work out how to merge existing userbase

SASL

• create an SQL database
• grant read access to dovecot-sasl and write-access to the self-service
• reconfigure dovecot-sasl to authenticate to the SQL database

Self-service

• decide which attributes users can manage
• implement password management
• implement MFA management
• implement mail token management
• implement attribute management
• implement SSH/PGP key change requests
• implement group membership management
• consider automated SSH/PGP key management

TPA

All the tasks described above apply to TPA.

For each TPA (web)service, we need to create and execute a migration plan to move from a local userbase to SSO-based authentication.

Tails

The Tails infra already uses puppet-rbac, but would need Puppet/LDAP integration deprecating the current hiera-based user and role management.

For each Tails service we need to establish whether to connect it to SSO or rather focus on merging it with a TPA counterpart.

Affected users

Everyone at Tor.

Personas impact

Wren from HR

Wren takes care of on- and offboarding folks. They use remote.com a lot and manage quite some documents in Nextcloud. They only use Gitlab to create issues when accounts need to be created or removed. Wren doesn't use SSH.

When Wren starts the working day by logging in to remote.com. They now need to use their Yubikey to do so. Once they're logged in, though, they no longer need to type in passwords for the other TPI services, they are automatically logged in everywhere.

When onboarding a new employee, Wren will have to explicitly check if they were already a core contributor. If so, the existing UUID for this person needs to be reused. If not, Wren can use a macro in the spreadsheet to generate a new UUID.

Wren no longer needs to create Gitlab issues to ask for accounts to be created for new employees (or removed for folks who are leaving). Once the employee data is entered in the spreadsheet, TPA will automatically be informed of all the account changes that need to happen.

When Wren wants to change their password and/or second factor, they only have to do so in one place now.

Corey, the core contributor secretary

Corey manages core contributor membership. That's all we know about Corey.

Corey used to maintain the list of core contributors in a txt file that they mailed to the list every so once in a while. This file is now structured in YAML and Corey pushes changes to a git repository instead of only mailing them.

Sasha, the sysadmin

Sasha has root access everywhere. They mostly use Gitlab and Metrics. Sometimes they log in to Nextcloud or remote.com. Sasha deals with user management, but mostly writes puppet code.

Sasha has a fair bit to learn about SAML and OIDC, but at least they don't have to maintain various different userbases anymore.

Sasha automatically gets notified if changes to the userbase need to be made. These notifications follow a standard format, so Sasha is tempted to write some scripts to automate these operations.

Sasha can write such scripts, but they are not part of the IdM system and must act with Sasha's authentication tokens, to retain audit log integrity. They could, for example, be a Fabric job that uses Sasha's LDAP credentials.

When users want to change their SSH or PGP key, Sasha needs to manually verify that these are legit changes and subsequently process them. Sasha is never quite sure how strict they need to be with this.

Sasha is happy they no longer need to worry about various access lists that are probably incredibly outdated, since permissions are now granted based on organisational role.

Devin, the service admin

Devin is a gitlab admin. That's all we know about Devin.

Devin can use their regular TPI account to log into Gitlab through SSO. That gets them logged in on their normal use account. For admin access, they still need to log in using their separate admin account, which doesn't go through SSO.

Devin no longer needs to create accounts for new employees. Instead, the new employee needs to log in through SSO once TPA has created their account. Devin does still need to make sure the new employee gets the right permissions (and said permissions are revoked when appropriate). Devin is encouraged to think of a way in which granting gitlab permissions can piggyback on the existing organisational roles.

Team lead Charlie

Charlie is lead of one of the development teams. They have root access on a few machines and regular shell accounts on a few others. They use Gitlab a lot and just discovered Hedgedoc being pretty neat. They use Nextcloud a fair bit, have two mailing lists that they manage, and look at the metrics every so once in a while.

Charlie used to have different passwords to use sudo on the machines they had root access on, but now they just use the same password everywhere. They do still need an SSH key to log in to servers in the first place.

Charlie no longer needs separate usernames, passwords, and 2FA tokens for Gitlab, Nextcloud, Mailman, Metrics, etc. Once logged into the first service, the rest goes automatically.

Charlie no longer needs to have an account on the Tails Gitlab to use Hedgedoc, but instead can use their regular SSO account.

Charlie no longer has to bother TPA to create user accounts for team members on the team's servers. Instead, Charlie can edit who has which role within the team. If a user has the right role, an account will be created for them. Vice versa, when a member leaves the team or gets different tasks within the team, Charlie need only remove their role and the account will be removed.

Kennedy, the contractor

Kennedy is a freelance contractor. They're working with Gitlab and Nextcloud, but don't really use any of the other TPI services.

Kennedy needs to get a WebAuthn device (like a Yubikey) to be able to log in. They're not used to this and the beginning of their work was delayed by a few days waiting for one, but now it works quite easily.

Sullivan, the consultant

Sullivan just does one small job for TPI, but needs shell access to one of our servers for this.

Sullivan probably gets access to the server a bit late, because it's unclear if they should be added in HR's spreadsheet or be hacked in by TPA. TPA wants to know the end-date for Sullivan's access, but that's unclear. The team lead for whom Sullivan works tries to bypass the problem and use their root access to create an account for Sullivan. The account automatically gets removed during the next puppet run. In the end, an end-date for Sullivan's access is made up and TPA creates their account. Sullivan receives an automated e-mail notification when their account is close to its end-date.

Blipblop, the bot

Blipblop is not a real human being, it's a program that interacts with TPI services.

Blipblop used to log in to services with a username and password. Blipblop doesn't understand SAML or OIDC, let alone WebAuthn. TPA has to create some loopholes so Blipblop can still access services without going through the SSO authentication.

Costs estimates

Hardware

• servers:
• SSO server (lemonldap-ng)
• IdM server ("the scripts")
• one LDAP replica (OpenLDAP) per point of presence
• FIDO2/WebAuthn tokens for all our personas

Staff

Phase 1, removing ud-ldap: 31 - 56 days

Task	Estimate	Uncertainty	Total (days)	Note
LDAP ACL update	1 day	high	2
LDAP schema update	1 day	medium	1.5
puppetise LDAP	2 days	medium	3	this includes enforcing TLS
deploy LDAP replicas	2 days	medium	3
deploy lemonldap-ng	4 days	high	8
password selfservice	1 day	high	2
attribute selfservice	2 days	high	4
move hosts to hiera	2 days	high	4
generate machine list	1 day	low	1.1
puppet/LDAP integration	2 days	medium	3
deploy puppet-rbac	4 days	high	8	this still has puppet-rbac use the old LDAP groups
configure pam-ldap	1 day	low	1.1
SQL pass selfservice	1 week	high	10
dovecot-sasl to SQL	1 day	low	1.1
remove ud-ldap	2 days	high	4

Phase 2, RBAC proper: 20 - 40 days

Task	Estimate	Uncertainty	Total (days)	Note
inventory of roles	1 week	high	10
implement roles in puppet	1 week	high	10
group management in selfservice	2 weeks	high	20	this may be quicker if we outsource it

Once phase 2 is completed, the Tails and TPA authentication systems will have been effectively merged. Phases 3 and 4 add further improvements.

Phase 3, Identity Management: 22 - 40 days

Task	Estimate	Uncertainty	Total (days)	Note
ensure access to sources	2 days	high	4	assuming there is no HR system, just a spreadsheet
introduce UUIDs	2 days	medium	3
create attribute mappings	1 day	high	2
write parsers for sources	3 days	high	6	assuming there is no HR system, just a spreadsheet
mechanism comparing sources to LDAP	3 days	medium	4.5
alerting to Gitlab issues	3 days	medium	4.5
comparing sources to mailing list	2 days	high	4
comparing sources to limesurvey	2 days	high	4
comparing sources to weblate	2 days	high	4
comparing sources to btcpayserver	2 days	high	4

Phase 4, SSO: 37 - 72 days

Task	Estimate	Uncertainty	Total (days)	Note
lemonldap-ng as SAML & OIDC IdP	2 days	medium	3
enforcing FIDO2 WebAuthn	2 days	medium	3
ensure everybody has a FIDO2 key	1 week	high	10
connect Nextcloud to SSO	1 day	high	2
connect mailman to SSO	1 day	high	2
connect limesurvey to SSO	1 day	high	2
connect metrics to SSO	2 days	high	4
connect Gitlab to SSO	2 weeks	high	20	this requires extensive testing beforehand
connect forum to SSO	1 day	high	2
connect RT to SSO	2 days	high	4
connect civicrm to SSO	3 days	high	6
connect weblate to SSO	2 days	high	4
connect jenkins to SSO	1 days	high	2
connect hedgedoc to SSO	1 days	high	2
connect remote to SSO	3 days	high	6

Connecting the various systems to SSO are mini-projects in their own right. Some, especially Gitlab, may even require their own RFC.

Timeline

Ideal

This timeline reflects an ideal (and non-realistic) scenario where one full time person is assigned continuously on this work, starting in September 2025, and that the optimistic cost estimates are realized.

• W32-41: phase 1, removing ud-ldap
• W42-47: phase 2, RBAC proper
• W48-51: phase 3, identity management
• end of year break
• W2-3: phase 3, identity management continued
• W4-W12: phase 4, SSO

More realistic

The more realistic timeline assumes this RFC will cause some discussion and work won't start until October 2025. Pessimistic cost estimates are used for this planning: being a bit overly pessimistic here keeps some space for other priorities and not continuously devoting 1FTE to this project.

• W40-51: phase 1, removing ud-ldap
• end of year break
• W2-3: phase 1 continued
• W4-13: phase 2, RBAC proper
• W14-23: phase 3, identity management
• W24-26: phase 4, SSO
• july break
• W28-41: phase 4 continued

Alternatives considered

We considered existing IdM frameworks like:

• OpenIDM
• OpenText Identity Manager
• Okta

However, those are generally too heavy and enterprisey for our needs and our available resources. They start to make sense once organisations have thousands of identities to manage. On top of that, cloud-based frameworks like Okta would enable a third party to completely compromise the organisation.

We considered the various SSO frameworks discussed in discussion on LDAP. The main contenders based on provided functionality were Casdoor, Keycloak, Lemonldap-ng and Zitadel. Casdoor was deemed risky due to it being open-core and not properly FLOSS, Keycloak is a bit of a java monster, and Zitadel is optimised for Kubernetes, which we do not run. On the contrary, lemonldap-ng is already packaged in Debian, which makes it a far easier fit in our infra.

References

• discussion issue
• TPA LDAP documentation
• TPA-RFC-73: Tails merge roadmap

Glossary

• DSA: Debian SysAdmin team. The sysadmins operating many base services on debian.org

• FIDO2: Fast IDentity Online, second version. Web standard defining how servers and clients authenticate MFA, typically with a security key like a YubiKey.

• IdM: Identity Management. Systems and processes that manage user accounts and their life cycles (creation, status, removal).

• LDAP: Lightweight Directory Access Protocol. An object database that's often used for user authentication. Used by TPA with userdir-ldap as a middleware.

• MFA: Multi Factor Authentication. Authentication through multiple credentials, for example with one-time codes generated by a mobile app or delivered over a side channel (email or text messages), or with a security key like a YubiKey.

• NSS: Name Service Switch. The component in UNIX that abstracts name resolutions mechanisms, defaulting to /etc/passwd, /etc/hosts and so on.

• OIDC: OpenID Connect. SSO protocol built on top of OAuth 2.0.

• PAM: Pluggable Access Modules. The UNIX component responsible for setting up login sessions and checking passwords, typically used for sudo and SSH authentication.

• RBAC: Role Based Access Control. Systems and processes that manage and provide authorization based on a user's role / group membership.

• SAML: Security Assertion Markup Language. SSO protocol built on top of XML.

• SSO: Single Sign On. Centralised authentication based on protocols like OpenID-Connect and SAML, where you login with credentials only once across a fleet of services.

• UUID: Universally Unique Identifier. A 128-bit label used to uniquely identify objects in computer systems, defined in RFC 9562. For example, f81d4fae-7dec-11d0-a765-00a0c91e6bf6 is a UUID.

• WebAuthn: part of the FIDO2 standard that defines the API websites use to authenticate users with MFA, for example with a YubiKey.