Multi-Tenancy, Multi-Instance two factor authentication system.
Supported authentication devices:
- Simple pass token, which in fact always says ACCEPTED.
- HOTP / TOTP: SafeNet/eToken Pass, Safeword, Feitian, Smartdisplayer (all OATH tokens)
- Push-Button key fobs, OTP cards, Smartphone Apps like Google Authenticator or FreeOTP.
- TiQR token for easy authentication by scanning QR code.
- RADIUS token to forward authentication request to a RADIUS server
- REMOTE token to forward authentication request to another privacyIDEA server
- Email-Token to send one time password via email
- SMS-Token so send one time password via SMS (SMSOTP, mTAN, mobileTAN)
- Yubikey in all Modes: OATH HOTP, Challenge Response, Yubico AES
- Day OTP token: Token that uses one password for a day and changes the password the next day.
- Password token: which combines the OTP PIN with an additional password. Internally this is used for the lost token scenario.
- SSH public key: The SSH token contains the public SSH key. This SSH key can be distributed to machines for SSH login.
- x509 certificates issued by connected certificate authorities.
- Registration Token for easy deployment.
- New Authentication devices can be added by creating a new python class inherited from TokenClass.
- Authentication via a REST API with easy authentication with JWT.
- Returns easy parsable JSON output
- Can act as a SAML Identity Provider in conjunction with SimpleSAMLphp
- Plugins available for
- PAM (supporting Offline OTP)
- 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).
- Create Resolvers and Realms
- View the audit log
- Manage tokens: enroll/delete, assign/unassign, set PIN, import, enable/disable, reset user PIN, resync token, 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
- Token validity period
- Maximum 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 attemps or to be valid only for the next two weeks.
- Create lost token: enroll a temporary token to a user, who has lost his token
- Define policies
- Simple Migration via RADIUS policies
- Define arbitrary actions based on any action
- 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.
- Delete, disable, enable, set PIN
- View the audit logs, that are concerned with his user account or his tokens.
- 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
- 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.
- privacyIDEA can create, modify and delete users in SQL user stores.
- Sophisticated policy module that allows a detailed behaviour configuration.
- 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 selfservice 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 securiy 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: Polcies 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.
- Define actions like user email notification as reaction to any triggering event.
- Defining handled events does not change the originial behaviour.
- Enhance event handling by easy module design.
- a detailed audit log is written to an SQL databse
- 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.
Machines and 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.
- 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