We are pleased to be able to release privacyIDEA 3.9. This release is an example of how privacyIDEA is ment to centrally manage all you authentication in one place – since successful authentication is a matter of smooth workflows.

privacyIDEA aims to be a management system where the administrator can easily manage the authentication topic for the users. You as an administrator can manage the OTP tokens (TOTP, HOTP apps, Yubikeys), tokentype like SMS or Email, even FIDO2. All you need for two factor authentication.

And privacyIDEA is able to also verify the first factor. The static password.

Old authentication – new token types

But sometimes you might see, that two factor authentication does not work out as expected. That applications do not play well with FIDO2/WebAuthn. Yes, sometimes applications do not play well even with OTP tokens. Take an Email client, that caches the user password and sends it, every time it fetches the emails from the server. The request will fail if it is sent with the same OTP value a second time.

Successful Authentication is not always a matter of choose the most modern cryptographic algorithm or the latest authentication method.

Sometimes there is an old, nasty application that refuses to work well with the 2FA method you are enrolling in your company. But privacyIDEA wants to help you as administrator to manage all these challenges in one system.

With privacyIDEA 3.9 we introduce two new token types which might sound old and insecure, but which are supposed to enable you to take a step forward, even if some old applications want to hold you back.

The application specific password token is simply a static password that can be bound to a specific application. The old application will send an authentication request against privacyIDEA and privacyIDEA will realize, that this auth request originated from this application and allow such application specific password tokens enrolled for this application to be used for authentication. A user can have a specific password for e.g. his email client, save this in his smartphone and privacyIDEA will accept this only for login requests by this email client resp. mail server.
You may check the conceptual evolution of this feature on Github.

The day password token is a similar quirky thing. In certain situations having an OTP token that changes all 30 seconds or 60 seconds may be to changeable for some users or use cases. But using no second factor and relying on a never changing static password is also not an option.

Why not have a token, that can be used for one hour? Or one day? The day password token in privacyIDEA 3.9 is a token type with a variable time window between one second and many days. During this time window the given code is valid during the whole time window and can be used as often as needed. It is similar to TOTP (in fact it is inherited from the TOTP token class), but has the above mentioned special effects.

This token type has its counter part in the privacyIDEA Authenticator App, which you can find in the Google Play Store and Apple App Store. The day password token is supported in the privacyIDEA Authenticator App starting with version 4.2.

Improving SSH Key Management

Managing SSH keys has been a bit cumbersome in the past. You as the administrator had to assign each SSH server to the SSH key, so that the user could use the SSH key to log to this server.

With privacyIDEA 3.9 you can now define service identifiers, which represent the servers. E.g. you could define an identifier “web servers” and assign SSH keys to this identifier.

Now you can simply have the SSH server identify as “web servers” to allow the login with this SSH key. This way it is easy as configuring the corresponding server, to add a new SSH server to the “web servers”.

The helper script privacyidea-authorizedkeys, which is supposed to run on the SSH servers has been modified so that it queires privacyIDEA for the corresponding service identifier.

Changelog

A new event handler can set the application assignment during enrollment. This helps with definding HOTP tokens as Offline-Tokens for the privacyIDEA Credential Provider. The PUSH token can do a decline, so that the authentication process is cancelled.

You can find the complete changelog at Github.

Install and Update

You can download and update privacyIDEA 3.9 via the community repositories for Ubuntu 20.04LTS and Ubuntu 22.04LTS or via the Python Package Index.

If you want to get involved, you can join the discussion at the Forum or coding at Github.

We are happy to inform you, that we released privacyIDEA 3.8 today. 3.8 is an important milestone, since we start to support the Yubikey as a smartcard, that can also be used to login to Windows domains.

Support for smartcard login on Windows systems

privacyIDEA 3.8 can manage the Yubikey as a smartcard that holds a smartcard logon certificate. To obtain the smartcard logon certificate, the privacyIDEA server has a new certificate connector to communicate to all Microsoft Active Directory Certiticate Services in the connected Windows domain.

Thus the certificate on the Yubikey can directly be obtained from the Micrsoft CA but be managed within privacyIDEA.

Rollout during authentication

privacyIDEA supports Multi-Challenge-Response for a while. This mechanism can be used to reset an OTP PIN or authenticate with 4-eyes tokens or index-secret tokens.

In version 3.8 this same mechanism can now be used to enroll a token during authentication. The administrator can define a policy, which token type should be enrolled by the user. In several challenge-response steps thus the user can enroll HOTP, TOTP, email, SMS or PUSH tokens. Email and SMS tokens can even be enrolled in standard applications like the Netscaler.

HOTP, TOTP and PUSH enrollment require the application to display a QR code. This mechanism will be supported by all privacyIDEA plugins for e.g. Keycloak, simpleSAMLphp or ADFS.

Fast login, fast debugging, token groups

Using a new “preferred client mode” the administrator can define, which should be the preferred way for a user to authenticate, in case the user has more than one token type.

The audit log has been greatly improved for bug tracking. It now also records the thread ID of an API request.
Since the threat ID is also contained in the debug log file, this is a great handle to find the relevant detailed information to a specific request in the logs.

privacyIDEA 3.8 comes with the new conecpt of “token groups”. We plan to use this to improve SSH key management and the management of offline tokens.

For more details see the changelog at Github.

Install or Update

You can download and update privacyIDEA 3.8 via the community repositories for Ubuntu 18.04, 20.04 and now also 22.04 or via the python package index.

If you are not using your own source code but use the precompiled privacyIDEA Authenticator released by the company NetKnights, this has the following meaning for you.

Breaking Change in Push-Functionality

In order to increase the stability of the push functionality and the reliability of the delivery of the push messages, we decided to revise the configuration of the Firebase project. As of version 4.0, the app works with a central Firebase project that is managed by NetKnights.

That means your privacyIDEA server will no longer be able to notify the push tokens in the app version 4.0 via the Firebase project you have configure individually. To enable the new and more stable notification feature, you either need to recompile the App or get a subscription from NetKnights to gain access to the central Firebase project.

However, you can also use the precompiled and released Authenticator App without the need for a Firebase project.

Using Push-Token without Firebase project

In this scenario you will use the Push-Poll functionality, where the Authenticator polls the challenges from the privacyIDEA server. Users will have to have the privacyIDEA Authenticator App in the foreground to receive messages.

You need to proceed as follows.

1. Update the privacyIDEA server to version 3.7.1. This will ensure a flawless polling functionality
2. If not yet configured, create a policy in scope “Authentication” with the setting “push_allow_polling” = “allow”.
3. If not yet configured, create a policy in scope “Enrollment” with the setting “push_firebase_configuration” = “poll only”.
4. If you already have a “push_firebase_configuration” policy, change it to “poll only”.
5. To receive the Push notification, the user must open the privacyIDEA Authenticator. The notifications will be polled or the user can actively poll the notifications by swiping downwards.
6. The configuration of the Firebase project in your privacyIDEA server can be deleted.

We take great pleasure in releasing privacyIDEA 3.7 today. It has been a long way since version 3.6. We implemented a lot of fixes and smaller but interesting enhancements. However, the most interesting new features are probably the redesign of the offline-token, a token verification during enrollment and a new supported way for encrypting the sensive data in privacyIDEA with a hardware security module.

Hardware Security Modules

Hardware Security Modules (HSMs) are expensive. Especially if you need a network attached HSM that provides the necessary performance to encrypt the OTP seed for each authentication request. This is the way how privacyIDEA currently supported HSMs. It is secure – but it is slow (unless you have the right hardware) and costly.

In privacyIDEA 3.7 we provide a new security module with a different approach. The idea was born in discussing security and speed with an enterprise community member.

The new security module encryptkey.py still holds the encryption keys in a keyfile. But this keyfile again is encypted with an assymmetric key on an HSM. The keyfile is decrypted by the HSM on startup and then the encryption keys from the keyfile are stored in memory. This way the slow HSM operation will only occur when starting or restarting the web server process. This allows you to use much cheaper HSMs or even Smartcards to protect your key material.

Still – you should be familiar with smartcards or HSMs and know what you are doing, to avoid wrecking your senstive data.

Offline Token

privacyIDEA allows clients like the privacyIDEA Credential Provider to fetch offline information to allow a user to login with a specific HOTP token, even if the privacyIDEA server can not be reached. However, this was always bound to the IP address of the client machine.

We removed the IP binding and redesigned the process. This way it is now much easier and more robust to use an HOTP token for offline authentication at your Windows notebook.

Verify Enrollment

When enrolling a smartphone HOTP or TOTP token, the user needs to scan a QR code that was generated by privacyIDEA. Only after scanning this QR code with a authenticator smartphone app, the token is technically enrolled on the user side. Administrators reported that sometimes some users forgot to scan the QR code. Thus privacyIDEA deemed the token as enrolled, while nothing existed on the user’s smartphone.

With 3.7 the administrator can now force the user to enter a valid OTP value during the enrollment process. This way the user is required to scan the QR code to be able to provide the valid OTP value. Only then privacyIDEA deems the token as successfully enrolled.

Further Enhancements

There are a lot of further enhancements.

Policies can now also use web server environment variables as conditions.

In version 3.6 custom user attributes have been introduced. In 3.7 the administrator can now define event handlers to set or delete custom user attributes. This way, you could e.g. set an attribute to a user as soon as the user enrolls a certain token type. Then you could have authentication policies, that take this token type as a condition, only allowing those users to do certain things.

Possibilities are many. We do not know them all! Find yours!

You can find the complete changelog at Github.

If you are running privacyIDEA in mission critical environments, the company NetKnights which staffs the core developers, also provides services and support.

If you want to get involved with privacyIDEA you can also visit the community forum.

We are proud to release the privacyIDEA simpleSAMLphp Plugin 2.1. We added a new feature, that allows the administrator to configure real Single Sign-On or secure 2FA requirement.

In Single Sign-On mode, the user is asked for the second factor only once. In the secure 2FA requirement, the user is required to provide his second factor for each application where he wants to log in.

The administrator can configure this behavirour in the config file with the parameter “SSO”.

The new version of the privacyIDEA simpleSAMLphp plugin is available via Github. You can download the code there and add it to your installation.

We are proud to present you privacyIDEA 3.6. Administrators and Users can manage custom user attributes. These additional attributes can overwrite and enrich the existing user attributes, which privacyIDEA reads from the user stores. This way the token administrator in privacyIDEA has additional possibilities to manage the users and to manage the user rights. These user attributes can be used within privacyIDEA policies. In addition policies can now also contain any token attribute like tokentype or fail counter. These attributes and policy conditions help administrators to keep control in larger setups by logically grouping users and tokens.

Policies with Custom User Attributes and Token Attributes

privacyIDEA is no Identity Management. Users are usually managed in an IdM, or only in LDAP or Active Directory. Nevertheless it can be important to add attributes to users – in case the token administrator has no access rights to the IdM or user directory. The administrator can now do so in privacyIDEA 3.6 using custom user attributes. The administrator can even allow users to manage their own attributes. This way the user can e.g. update his mobile number himself, without the need to contact the help desk or the administrator.

Based on these user attributes the administrator can now define policies and thus the access rights can be tuned in more detail.

In addition policies can now have conditions on each and every token attribute like description, serial, tokentype, otp length, maximum failcounter, failcounter, active state and more.

This way the administrator could allow helpdesk users to only delete tokens, that have previously been disabled by the user himself. Possibilities are endless.

Simple PUSH Token

Starting with privacyIDEA 3.0 we introduced the PUSH token. If everything works out fine, the PUSH token can work like a charm. But setting it up is quite complicated. Also the Push services by Google and Apple actually do not work that reliably. With privacyIDEA 3.6 the administrator can now configure the PUSH token to only work in a polling method. In this scenario no external 3rd party service is needed and the user’s smartphone only communicates with the privacyIDEA server.

By giving up some comfort such a setup can gain stability and improve the privacy aspect.

Token Rollover

The administrator can now configure a WebUI policy to allow users to roll over their tokens. This means that the key material is generated anew and the user can enroll the token again, e.g. by scanning a new QR code. This comes in handy, if the user is only allowed to have one token, but wants to move his token to a new smartphone or if the company decides to increase the key size of the tokens.

Enhancements

Besides these main features there are a lot of enhancements. The administrator can use pi-manage to export and import the system configuration. This can be used to move configuration from testing environments to productive environments. You can have different PIN policies for different tokentypes.

In pi.cfg the system administrator can define a custom entry point for the WebUI. This way you can create your complete own WebUI without changing anything in the code.

The token janitor received several improvements. It can export arbitrary user attributes, the seed can either be exported in hex or base32 to increase the interoperability with other MFA systems. The token export can now also contain the user assignment. This way tokens can easily be transferred between different privacyIDEA installations.

You can find the complete Changelog at Github.

Availability

You can download privacyIDEA 3.6 from Github or install it from the Python Package Index. For easy deployment you can use the community repositories for Ubuntu 16.04, 18.04 and 20.04. You can find the installation guidline in the online documentation. If you are updating, it is crucial to read the READ_BEFORE_UPDATE, which contains important information about LDAP resolvers and TLS.

If you want to get involved, be sure to drop by at the community forum. You can also take a look at Weblate, were the community can translate to different languages. We are grateful for the community effort to be able to ship translations in Dutch and French!

For mission critical scenarios the company NetKnights provides an Enterprise Edition with Support.

We had launched a survey about the satisfaction and experience with privacyIDEA. 95% of the respondents said they had gerneral experience with two-factor authentication. Most of them found privacyIDEA via Google, a quarter via recommendations from friends and acquaintances.

In most cases, privacyIDEA is used for VPN and web applications. The use for Single Sign-On like via Keycloak, SimplSAMLphp or ADFS is at about 40% but is catching up.

privacyIDEA is a true open source project. Planning and development is actively done on Github. Just over half of the respondents have either starred the Github repository, posted an issue, or even contributed code.

Documentation and plugins

We received individual feedback that the user could not easily and quickly find the information in documentation he was looking for. This is understandable for us, since privacyIDEA is a complex product that can be approached from many different angles. If you give us feedback on the documentation, please always let us know, what info you need and where you were looking for it. These details help us to understand how you are reading the docs and improve the documentation at the right place.

We have received feedback on the Keycloak plugin and the ADFS plugin. For the Keycloak plugin we are currently working on a new version. The ADFS plugin has been so far developed by a single developer in the community. We now started a new ADFS plugin in the privacyIDEA project, which will then seamlessly integrate like the plugins for Keycloak or simpleSAMLphp into the privacyIDEA universe.

Specifically, the flexibility and the many authentication possibilities of privacyIDEA were praised. We continue to expand these. The reason for this survey was the evaluation of biometrics via facial recognition or typing behavior and the consideration of whether to extend privacyIDEA with a corresponding token type.

Biometrics

The two biometric methods work the same in terms of the rough principle. During registration, biometric data is captured (face or typing behavior) as a mathematical representation; this mathematical representation is then stored in the cloud by the vendor of the method. privacyIDEA takes care of the assignment of the user to the corresponding data set within the vendor’s cloud service. So while privacyIDEA itself with the user assignment is running on premises, the mathematical representation would be stored outside of privacyIDEA.

Facial recognition or a typing token could be used in privacyIDEA self service portal when a user has lost his primary token.

When logging in to self service, to Keycloak or ADFS, a Javascript library would capture the data and compute a new mathematical representation. privacyIDEA would send this with an appropriate handle to the cloud service, which would check for equality with appropriate thresholds. Accordingly, privacyIDEA would grant access. Unfortunately, in order to protect their IP and monetize it, today’s vendors prefer to provide the verification service online.

The privacyIDEA users have a similar feeling like ourselves. 65% are pragmatically and see biometric authentication simply as an additional token type, that can be used or not. 40% even see it as a good extension.

However, some users also completely reject the support of biometrics.

Only just over 10% of the respondents would use such a biometric method for self-service login. The rest are undecided; just over half would not use it.

Even more interesting is the willingness to pay money for such a service. These biometric systems are offered as cloud services and are correspondingly expensive. 70% of the respondents would not spend money on a biometrics service. 25% of the respondents would be willing to spend an amount that would not cover the costs. Only 5% would possibly be willing to afford such a service.

Conclusion for Biometrics

Biometrics in the enterprise, centrally managed for its own infrastructure, seems to be a niche market. Many end users like to unlock smartphone with a finger or face. In this survey, nearly 2/3 of the respondents said they use biometrics on laptops or smartphones. But apparently it behaves differently with Single Sign-On or VPN.

Or is it simply the group of respondents? The people who participated in this survey are most likely the administrators and IT guys. We didn’t ask directly about the reasons, but you can guess from some of the answers. Sometimes it has been suggested that biometrics is considered too insecure. Definitely, the way biometrics is offered in the enterprise context, is seen by respondents as too expensive.

While we actually have a use case for biometrics, there might not be a market.

You could then use the Yubikey with the x509 certificate to login to you desktop, sign or decrypt emails. These application examples are not topic of this blog post and might be covered in later posts.

You will need a Yubikey 5 and a privacyIDEA installation with version 3.5. We also assume in this example, that you are running Linux on your desktop.

Setup CA in privacyIDEA

First we have to setup a certificate authority (CA), that will sign the certificate signing request (CSR) generated by the Yubikey. privacyIDEA currently only supports local openssl based CAs. This could however be a sub CA to your existing enterprise CA. In this example, we create a new root CA.

Note: You need read access to pi.cfg and write access to /etc/privacyidea/ca

# pi-manage ca create -t local myLocalCA

This pi-manage command will create the CA files and also the CA configuration within privacyIDEA. You are asked a couple of questions and answer them accordingly:

# pi-manage  ca create -t local  myLocalCA

             _                    _______  _______
   ___  ____(_)  _____ _______ __/  _/ _ \/ __/ _ |
  / _ \/ __/ / |/ / _ `/ __/ // // // // / _// __ |
 / .__/_/ /_/|___/\_,_/\__/\_, /___/____/___/_/ |_|
/_/                       /___/

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

        Directory  : /etc/privacyidea/ca
        CA DN      : /CN=myLocalCA
        CA Keysize : 4096
        CA Validity: 1800

        Validity of issued certificates: 365

        CRL validity: 30
        CRL overlap : 5

Is this configuration correct? [y/n] y

You also need to fix the access to the directory

chown privacyidea -R /etc/privacyidea/ca

and create a file /etc/privacyidea/ca/templates.yaml with the contents:

user:
    extenstions: "user"
    days: 365

which will ensure, that the certificate will created as a user certificate with a validity period of 365 days.

You need to do some minor fixtues:

cd /etc/privacyidea/ca
openssl rand -writerand .rnd 
touch index.txt.attr 
chown privacyidea .rnd index.txt.attr

For simplicity comment out two lines (crlDistributionPoints and authorityInformationAccess) in the section “user” in the file /etc/privacyidea/ca/openssl.cnf

[ user ]
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
basicConstraints = CA:FALSE
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
#crlDistributionPoints = @crl_dp_policy
#authorityInfoAccess = caIssuers;URI:http://www.example.com/yourCA.crt

As a last step, go to the Web UI in Config->CA and add the “Certificate template file” /etc/privacyidea/ca/templates.yaml.

Now your CA is ready to go.

Setup PIV trusted certificates

The attestation certificate verifies that the private key was generated on the Yubikey. You can tell privacyIDEA, which attestation certificates should be trusted. Here we will use the Yubikey, so we need to fetch the Yubico PIV CA from their web site.

mkdir /etc/privacyidea/attestation    
wget https://developers.yubico.com/PIV/Introduction/piv-attestation-ca.pem \
     -O /etc/privacyidea/attestation/yubico.pem

The PIV Root CA has signed the attestation CA, that is contained on each Yubikey. We need to retrieve this from the Yubikey. Do do so insert a Yubikey and run the following command:

yubico-piv-tool --action=read-certificate \ 
      --slot=f9 >> /etc/privacyidea/attestation/yubico.pem

The certificate we read from the Yubikey from slot f9 is the attestation CA, that was signed by the Yubico CA. The attestation CA will sign the attestation certificate, that testifies, that the CSR was created on the yubikey. The file yubico.pem now contains the certificate chain of the PIV Root CA and the Attestation CA.

Note: With new production charges Yubico might put a new attestation CA on the yubikeys. So if you buy 100 yubikeys, they will most probably have the same attestation CA, but if you buy another 100 yubikeys several month later, they might have another attestation CA, so you need to repeat this step and put the new certificate chain in a second file.

Configure privacyIDEA policies

privacyIDEA can already enroll x509 certificates. But to ensure, that it will only enroll certificates from CSRs, that are created on the Yubikey, we need to define a new policy, which is available starting with privacyIDEA 3.5.

We create a policy to require an attestation certificate

scope: enrollment
action: certificate_require_attestation=require_and_verify

In this example we will have the administrator enroll yubikeys, so we set an admin policy, that specifies, where the trusted CA chains can be found:

scope: admin
action: certificate_trusted_Attestation_CA_path=/etc/privacyidea/attestation/

Enroll certificate

Now the admin needs to pass the CSR and in addition an attestation certificate, if he wants to have the CSR signed and receive a certificate. The admin could do this manually with the yubico own tools and using the privacyIDEA REST API.

However, in this example we use the privacyidea admin client, which can be found at github.

Note: You can run the command line client on any other computer, it does not need to be your privacyIDEA server.

In this case we are running it on an Ubuntu Linux desktop.

Prepare dependencies:

sudo apt-add-repository ppa:yubico/stable
sudo apt update
sudo apt install yubikey-manager
sudo apt install ykcs11

Create a virtualenv:

virtualenv -p /usr/bin/python3 piv-test

Enter the environment:

source piv-test/bin/activate

Install the privacyidea admin client:

git clone https://github.com/privacyidea/privacyideaadm
cd privacyideaadm
pip install .

Now you can use the current development branch of the admin client in your virtualenv.

Note: You need to have enough hardware access rights, otherwise you might get errors like ” Failed to transmit with protocol T1. Reader is unavailable”

If necessary, you can reset the PIV data on your yubikey:

ykman piv reset

Now you can enroll the yubikey certificate:

privacyidea-enroll-yubikey-piv init-cert -s cornelius -u cornelius \
     -U https://localhost -a super -p test -c myLocalCA -n -P 123456

This will create a CSR on the Yubikey, with the subject “CN=cornelius” and access the Yubikey with the PIN “123456”. The CSR and the attestation certificate will be sent to privacyIDEA at “https://localhost”, the admin will authenticate as user “super” with the password “test” and enroll the certificate to the user “cornelius”. privacyIDEA will verify the attestation certificate, sign the CSR and the certificate will be imported to the Yubikey.

Note: If you have problems enrolling and try to reenroll, you might need to delete temporary files _*.

You can now use the Yubikey with the certificate on it to sign emails or login to your Desktop. As mentioned, this can be a topic for future blog posts.

Conclusion

We showed here how an administrator can enroll a Yubikey with an x509 certificate to a user. At the same time privacyIDEA ensures, that the private key is really generated on the Yubikey. This is an important aspect, when using smartcards for authentication. This ensures, that the private key is unique and can not be copied, neither during the enrollment process nor lateron, making the smartcard a unique authentication factor.

The same way, a user could issue a CSR that was generated on a smartcard to privacyIDEA, making the enrollment process more robust.

This is an important fist step for privacyIDEA to deal with smartcards. We will continue working on smartcard functionalities, smoothening the workflow and enhancing policies.

In an enterprise environment managing x509 certificates and smartcards on a central location is crucial. The Yubikey could contain several certificates. It can contain Webauthn profiles or HOTP slots. If a Yubikey is lost, the service desk should be able to revoke the one hardware key and the central management should know, which certificates and which HOTP slots are affected. With privacyIDEA we are working on this, to ease the life of administrators and service desk users.

Today we put privacyIDEA 3.5 under your Christmas tree. Unwrap it and you will find a lot of enhancements. One of the most important features is that version 3.5 does the first step to also support smartcard management. For high security environments we drastically imrpoved the workflow of Four-Eyes-Tokens.

Let’s do this togeather – Four-Eyes-Tokens

Using the Four-Eyes-Tokens the administrator can define how many users from several different groups should come togeather when the account – the holder of the Four-Eyes-Token – wants to authenticate. This way you can define, that this account worthy of protection can only be used if e.g. two IT administrators and one member of the works council come togeather and use their own 2nd factors to authenticate.

The Four-Eyes-Token has been around for a while in privacyIDEA. But now we are using the Multi–Challenge, that was introduced in privacyIDEA 3.4, to heavily improve the workflow and authentication flow. It is totally transparent to our application plugins and the RADIUS protocol, so that it can be used e.g. with Citrix Netscaler.

Do not copy, rather sign! – PIV smartcards with privacyIDEA

Smartcards are interesting devices, that have certain disadvantages in handling but also come with advantages and features, that allow for completely other use cases like offline authentication, decryption or document signing.

privacyIDEA was already capable of enrolling and manageing x509v3 user certificates. As a first step to better support smartcards, privacyIDEA 3.5 now can require that certificate requests are generated on a PIV smartcard. This is done by
using policies to force the presence of an attestation certificate during enrollment. The attestation certificate confirms, that actually the key pair was generated on a smartcard and there is no copy of the private key.

This was successfully done with the Yubikey 5 and a corresponding enrollment tool. We will continue working on imrpoving the privacyIDEAs smartcard capabilities.

Make the admin’s life easier – serveral enhancements

Tokens

The Push token gets a lot of feedback in the community. So we are continuously improving it. User certain conditions a smartphone device can renew its firebase token, that is used to communicate with Google’s firebase push service. The smartphone app can now contact the privacyIDEA server to update this firebase token.

The registration token is a long “registration code”, that can be used to authenticate once during enrollment processes. The admin can now configure a policy to define the length and contents of the registration code.

A Webauthn token should also provide a signature counter, that is used to identify and avoid cloned tokens. However, not all cheap devices implement this. privacyIDEA now also allows to use Webauthn tokens without a signature counter on demand.

Hardware tokens come with a seed file. privacyIDEA can import a lot of different formats, also PSKC which is defined in RFC6030. The import of PSKC files now also verifies the MAC of the token secrets.

The questionnaire token can now ask more than one question during the authentication process.

Event handlers and policies

The policies may now contain additional extened conditions from the tokeninfo attributes. This can be any arbitrary attribute, so that the admin could define policies, that e.g. allow the authentication at certain applications with a hardware token but not with a software token.

The Tokenhandler can choose the SMS Gateway Identifier or the SMTP Identifier when enrolling an SMS or respectively an Email token.

The Tokenhandler can now increase and decrease the fail counter and also set the Maxfail counter.

The Web UI

Several enhancements allow a smoother work experience for administrators and service desk users. The admin can define a policy to hide certain columns in the audit log. This way the service desk users only see this information, which they really need. Also, the audit log contains the start time, the end time and the duration of a request. This way it is easy to filter or search for long running requests to debug authentication problems. In the dashboard the usernames of the users with failed authentications are displayed with a short link to their user details. This helps the service desk to immidiately find failing users and offer quickers support.

The WebUI now supports the PIN change via multi-challenge response.

The conditions for event handlers and actions for policies have been redesigned to make them look the same and easily searchable.

Managing privacyIDEA

In certain setups you might have a testing environment, a staging environment and a production environment. Configuration changes are often first tested in the testing environment and then transferred to the staging and production environment.

The pi-manage script has a new sub command to export and import resolver configuration, that will help in such scenarios.

The full list of features, enhancements and fixes can be found in the Changelog.

Get privacyIDEA

privacyIDEA is an enterprise grade, extremely flexible multi-factor authentication system, that can adapt to your needs and that lets you automate a lot of tasks. Using privacyIDEA will increase your security. Migrating from other mult-factor
systems to privacyIDEA will ease your life. People have done this and dropped many well-known, but old and crusty authentication systems. Take a look at privacyIDEA and join the community.

It is freely available via the Python package index and via community repositories for Ubuntu LTS 16.04, 18.04 and 20.04.

The company NetKnights provides an Enterprise Edition with Service Level Agreements and stable packages for Ubuntu LTS and Red Hat Enterprise Linux/CentOS.

If you want to stay tuned, join the community forum or subscribe the NetKnights’ newsletter.

We are about to release a new version of the privacyIDEA Authenticator. We moved to a new framework “Flutter”. It is supposed to ease the life of the developers and create more stability between the Android and the iOS app.

The new version is supposed to provide better PUSH token functionality. It will also provide the possibility to “poll” the PUSH notification – sounds strange, right? It can be. But this is necessary if for some reason the concatenated push services of Google and Apple do not work out as expected. Then the smartphone will poll the privacyIDEA to check, if there is a challenge available.

privacyIDEA 3.4 is required in the backend for PUSH-poll to work.

A beta version of the new privacyIDEA Authenticator is available now via Testdrive Testflight. If you want to participate, register here.

We are looking forward to your feedback.