privacyIDEA Authentication System

privacyIDEA is an authentication system. Quite a while ago we started to drop the sole OTP statement. privacyIDEA is managing authentication objects. Yes, a classical OTP key fob token is an object a user can use to authenticate. As is a smartphone.

But privacyIDEA already facilitated SSH keys. These files are objects, a user can use to authenticate.

Trust the privacyIDEA Certificate Authority

In this release 2.18 we improved the functionalities of the local CA. privacyIDEA provides an interface to connect to certificate authorities to ask them to issue certificates for the users.

Connectors can plug into this interface. At the moment we are providing a “local CA” connector, which connects to a locally running OpenSSL based CA. With privacyIDEA 2.18 setting up such a local CA is much easier. The local CA also supports automatically generating the CRL, if a certificate token is revoked. The CA now also can handle certificate templates with different X.509 extensions and different validity periods.

For a complete list of all features, enhancements and fixes see the Changlog at Github.

Use a local CA

Certificates are a special token type with privacyIDEA. The documentation at readthedocs has more detailed information about the certificate handling in privacyIDEA. We will give you a quick idea what is new in regards to the local CA.

Create your local CA

You can use the pi-manage tool to create a CA Connector, list all CA Connectors and also create CRLs.

pi-manage ca create myCA

This will create a CA Connector of type “local CA”. You are asked the following questions:

Creating CA connector of type local.
In which directory do you want to create the CA [./ca]: /etc/privacyidea/myCA
What should be the keysize of the CA (2048/4096/8192) [4096]: 
How many days should the CA be valid [1800]: 7200
What is the DN of the CA [/CN=myCA]: 
How many days should the CRL be valid [30]: 60
What should be the overlap period of the CRL in days [5]: 10
============================================================

Directory : /etc/privacyidea/myCA
 CA DN : /CN=myCA
 CA Keysize : 4096
 CA Validity: 7200

Validity of issued certificates: 365

 CRL validity: 60
 CRL overlap : 10
 
Is this configuration correct? [y/n]

When answering “yes”, the CA will be created on the file system and also within privacyIDEA the CA Connector definition, that links to this CA will be created.

Enroll Certificate

Now, the administrator can immediately start enrolling certificates for the users. The certificates will be issued by “myCA”, which we just created.

At the moment, we can not use certificate templates, we need to create an additional configuration file to do so.

A templates.yaml defines, which special X.509 extensions from the openssl.cnf file should be used and what should be the number of days, this very certificate will be issued for.

A file /etc/privacyidea/myCA/templates.yaml might look like this:

user:
    days: 365
    extensions: "user"
email:
    days: 750
    extensions: "email"

This file needs to be specified at Config -> CAs -> myCA.

This way you can enroll certificates with different attributes for certain purposes.

Installation and servies

There are different ways to install privacyIDEA which are well documented in the online documentation. Checkout the Github repository to file and issues, post your ideas or pull requests. Or simply star the project.

If you are running privacyIDEA mission critical you might want to take a look at the privacyIDEA Enterprise Edition provided by NetKnights GmbH.

Certificates and Hardware Security Modules

The certificate handling in privacyIDEA was improved. Administrators can now enroll a certificate token for a user and also generate the RSA key pair. Users can download the certificate and the private key as a PKCS12/PFX container. This is useful in certain scenarios where a VPN client requires the local installation of a client certificate that stays on the machine.

In addition support for hardware security modules like the Nitrokey HSM was added. This was done by adding a PKCS11 security module.

Time Dependent Policies

It is now possible to restrict policies to certain times. Thus you can allow the login outside of the office hours only with a yubikey while allowing login with a Google Authenticator only during daylight. Or the token management of the C-level group tokens could only be allowed on mondays…

…do what you want!

Event Handler Framework

The event handler is a complete new concept of allowing new workflows in privacyIDEA. Depending on certain conditions each event (REST API calls) may trigger a new action. The administrator may configure the triggered actions in the most flexible manner.

E.g. if a token is enrolled or assigned, the user may be notified about this. The event handler framework allows for any kind of thinkable workflow. Please read our previous post on this topic.

…do what you want!

Changelog

This is the complete changelog.

Features

• Event Handler Framework #360
• local CA connector can enroll certificates for users. Users can download PKCS12 file. #383
• Add and edit users in LDAP resolvers #372
• Hardware Security Module support via PKCS11
• Time dependent policies #358

Enhancements

• Policy for web UI enrollment wizard #402
• Realm dropdown box at login screen #400
• Apply user policy settings #390
• Improve QR Code for TOTP token enrollment #384
• Add documentation for enrollment wizard #381
• Improve pi-manage backup to use pymysql #375
• Use X-Forwarded-For HTTP header as client IP #356
• Add meta-package privacyidea-mysql #376

Fixes

• Adduser honors resolver setting in policy #403
• Add documentation for SPASS token #399
• Hide enrollment link (WebUI) is user can not enroll #398
• Fix getSerial for TOTP tokens #393
• Fix system config checkboxes #378
• Allow a realm to be remove from a token #363
• Improve the date handling in emails #352
• Sending test emails #350
• Authentication with active token not possible if the user has a disabled token #339

This will be things like:

• Event handler to trigger certain actions depending on events
• Improved certificate support
• Editable user resolvers – even in LDAP
• Improvements in the WebUI and policies
• Easy Migration with RADIUS passthru policy

Tübix is a Linux event in the south of Germany, so the talk will be in German. But much time to discuss things, also in the evening utilizing a cold beer.

privacyIDEA is moving towards a central point to manage authentication items. This was done by adding the machine concept, SSH keys, using Yubikeys for booting LUKS and now by adding the possibility to manage certificates.

privacyIDEA acts as a central control room to manage all relevant points. In 2.3 the managing of client certificates was added. But privacyIDEA is not just another certificate authority. No, privacyIDEA follows the same concept as for user resolvers, machines and applications and lets you define CA connectors that – as the name suggests – connects to existing certain certificate authorities. Thus you may even have several CAs for different purposes and configure privacyIDEA to connect to them all.

Then you can assign certificates (a new token type) to the users and have the users enroll their certificates easily from within the modern Web UI. You can read more about this at the online documentation.

Also other interesting things were added like the registration token type, which eases the process of mass enrollment.

Adding the SCIM Resolver provides better means to be integrated into Cloud setups.

The new TYPO3 plugin is interesting for all Web Hosting companies.

The complete ChangeLog looks like this:

• Add connector to remote Certificate Authority.
• Add Tokentype “certificate” to manage certificates for users Certificates or Certificate Requests can be uploaded. Certificate Requests.(Keypair) can be generated in the browser.
• Add Tokentype “registration” for easier enrollment scenarios.
• Add TokenType “Email” to send OTP via Email.
• Add “First Steps” to online documentation to ease the process of getting up and running.
• Add handling of validity period of token.
• Enable download of Audit log as CSV.
• Add Resolver Priority, to handle a duplicate user in a realm.
• Add TYPO3 Plugin to enable OTP with TYPO3
• Add SCIM Resolver to fetch users from SCIM services
• Several Fixes like:
  • Failcounter issue
  • NTLM password check
  • timestep during enrollment
  • Yubikey CSV import

As usual there are several different ways to install or upgrade the system.

After the initial Fork many new authentication aspects have been added. The Yubikey could be used to authenticate against LUKS to boot your notebook.

With the concept of applications and machines, the new SSH token type was added, that lets you manage all public SSH keys. Thus having a central system to manage the accounts, identities or authentication object of your users.

The upcoming release 2.3 will provide the first implementation of managing certificates. The CA Connector concept allows to connect to any existing certificate authority. The first connector type will connect to a local running OpenSSL based CA. Implementing new connector types to connect to other certificate authorities, even like Microsoft CA, is possible.

We just pushed the implementation for enrolling a certificate. In this first simple case, a Certificate Signing Request is passed with the token initialization API and the Request is signed by the CA which is connected via the CA connector. The certificate is then stored as a new tokentype within the token database.

Thus you will see all OTP-Tokens, SSH Keys and Certificates of a user in one place.

The release of 2.3 is planned for June 11th. But stay tuned – it might come early!

Further reading:

The Certificate Concept

Enroll a Certificate