Therefore, we invite you to attend our free online events

“Central MFA with privacyIDEA” on August 19 or 28 and “privacyIDEA – Your replacement for DUO and OKTA” on September 16.

In these free online events, we will show you how you can use privacyIDEA to design your authentication processes flexibly, securely, and independently.

In addition, Cornelius Kölbel, CEO of NetKnights with more than 15 years of experience in the field of multi-factor authentication, will personally answer your questions.

Take advantage of this opportunity to gain new insights for your authentication project and get answers to your questions!

Dates & Time

19 August, Central MFA with privacyIDEA, 3 pm-3:45 pm Central European Time

28 August, Central MFA with privacyIDEA, 7pm-7:45 pm Central European Time

16 September, privacyIDEA – Your replacement for DUO and OKTA, 7 pm-7:45 pm Central European Time

Secure your free spot and learn more about MFA with privacyIDEA!

Registration via: https://netknights.it/privacyidea-webinar-registration

We look forward to your participation. If you have any further questions about the webinars, do not hesitate to contact us via marketing@netknights.it

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.

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 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.

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.

We learnt this in a lot of set ups and are claiming it since 2018 at the LinuxFest North West. One-solution-fits-all does not work out! Nowadays a company or organization wants to deploy 2FA to not only secure a certain login to a certain application, but also wants to have secure workflows around the authentication process. Thus the perfect 2FA or MFA software needs to adapt to the needs of such company or organisation.

The beauty of the event handlers

privacyIDEA introduced the Event Handlers already in version 2.12, May 2016. The script event handlers, which I want to talk about today, followed in version 2.17, December 2016.

Event Handlers were used quite actively since then. Only the script handles seemed special and awkward. It has been quiet around this one for a while. But recently a comment and question of a German partner (IT-Schmid), who was implementing a roll out concept for a customer, caught my attention and reactivated the thinking about the beauty of the script handlers.

privacyIDEA is implemented in a very modular way – on a horizontal but also on a vertical level. Database level, library level, the REST API and the Web UI are different, separated parts. And this helps us a lot with the script handlers. It is easily possible to write python scripts, that are using the library level, without the need to issue REST Requests that are processed through the web server. This improves performance of such scripts and it gives you access to ready made library functions, that allow you to address tasks with a few lines of code.

Script collection at Github repository

We realized, that it makes sense to provide a collection of example scripts, to give you a better understanding, what scripts can do and how this could be done. A new repository has been added at Github to host such example scripts. The first script is a script is a few lines, that can reassign a token from a username in one realm to a username in another realm. This can be a useful step during more complex rollout scenario. But automating such tasks of course reduces complexity and efforts to be taken.

We are happy to receive ideas and pull requests with new interesting scripts, which could enhance the scenarios with privacyIDEA to unexpected widths.

Visit our community forum for further discussions!

We are happy to announce, that today the first major release of the new privacyIDEA 3 series was pushed to the repositories. It is available via the Python Package Index and on the Ubuntu repositories for Ubuntu 16.04LTS and 18.04LTS.

With privacyIDEA 3.1 the administrator can configure policies that will only be bound to users with certain user attributes. This way the admin can define different policies for users in the same user resolver.

Migration from proprietary 2FA solutions gets even simpler with automatic token assignment and PIN setting.

Even more flexible policies

The administrator can now define policies based on any arbitrary attributes. To do so, privacyIDEA can provide different attribute modules for the policy conditions. This version of privacyIDEA comes with a user-attribute module. Up to the latest version policies could only be assigned to a complete user resolver. This was difficult, when rights of users changed and only some users from a certain user resolver should get new policies in privacyIDEA.

Now the administrator can set an attribute e.g. in the LDAP dirctory of a user, and as soon as this is set the policy will be automatically bound to this user. This provides a bigger flexibility with handling access rights or in migration or enrollment scenarios.

We also added new policy actions for administrators. Administrators now can get a special read right on any configuration setting. This way the super user can define, which administrator is allowed to read certain configuration or which configuration should be hidden from which help desk user. The migration script, which runs automatically in the ubuntu package update will create new migration policies so that the current behaviour of the installation does not change after the update.

We did a lot of work on policies in this release – we called in polishing policies.

Migration of proprietary 2FA solutions

Again we improved the possibility to migrate from existing, proprietary 2FA solutions. Proprietary software goes end of life and sometimes leaves the user with a mess. Cornelius wrote a blog article about that problem.

The administrator can import an existing seed file from the old system. privacyIDEA then basically knows the old tokens. On authentication request privacyIDEA can automatically find out, which token belongs to which user. In addition it will set the old OTP PIN of the tokens. This way neither the user nor the administrator have anything to do to migrate to privacyIDEA.

This is possible since privacyIDEA will at first forward the authentication request to the old system. If authentication is successful privacyIDEA will use the used OTP value to identify the token for the user and it will use the rest of the passed credential to automatically set the OTP PIN.

Many enhancements

Further work was done on the TiQR-Token in privacyIDEA. This is an older concept where a challenge is passed to the user’s smartphone via a QR code, which is displayed during the login process. The user simply accepts the login request on his smartphone.

In addition with privacyIDEA 3.1 there come a lot of minor enhancements and bug fixes.

The complete changelog can be found at Github. privacyIDEA will be at the ownCloud conference in Nuremberg in September. Stop by and get safe!

A whole day with the topic of open source two factor authentication allows us to discuss even more complicated things. We refrained from giving single talk. Because we do not only want to pass information to you, but we also want to get your feedback from you, from the community, how privacyIDEA could develop further.

Please note, that the talks are denoted in German, since the vast majority of the audience is still German speaking. But please do not hesitate to join, if you are English speaking. We are happy to switch to English whereever necessary.

There are some examples of the topics in the project room:

A user story, how privacyIDEA is used at the home network to integrate with FreeIPA, Kolab, OpenVPN and much more.

We discuss, how we can redesign the Web UI to allow for new tasks, workflows and better user experiences.

A workshop, how you can add two factor authentication to your own project using privacyIDEA.

We discuss, how privacyIDEA can become a smartcard management system.

We are looking forward to you joining the day in project room, either for only one slot or for a longer time period. Or simply stop by and say hi!

I will conduct a workshow where we can install privacyIDEA into an existing network, read users from an AD, assign tokens, add two factor authentication to ownCloud, NGinX or SSH. Single Sign On is a great mechanism to ease the life of the users. But protecting this single login is even more important. Protect it with a second factor. We will see how this can be done for Keycloak or simpleSAMLphp.

On the next day I will give a talk how you can migrate to privacyIDEA two factor authentication and how it can help with your workflows in your environment.

Come, see, listen, talk. You may even get some swag!