privacyIDEA 3.3 is out. The new version introduces a new Event Handler Module to enable custom event-driven logging. Also new in 3.3 is the support of WebAuthn tokens which come to privacyIDEA initially as a second-factor for WebUI login.

WebAuthn

Everybody speaks about WebAuthn becoming the global standard for web-based authentication to overcome phishing and man-in-the-middle attack scenarios. Indeed, WebAuthn, as specified by the W3C, is a very flexible JavaScript-based API for user authentication. It is the successor of the U2F standard of the FIDO alliance and is, like its predecessor, phishing-resistant by using public-private key encryption in a TLS-secured challenge-response communication. However, WebAuthn has a far more general scope, as it is designed to work not only with U2F tokens but also with any other hardware which supports the API interface. WebAuthn will greatly extend the set of usable token devices e.g. to hardware crypto-chips which can be unlocked by a fingerprint-scanner. For the end user, this example case will result in a unique authentication experience with the fingerprint as apparent key-device. During the authentication process, the browser acts as relay between the WebAuthn security device (authenticator) and the service (relying party).

WebAuthn comes to privacyIDEA

privacyIDEA initially implements WebAuthn to support WebAuthn/FIDO2 Hardware Token as second factors. You can configure privacyIDEA as your relying party, enroll WebAuthn Tokens with privacyIDEA and use them as a second factor to login to the WebUI. The following gallery shows the enrollment process.

However, this is pretty much it for the moment since WebAuthn requires both service and client to support it properly. As the privacyIDEA server integrates with other services like simpleSAMLphp, Keycloak, Owncloud and others via plugins, those represent the client side. The following steps will therefore be to update the plugins accordingly. With the well-documented WebAuthn API flavored with coding examples, this is a fairly straightforward task (it still requires time). Everyone is invited to speed-up the process by contributing on Github. NetKnights, the company driving the development of privacyIDEA on Github, plans on developing an SDK to help plugin developers to integrate privacyIDEA with their favorite applications.

Log Freely

Already since privacyIDEA version 2.12, the event handler supports user notifications sent by email or SMS, triggered by custom events. privacyIDEA 3.2 introduced the ContainerAudit module to support multiple logging targets which enabled the default SQLAudit and other logging modules to receive logged messages. This might be used to integrate privacyIDEA logging with central logging systems like Logstash ans Splunk.

The new version 3.3 builds on this basis and pushes forward towards a completely customizable logging. The new event handler module Logging basically implements a UserNotification which is not sent via external service but to the Python logging facility instead. As all Event Handlers in privacyIDEA, it can be bound to any event with all the usual possibilities to configure further constraints. The custom log messages support the variables known from the UserNotification handler to provide the administrator with maximum flexibility. The privacyIDEA advanced logging is configured via a configuration file. Starting with version 3.3, privacyIDEA supports both YAML and INI format for the logging configuration file. This new event handler offers great flexibility since not only what is logged can be configured to your needs but also where to. The logging name can be customized, which enables an easy separation of different types of information.

Tell me your index: the Indexed Secret Token

privacyIDEA comes with a new token type, called Indexed Secret. This challenge response token was requested to realize a second factor using already known shared secrets between an organization and its employees. The secret is stored in privacyIDEA for every user and during login a challenge is presented, asking the user e.g. for the 1st and 4th character in his secret. For the secret “Secret”, the user would have to answer by typing “Sr”.

The secret may also be preset with user attributes from the userstore. However, note that using the phone numbers of your employees represent a weak second factor attribute. The potential of this token is to support complex rollout scenarios to provide every user with a unique second factor, right from the start.

Administer Transparently

Previously the admin user for whom an admin policy should be in place could be specified in privacyIDEA. This could be for example a policy to allow enabling and disabling of tokens but not the deletion. The new version adds the possibility to add specific users that are to be managed by this policy. This helps a lot in the delegation of user management and segmentation of your administrative tasks.

There are now separate fields for the admin user and the user himself in the admin policy creation dialog.

The complete changelog can be found at Github.

Start your independence now

privacyIDEA is the flexible open-source multi-factor-authentication solution which runs on-premises. It is hosted on Github and can be run and extended by anyone free-of-charge. But it also comes without any warranty. NetKnights provides professional support for enterprise customers in three different levels. Open-source means for privacyIDEA, that you will always be able to run it, without the fear of an end-of-life scenario. You can also participate in the development, reporting bugs, suggesting features or create pull requests to have your own code included on Github. You can discuss about privacyIDEA and share your use case in the privacyIDEA community.

privacyIDEA 3.3 can be installed from the Github sources, from the Python Package index at pypi.org or with the community packages for Ubuntu 16.04 LTS and 18.04 LTS. NetKnights will also offer packages for CentOS/RHEL in the privacyIDEA Enterprise Edition.

At the same time privacyIDEA provides several different ways to migrate existing 2FA system to privacyIDEA. This is important, since proprietary systems tend to go end of life.

privacyIDEA Talk at SCALE 18x

Cornelius will be giving a talk at SCALE 18x about where 2FA or MFA is going and what we might expect from the old key players.

privacyIDEA can easily help you to get rid of old vendor locks once and for all. privacyIDEA aims to be future proof. Not only do we support Python 3! but we also keep up with new developments in the authentication market. privacyIDEA provides a lot of different authentication types like U2F (FIDO2), HOTP/TOTP, SMS or PUSH notifications. This talk will give an insight of the pros and cons, which you need to know to find the right auth type for your scenario.

If you are around, stop by at the Southern California Linux Expo at the Convention Center in Pasadena on March 5th-8th, 2020.

Read more

Update: The talk will be held on March 8th in the Security track, 3pm – 4pm.

Today we released the ownCloud App version 2.5.1. This plugin connects ownCloud to privacyIDEA adding enterprise 2FA to your ownCloud.

privacyIDEA supports a lot of different token types to provide 2FA for the user. This can be keyfob tokens or Smartphone Apps but also authentication mechanisms that work with a challenge/response workflow like Email, SMS or U2F.

The version 2.5.1 of the privacyIDEA ownCloud app improves the challenge/response authentication when logging in to ownCloud. A user can now have several different challenge/response tokens, an Email, an SMS and/or a U2F device. The privacyIDEA ownCloud app will handle this correctly and allow the user to either authenticate with the code from an SMS or with his U2F device.

A complete changelog can be found here at Github.

The privacyIDEA ownCloud app is also available via the ownCloud Marketplace.

Proudly we talk about our release of the major version privacyIDEA 3.0, today.

Changing the version number 2.23.5 to 3.0 indicates a lot of changes. Changes why you should take more care during the update process. And changes, why this article is a bit longer than usual. But relax! We did everything we could to still give you a smooth update experience.

So what is so different?

Get ready for the future

The most important changes in version 3.0 are under the hood.

Now privacyIDEA runs well on Python 2 and Python 3! This way we will still be in business when Python 2.7 is no longer supported in 2020. Being able to run on Python 2 or Python 3 with the same code allows you to choose, whether and when you want to move your installation to Python 3!

The other major change is in the database schema. For years tokens were assigned to a user, by storing the link to the user in the token database table in the columns userid and resolver. From this, the limitation came that a token could originally only be assigned to one user. In version 3 we store the token assignment in a new database table “tokenowner”. This way the database schema allows that a token can have multiple token owners. While currently the API and Web UI still only allow to assign one user to a token, we have laid the foundation for an even greater flexibility in the future.

This change leads to something, we did not have before during update. Data migration! While the past versions contained schema migrations, that added new columns and features to privacyIDEA, this is the first time, that the update process will also change data in the database! The userid and resolver is removed from the token table and migrated to the tokenowner table. We tested this successfully with roughly 25.000 assigned tokens. Migrating more tokens will just be a matter of time.

Push and Queue

Two new main features are the Push Token and internal Queueing.

With the Push Token privacyIDEA will send a push notification to the user’s smartphone informing the user about the login request. Using the privacyIDEA Authenticator App the user can confirm the login request by simply clicking the notification. In the background a cryptographic challenge is signed on the smartphone and sent back to privacyIDEA. privacyIDEA verifies the signature and the login for the user is granted. The Push Token adds another unique authentication mechanism to privacyIDEA. Thus the administrator can choose between a lot of different authentication types like TOTP, HOTP, Yubikey, U2F, Email, SMS… and decide which matches the user’s needs.

privacyIDEA now offers a queue, that can run tasks outside of the request context of e.g. an authentication request. For starters the task of sending an email (e.g. during authentication with an email token or with the notification event handler) can now be pushed to the queue and thus be decoupled from the original request, resulting in reliably quicker response times.

In the future the queue can be used for a lot more tasks.

Tell me what happend – helping the administrator understanding his complex system

In big installations the administrator might have configured a lot of different policies, to tweek the system exactly to his needs. Policies define the way, how the systems responds to an authentication request, the enrollment of a token or any other API request. The combination of the policies can make things more complex and the administrator can loose the overview. “What policy combination caused the system to respond in this way?”

The audit log already saves every API request that was sent to privacyIDEA. In version 3.0 the audit log also contains a list of all used or relevant policies during this request. I.e. the administrator can easily see, why the system behaved this way it did. The audit log will contain the complete list of policies, that led to this very decision. This will help the administrator or service desk to trouble shoot user’s requests in a shorter time.

Get it and authenticate

As always you can find the complete changelog at Github. Please be sure, to read the READ_BEFORE_UPDATE, before updating! (Just like the name suggests)

privacyIDEA 3.0 is available via the Python Package Index and via repositories for Ubuntu 16.04LTS and 18.04LTS. The repositories have been changed to be able to provide more strictly defined installation scenarios. Please read the online documentation for install methods and the update process.

New users are welcome at our community forum! Enterprise users can get an Enterprise Edition here.

You should always take a look at the Changelog, but starting with privacyIDEA we added a document READ_BEFORE_UPDATE, which contains important information to consider before upgrade.

New Features: RADIUS integration, VASCO support, Offline Refill and more

With privacyIDEA 2.22 we added the possibility to pass more useful userinformation to a RADIUS client like a VPN. The administrator can add a policy to include the resolver and the realm of a user who authenticated successfully. This response data can then be used in the FreeRADIUS plugin and modified by regular expressions to add any arbitrary RADIUS attribute in the RADIUS response, which then would be sent to the VPN. This additional information can be used by Cisco ASA, Citrix Netscaler or any other enterprise grade VPN to put the user into certain subnets or to assign resource to the user.

VASCO token support

privacyIDEA is Open Source. We love Open Source and open standards. But sometimes you have to communicate with proprietary partners, so that they have the chance to become open. This is why privacyIDEA 2.22 comes with support for the proprietary VASCO Digipass tokens. This way it is easier to run VASCO tokens and open standards tokens like HOTP, TOTP or Yuibkeys in parallel and maybe even one day migrate all VASCO tokens – after the batteries have died – to other devices.

If you want to learn more about migrating your VASCO tokens, please contact NetKnights for professional sevices.

Offline Refill

We are improving the offline capability of privacyIDEA in conjunction with the PAM module and the privacyIDEA Credential Provider. The new offline refill will allow to automatically refill the hashed OTP values on the notebooks, which are available for authentication, if the notebook is offline. This way users or administrators will not have to worry anymore when taking the hardware on a business trip.

Send SMS via SMPP

SMPP (Short Message Peer-to-Peer) is a protocol used by carriers for sending SMS. privacyIDEA 2.22 comes with a new SMS Provider to send SMS via SMPP. This can be used for sending SMS in the SMS token during authentication but also for sending SMS in the notification event handler, to notify users or administrators on certain events.

Use Counter handler for monitoring and statistics

We often see, that the event handler is a mighty tool to cope with many different requirements. In addition to the notification handler, token handler, script handler and federation handler privacyIDEA 2.22 now comes with a simply but very flexible counter handler. Just like every handler it can be attached to any event (API call) and will trigger under defined conditions. The counter handler simply increses a counter in the database for this very event.

These counters can now be used for statistics or monitoring, e.g. when increasing a certain counter on the event failed authentication with HOTP token. This way the administrator could monitor the number of failed authentications per time interval.

Each token has a tokenkind

Many installations use hardware tokens and software tokens at the same time. To be more flexible in distinguishing these tokens when it comes to deleting tokens or deciding giving access, we added an additional class attribute to tokens. The “tokenkind”. In contrast to the tokentype, which is simply the mathematics of the token, the tokenkind defines if this very token object is  hardware token, a software token or a virtual token.

Use arbitrary tokeninfo in authorization policies

Authorization policies are used to decide if an authenticated user should get access or not. As the arbitrary tokeninfo fields are getting used more in more in event handler definitions, the tokeninfo can now also be used in the authorization policies to grant or deny access.

This way event handlers could modify token information and this modified token information can be used for granting access. Event handling and authorization thus get connected more tightly.

Lots of enhancements

There are further enhancements of existing features in privacyIDEA. We improved the token export the PSKC files – we will also export PW token types and the counter values of HOTP and TOTP tokens. The export can now also be used to reencrypt a token database.

The SMS and Email token types can now either use the fixed mobile number or email address in the token data or read the mobile/email dynamically from the user store on each authentication event.

The administrator can define a policy so that the validity of the U2F attestation certificate will be ignored. Some U2F devices come with a attestation certificate with an invalid validity period.

We improved the speed of the LinOTP migration script, so that a database with tens of thousands of tokens can be easily migrated.

The pi-manage script can now generate API tokens with a freely chosen validity time.

The user can now set the description of HOTP and TOTP tokens during enrollment.

The administrator can add a timeout to the SMTP server configuration.

The email tokens can now use a complex html template for sending emails.

The LDAP resolver allows to define each attribute as a multivalue attribute.

The event handler condition can trigger on failed authentication.

For the complete changelog with also contains all the fixes, please take a look a the Github repository.

Enterprise Edition

If you are running large mission critical setups, privacyIDEA is also available as Enterprise Edition with support and warranty/liability.

privacyIDEA at Grazer Linuxtage and Linuxfest Northwest

At the end of April you can hear a talk about privacyIDEA in Austria at the Grazer Linuxtage. You will learn, how you can easily migrate an old, existing, proprietary 2FA system to privacyIDEA. Project member Friedrich Weber will also host a workshop at the Grazer Linuxtage, where you can participate in installing privacyIDEA and configuring to your needs.

At the same time Cornelius Kölbel will give a talk in Bellingham Technical Colleage, U.S.A. At the LinuxFest NorthWest 2018 you can learn about what makes privacyIDEA so unique in regards to workflow integrations using the privacyIDEA Event Handler system automating a lot of individual tasks.

Join the discussion

Join the discussion a community.privacyidea.org.

The following changes were made in 2.19.1:

Minor enhancements:

• Add “pi-manage policy load” and “pi-manage policy export”. (#721)
• Allow customization via pi.cfg file.
• Add {username} and {realm} as tags for the tokenhandler. (#735)

Fixes

• Fix pi-manage file permission for backup
• Fix search for resolver in audit log
• Allow to read old legacy time from validity period
• Fix wrong enddate with lost_token
• Fix typos
• Improve documentation for yubikey
• Improve documentation for cache decorator
• Improve documentation for webui policy

With privacyIDEA 2.19.1 the company NetKnights also started to provide a privacyIDEA appliance.

You can install and update privacyIDEA from the Ubuntu PPA repositories for Ubuntu 14.04 and 16.04 and from the python package index.

Do not forget to stop by the privacyIDEA Forum.

If you can not attend or if you want to try this at home afterwards, here is what we will do!

Setup

10.0.2.201 ucs.tuebix.intranet (LDAP) Univention Corporate Server 4.2
10.0.2.202 privacyidea.tuebix.intranet, Ubuntu 16.04 LTS
10.0.2.203 wordpress.tuebix.intranet, Ubuntu 16.04 LTS with latest wordpress
10.0.2.204 owncloud.tuebix.intranet, Ubuntu 16.04 LTS with ownCloud 10

LDAP

BaseDN: cn=users,dc=tuebix,dc=intranet

The UCS has the following users:

• admininistrator
• user1
• user2
• user3

ownCloud

ownCloud is connected via LDAP, so the LDAP users can connect to ownCloud.

The ownCloud Administrator is called: admin

WordPress

WordPress only has internal users. Nevertheless the user are also called:

• administrator
• user1
• user2
• user3

What we will do – our Agenda

• We will install privacyIDEA and connect privacyIDEA to the UCS, so that privacyIDEA knows the users from the LDAP directory
• Then we will enroll different kind of tokens to the users.
  • The administrator can enroll a token for the users but
  • users can also login to the webui with their LDAP password an enroll a token for themselves.
• Then we start connecting applications to privacyIDEA to add 2FA to the applications
  • WordPress with “strong authentication” plugin
  • ownCloud with the “privacyIDEA ownCloud App” from the market place
  • SSH login with 2FA for users user1, user2, user3

privacyIDEA

Install

privacyIDEA can be installed in many different ways on different Linux distributions. We will install privacyIDEA on our Ubuntu 16.04 machine 10.0.2.202.

As root:

add-apt-repository ppa:privacyidea/privacyidea

apt update

apt install privacyidea-apache2

privacyidea-apache2 is a meta package which will install MySQL, Apache and set up privacyIDEA. Finally we only need to create the first token administrator.

pi-manage add admin super

Now we have an administrator called “super”

Configure

privacyIDEA can be configured via command line, API or the web UI.

https://10.0.2.202

We need to configure the Resolver tuebix_users as Active Directory. For this we need to fetch the certificate of the UCS server.

• LDAP Resolver to ldaps://ucs.tuebix.intranet
• Base DN cn=users,dc=tuebix,dc=intranet
• Bind DN cn=administrator,cn=users,dc=tuebix,dc=intranet
• Preset AD

And a Realm tuebix with the resolver tuebix_users.

We can also take a look at the policies and configure a policy to use otppin=userstore.

Enroll tokens

Enroll tokens as administrator and as normal user…

• Enroll Smartphone App
• Yubikey
• U2F Token
• Feitian C200 (import File Feitian.csv)

ownCloud with 2FA

For ownCloud X we login as administrator and install the “privacyIDEA ownCloud App” from the Marketplace.

We need to configure the App against privacyIDEA:

• https://privacyidea.tuebix.intranet
• no realm
• no ssl check

Note: The privacyIDEA ownCloud App will authenticate all users with a 2nd factor!

After this, users need to present a 2nd factor against privacyIDEA when they log in.

WordPress with 2FA

Install the “strong authentication” plugin.

We need to configure the Plugin against privacyIDEA:

• https://privacyidea.tuebix.intranet…

Note: Users need to enter both factors in the password field at the same time.

The WordPress plugin authenticates users only against privacyIDEA; while with ownCloud users are authenticated by ownCloud and by privacyIDEA.

SSH with 2FA

On either owncloud machine or wordpress machine we install the privacyIDEA PAM module:

add-apt-repository ppa:privacyidea/privacyidea

apt update

apt install privacyidea-pam

…and configure it accordingly against https://privacyidea.tuebix.intranet.

Note: Users need to match!

privacyIDEA LDAP Proxy

Bonus!

The first question we asked ourselves was: What exactly do we want to find out? As we worked a lot on optimizing the LDAP resolver, we first wanted to know if privacyIDEA 2.19 by itself processes authentication requests faster than privacyIDEA 2.18.1. The next question was whether performance can be further improved by enabling the new user cache feature of privacyIDEA 2.19. Here, we wanted to differentiate between a worst-case scenario with an empty cache and a best-case scenario with an already-populated cache. For each scenario, we wanted to get an idea of the time that privacyIDEA needs to handle an incoming authentication request. Having cleared our objective, the next step was creating a suitable lab environment that resembles the real world as closely as possible to run our benchmarks in.

Our lab environment

We created a lab environment as follows. First, we set up an Univention Corporate Server and added 1000 users to its directory, which we simply called user000 to user999, as well as a privacyIDEA service account. In the same network, we prepared two Ubuntu 16.04 virtual machines and installed privacyIDEA 2.18.1 on the first and privacyIDEA 2.19-dev5 on the second machine. On both instances, we added a realm with a LDAP resolver connecting to the Univention Corporate Server via LDAPS.

In order to keep our environment as close to the real world as possible, we would need to enroll HOTP or TOTP tokens for our 1000 users. However, we ultimately decided against it. For one, we suspected that the time spent calculating and checking the next OTP value on the server is relatively small in comparison to the time spent communicating with the LDAP server. Enrolling real OTP tokens would also require us to keep track of secrets and counter values on our benchmark client, which would complicate our setup a lot. To keep things simple, we instead decided to enroll one simple password (SPASS) token for each user.

Our benchmarking approach

Now, we had set up two privacyIDEA instances with 1000 tokens. The next question was: How exactly do we now measure the performance of one authentication request? We decided to settle on the following approach: One benchmark consists of 2000 successful authentication requests, performed one after another for the users user000 to user999. This means that each user is authenticated twice during one benchmark. For each authentication request, we measured the time from sending the request until receiving the response using a simple benchmarking script in Python based on python-requests. We copied the script to the virtual machines and performed all authentication requests against https://localhost in order to exclude the network delay from our measurements. Running the script then produces 2000 measurements of response time, of which we computed the median response time.

We decided to measure the response times for the following scenarios:

• Scenario #1: Authentication against privacyIDEA 2.18.1
• Scenario #2: Authentication against privacyIDEA 2.19, with the user cache feature disabled
• Scenario #3: Authentication against privacyIDEA 2.19, with the user cache enabled and initially empty
• Scenario #4: Authentication against privacyIDEA 2.19, with an already-populated user cache. This means
  that the user cache contains valid 1000 entries, one for each user from user000 to
  user999.

The scenarios 2, 3 and 4 were carried out on the privacyIDEA 2.19 machine. For scenarios 3 and 4, we enabled the user cache with a timeout of one day (corresponding to 86400 seconds).

Our results

Now, we had everything in place to start our benchmarks! In total, running the benchmark for all four scenarios took roughly one hour and we obtained the following results.

Interesting! According to our measurements, an update to privacyIDEA 2.19 alone seems to reduce the median response time by roughly 57% (Scenario #2), even without enabling the user cache. This speedup can probably be attributed to some performance improvements in the LDAP resolver (see issues 655 and 664).

Furthermore, if the user cache is enabled and fully populated (Scenario #4), the median response time is reduced by another 33%. In comparison to privacyIDEA 2.18.1, this corresponds to a reduction by 71%. Of course, this models a best-case scenario in which the LDAP server does not need to be queried any more at all. This may not be the case in the real world, e.g. if an otppin=userstore policy is enabled.

Scenario #3 is quite interesting, as the user cache is initially empty and is subsequently populated during the first 1000 authentication requests. For the second round of 1000 authentications, privacyIDEA can rely on the user cache instead of querying the LDAP server. We can also observe this if we plot our measurements:

The horizontal axis denotes our measurements and the vertical axis gives the median response time in milliseconds. We can observe that the median response time drops dramatically after the thousandth measurement, from which we can conclude that the user cache does have a measurable positive impact on the performance of authentication requests.

Of course, our benchmark is not perfect and leaves room for improvement due to multiple reasons. Firstly, the measurements also include the round-trip time between LDAP server and privacyIDEA instance, which significantly depends on the network setup. Secondly, we have only enrolled SPASS tokens and no real OTP tokens. Thirdly, we have not performed any concurrent requests and cannot, for example, say anything about the maximum number of authentication requests per second. Finally, two authentication requests by the same user are several minutes apart. If the same user sends two authentication requests during the timespan configured by the cache timeout option of the LDAP resolver (which defaults to 2 minutes), privacyIDEA queries an in-memory cache, which may be even faster than the query to the local database performed by the user cache.

However, we believe that our benchmark shows that privacyIDEA 2.19 improves the performance of authentication requests quite significantly even without the user cache. Additionally, enabling the user cache may bring significant performance improvements in case a large number of users are expected to send authentication requests over a large timespan. Finally, we noticed that the LDAP connection in our test setup is quite fast (a LDAP search takes just unter 30 milliseconds), so the user cache may provide an even better speedup in case of slower LDAP servers or connections. You are welcome to try it out for yourself! If you have any further questions, pleask ask them on our community site.

Need for Speed

privacyIDEA is used in quite some big setups. So in this release we also had the focus on speed! With different actions we were able to reduce the time needed for one authentication request by up to 72%! (According to our lab environment – other numbers may differ)

So how did we manage this?

Many setups run their users in an LDAP directory or Microsoft Active Directory. As privacyIDEA does not store users but only references to user objects in user directories, we need to find the user object, when a user enters a login name. Thus, during authentication some LDAP requests are involved to resolve the login name to this user reference. We manage to optimize our LDAP calls, which resulted in a speed up of 57% in comparison to privacyIDEA 2.18.

The User Cache

But still privacyIDEA has to query the LDAP server. There can be setups, where the connection to the LDAP server is rather slow, since it is located behind a VPN connection. So we added a user cache in privacyIDEA 2.19. The user cache stores the login name and reference to user object in the local SQL database. Thus, once a user is know, there is no need for a further LDAP call.

In our lab environment we measured a further speed up of 33%, if the user cache is used with LDAP users. This effect could be even better, if you are running a slow LDAP connection!

U2F

privacyIDEA comes with two new policies for enrollment and for authentication.

The administrator can define a regular expression to restrict the types of U2F devices, that may be enrolled or used for authentication. This way a company may restrict the usage of U2F devices to one of a specific vendor. Or certain resources may only be accessed with some special U2F devices.

Secure Smartphones Apps

To use the Smartphone as your authentication device is a very common scenario nowadays. Everyone is taking care for his smartphone and is carrying it along. But as stated in the NetKnights blog post, the enrollment process most of the time is not that secure. The Key URI in the QR Code introduced with the Google Authenticator and used by many smartphone apps out there, contains the secret key.

privacyIDEA comes with a new integrated mutual key enrollment which makes implementing smartphone apps with a secure key enrollment much simpler. The privacyIDEA server and the smartphone app both create one component. The actual key is generated from these two components. Thus the secret key can not be easily copied and shared between several smartphones.

Further enhancements

There are many other enhancements. The time format was improved by adding a timezone. Policies and Eventhandler had some improvements like being able to set the Client IP or the User Agent in the tokeninfo fields.

The full Changelog can be found here.

In March we will have a booth at the Chemnitzer Linuxtage (March 11th and 12th). Chemnitzer Linuxtage is the biggest yearly Linux event in Germany with about 3000 visitors.

At the booth we will have a demo installation of privacyIDEA, different token types like Yubikeys, U2F devices, Nitrokeys or OTP-Tokens and Cards to present possible solutions to interested visitors. 

If you also want to get personally involved in the privacyIDEA project and development and act as a stand helper you are welcome to join us at our stand. Please drop me a note via the Google Group. You will get free entrance, catering and saturday night event dinner. At the moment we are three persons at the stand. We are looking forward to your experiences, your questions and you as a real life person.

See you in Chemnitz!

Cornelius