flexible, Open Source Multi Factor Authentication (2FA)
flexible, Open Source Multi Factor Authentication (2FA)

Features

privacyIDEA is a multi-tenancy, multi-instance two factor authentication system. It ships a WebUI for configuration, central token management and user-level self-service. privacyIDEA supports many hardware and software token types and can be connected to many services through plugins.

The behavior of the system if fully configurable through policies and event handlers. It is written in Python and brings a REST API interface which makes scripting easy as well as to integrate privacyIDEA in your own web portals.

privacyIDEA brings its own WebUI interface. Impressions can be best obtained from the Screenshots page.

Integration

privacyIDEA integrates well with all types of corporate environments. Within your own network infrastructure it runs best on its own (virtual) linux machine.

privacyIDEA Token Types

  • HOTP / TOTP one time password Token, provided by hardware or as a soft-token
    • TokenSafeNet/eToken Pass, Safeword, Feitian, VASCO, Daplug, Smartdisplayer (all OATH tokens), Push-Button key fobs, OTP cards
    • Smartphone Apps like privacyIDEA Authenticator, Google Authenticator or FreeOTP.
  • mOTP Token – time based One Time Password tokens for mobile phones based on an a public Algorithm.
  • TAN lists which represent a list of OTP values
  • Push Token – A challenge response token, that sends a challenge to the user’s smartphone and the user simply accepts the request to login.
  • Email Token to send a one time password via email
  • SMS Token to send one time password via SMS (SMSOTP, mTAN, mobileTAN)
  • TiQR – A Smartphone token that can be used to login by only scanning a QR code.
  • WebAuthn token to support the modern web authentication (starting from privacyIDEA 3.3)
  • U2F – A U2F device as specified by the FIDO Alliance. This is a USB device to be used for challenge response authentication.
  • Yubikey in all modes (OATH HOTP, Challenge Response, Yubico AES) to authenticate against privacyIDEA or against the Yubico Cloud service. Enroll many Yubikeys at once with the privacyIDEA admin tool or the YubiKey Personalization Tool.
  • NitroKey – Open Source hardware token which is supported by privacyIDEA in HOTP and TOTP mode. You can also use the admin tool to mass-enroll NitroKey with privacyIDEA.
  • Questionnaire Token – A token that contains a list of answered questions. During authentication a random question is presented as challenge from the list of answered questions is presented. The user must give the correct answer to authenticate.
  • Four Eyes – Meta token that can be used to realize a Two Man Rule
  • Registration Token used in certain enrollment procedures
  • Spass – The simple pass token. A token that has no OTP component and just consists of the OTP pin or (if otppin=userstore is set) of the userstore password. I may be used for testing or to selectively bypass the 2FA of privacyIDEA.
  • Password Token – A token with a temporary password, enrolled during the lost token scenario.
  • x509 Certificate Token issued by a connected certificate authority
  • SSH public key: The SSH token contains the public SSH key. This SSH key can be distributed to Machines for SSH login.
  • RADIUS and Remote Tokens to forward the request to a RADIUS server or another privacyIDEA server
  • WebAuthn – privacyIDEA supports authentication via WebAuthn.
  • New Authentication devices can be added by creating a new python class inherited from TokenClass.

Authentication

  • Authentication via a REST API with and easy authentication with JWT.
  • Returns JSON output for easy parsing
  • Can act as a Identity Provider in conjunction with SimpleSAMLphp or Keycloak
  • Provides a RADIUS interface with the privacyIDEA freeRADIUS plugin
  • Many applications can be secured with privacyIDEA. Plugins are already available for
    • PAM (supporting Offline OTP)
    • Apache2,
    • OTRS,
    • Django,
    • ownCloud,
    • WordPress,
    • TYPO3,
    • Contao,
    • dokuwiki,
    • Jitsi…
  • Using the policy module privacyIDEA can bypass incoming authorization requests to a secondary RADIUS server if the queried user has no token in privacyIDEA yet. This is especially useful for a user-unnoticed migration from an old 2FA system (e.g. RSA SecurID) to privacyIDEA.

Login

  • Users and administrators can login to the privacyIDEA WebUI.
  • Users and administrators can either authenticate against their userstore (e.g. a domain password) or against privacyIDEA (using OTP).

Management

  • Admin Dashboard (v.3.4)
  • Create Resolvers and Realms to manage users
  • Define unlimited administrative reams and configure fine-grained permissions through Policies to adapt to all environments and work-flows.
  • Manage tokens: enroll/delete, assign/unassign, set PIN, import, enable/disable, reset user PIN, re-sync token, set and view detailed token info
  • Get OTP values for a given token
  • Get the token serial number for a given OTP value
  • Define token default settings
  • Set a token validity period
  • Limit token usage (either per day or per use counter). Thus you can limit the token usage to e.g. 10 successful logins or 20 login attempts or to be valid only for the next two weeks.
  • Lost Token: easily enroll a temporary password token to a user, who has lost his token
  • Simple Migration via RADIUS policies
  • Define event-triggered actions through powerful Event Handlers
  • Use the WebUI to schedule Periodic Tasks
  • Useful tools like the privacyidea-token-janitor for special tasks
  • Scriptable due to accessible API and python interface

Self Service

  • Configurable enrollment wizard to welcome new users to make the enrollment as smooth as possible.
  • The user can access the WebUI, where he can manage his own tokens.
  • Enroll new tokens via QR-Code (Google Authenticator), via seed or via serial number of the token.
  • Use the free privacyIDEA App for Android and iOS to store and manage OTP tokens
  • Delete, disable, enable, set PIN
  • View the audit logs, that are concerned with his user account or his tokens.

Users

  • Users can be found in external user stores like flat files (/etc/passwd or self generated files), many different SQL databases, LDAP, OpenLDAP, Active Directory and many other LDAP servers and SCIM servers.
  • Settings for the user table in the SQL database can be defined in detail. Presets for special user tables from
    • WordPress,
    • OTRS,
    • ownCloud,
    • and Tine 2.0 are available to make the setup easy.
  • Settings for the users in LDAP directories can be defined in detail. Presets for OpenLDAP and Active Directory are available to make the setup easy.
  • Several of these so called resolvers can be combined to a realm. privacyIDEA can manage unlimited realms to segment the user base as required
  • privacyIDEA can create, modify and delete users in SQL user stores.

Policies

A core functionality of privacyIDEA is the sophisticated policy module that allows a fine-grained configuration of the system.

  • Policies can be defined for the token management, system configuration, self service, authentication, authorization, enrollment and auditing.
  • A policy is valid for certain users, realms, administrators, administrator actions, requesting clients, requesting token types and many more.
  • Admin scope: Policies can define what an administrator is allowed to do (each action) in the management interface.
  • System scope: Policies can define which administrator is allowed to configure privacyIDEA.
  • Self service scope: Policies can define what a user is allowed to do with his tokens in the selfservice portal. If he needs to authenticate to the self service portal with his account password or with a token. The type of allowed actions can be different if he logs in from the local network or from the internet.
  • Authentication scope: e.g. if a user should use an extra OTP PIN with the OTP value to login or use his LDAP password with the OTP value to login.
  • Authorization scope: If certain token types or serial numbers are required to login. Thus security levels can be define, allowing the login to a restricted are only with hardware tokens and to less secure areas also with software tokens.
  • Enrollment scope: Policies can define how many tokens a user is allowed to get assigned or how many tokens a realm is allowed to contain. Can set random OTP PINs during enrollment and define the required OTP PIN strength.
  • Audit scope: Policies can define which administrator is allowed to view the audit log.
  • Policies can be imported and exported, enabled and disabled through the WebUI or the command-line tool pi-manage.

Event Handler

Event Handlers allow to let events trigger certain actions. Any API event can be selected and optionally further refined by additional constraints. For the actions, several Event Handler Modules are available.

  • Define actions like user email, SMS notification or custom log-messages as reaction to any triggering event.
  • Defining handled events does not change the original behavior
  • RequestMangler and ResponseMangler to fine-tune the request and response behavior of the system
  • Script handler to run custom scripts on user-defined events
  • Add own handler modules made easy by clear module design.

Audit and Logging

A detailed audit log is written to an SQL database and/or to the python logging system. This approach supports simple log files and/or sophisticated central logging system such as Logstash or Splunk as demonstrated in the privacyIDEA blog.

  • The audit entries are digitally signed and checked against deletion (tamper protected)
  • The audit log keeps track about the event, the success of the event, who issued the event, what token was involved, additional detail information, the client from which the request originated, the privacyIDEA server on which it was executed.
  • privacyIDEA allows to setup an audit rotation to save disk space and serve your privacy policies
  • The event handler module Logging can write event-driven custom log messages.

Machines and Applications

privacyIDEA implements machines concept, which can be used to define access rules for specific hosts to certain applications.

  • You can define client machines.
  • You can define application types (SSH, PAM, LUKS).
  • Tokens can be assigned to those applications on those client machines to support offline authentication like Yubikey authentication at LUKS or SSH public key authentication.

Database

  • All Token data is stored in an SQL database. SQLalchemy is used, so you can use SQLite, MySQL, PostgreSQL, Oracle, DB2.
  • The Token secrets in the database are AES encrypted
  • Encrypted import of third-party token seeds is supported