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

However with iOS devices things are a bit more complicated and additional steps have to be taken. These additional steps are described in this blog post.

Apple push apps – different than Android

The Firebase service can not directly push to apple devices. Instead, the Firebase service pushes to the Apple Notification Service. While Android allows an app to be connected to different Firebase projects, an iOS app with it’s app identifier can only be connected to one Apple Push project.

What does this mean?

For the Android devices you created a Firebase project. Your own Firebase project. You configure the data in the privacyIDEA server and the information about the Firebase project is passed to the privacyIDEA Authenticator for Android during the rollout process. This means that a privacyIDEA installation running with organization A connects the push tokens to their own Firebase project and organization B will connect their push tokens to a totally different own Firebase project.

Unfortunately this is not possible with the Apple Notification Service. NetKnights, the company behind privacyIDEA, created one Apple Notification Service project. The secret push key of this project is connected to the app identifier “privacyidea.authenticator” of the privacyIDEA Authenticator App for iOS. The privacyIDEA installation in organization A sends the push notification for an iOS device to the organization’s own Firebase project, but then the Firebase project will forward the notification to the general Apple Notification Service project. This second step will be the same for all Push notifications to iOS devices connected to any privacyIDEA installation on this planet. This probably arises from Apples cloud-centric idea, that probably an app will only receive notifications from one central cloud service.

However, during enrollment of the iOS privacyIDEA Authenticator the app sends a random device identifier to your privacyIDEA server. Your privacyIDEA installation then uses this random identifier to send the push notification to this very device. It seems unlikely for another privacyIDEA installation to guess the device identifier of a foreign Apple device. If an attacker was able to guess a random device identifier the attacker could send arbitrary notifications to the iOS device. But in addition the iOS privacyIDEA Authenticator is also registered to your own Firebase project. This means, that the attacker indeed could send an arbitrary notification but such notification would not be processed by the privacyIDEA Authenticator.

If you do not like this (which we would understand) you need to recompile the privacyIDEA Authenticator for iOS with your own Apple Notification Service project, with your own Apple developer account, your own certificate and push notification key and with your own app identifier. Just like all other privacyIDEA code, the privacyidea-authenticator-ios is available on github.

NetKnights hopes to be able to provide customization services one day to create customer specific apps as part of a privacyIDEA Authenticator Enterprise Edition, to circumvent this problem.

After this lengthy disclaimer lets now connect Firebase with the Apple Notification Service especially with the privacyIDEA Authenticator.

Note: This howto discloses the secret project key, which is needed so that Firebase can send messages to the Apple Notification Service. This means, that an attacker could – after successfully guessing a device identifier – potentially spam messages to devices connected to the privacyIDEA Apple Notification Service. However, the impact on login security is none, since all messages are digitally signed in both directions. Again: This downside is due to the cloud-centric design or the Apple Notification Service and can only be avoided by compiling your own Authenticator app and publishing it to the Apple app store.

But let’s do the iOS device, now!

Add new Firebase App

In the Firebase console, you need to create a new App in your Firebase project. Do so so click the button “+ Add app”.

The new app you want to create, is an iOS app. So click the round button “iOS”.

In the app registration dialog you need to create an iOS bundle ID. Creating a nickname is optional. For the bundle ID you need to enter “privacyidea.authenticator”. Choose a nickname to your likings.

In the second step of the app registration you need to download the plist file. Save it for later, you need to enter the settings from within this file in your privacyIDEA policy.

In the third step you do not need to take any actions. You do not bother with the SDK, since the privacyIDEA Authenticator iOS app already exists!

Also in the next step you do not need to take any action. Simply press “Next”.

Now you are done registering your iOS app and you can “Continue to console”.

Adding the secret iOS Authentication key

After you have told the Firebase service, that also iOS devices are going to connect to it, you now need to tell Firebase, how it can talk to the Apple Notification Service. For this you need the secret key we talked about at the beginning of this article. If you do not want to compile your own app and publish it in the app store, you unfortunately have to share the “secret” key with all other default installations of privacyIDEA. Download the secret key file to your computer and save it for later.

Still in the Firebase console, first go to the “Project settings” in the upper left corner

In the “Settings” go to the tab “Cloud Messaging”.

In “Cloud Messaging” you will find the “iOS app configuration”. There you can hit “Upload” to upload the secret key file.

Now select the secret key file (AuthKey_2FZRBAT74S.p8) to upload it to the Firebase console.

Enter the Key ID (2FZRBAT74S) and Team ID (627QALYL3B) exactly as stated in the image below.

After hitting the “Upload” button you should be fine and your Firebase Push Service is connected to the Apple Notification Service for the privacyIDEA Authenticator iOS App.

Configure iOS Authenticator in privacyIDEA

Now open the plist file you saved earlier. Find the entries API_KEY and GOOGLE_APP_ID. It will look like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        ...
	<key>API_KEY</key>
	<string>example-key_value</string>
        ...
    	<key>GOOGLE_APP_ID</key>
	<string>1:example:ios:appid</string>
</dict>
</plist>

You need to enter the value “example-key_value” in apikeyios and the value “1:example:ios:appid” in appidios.

Now you are ready to register iOS devices with your privacyIDEA Push setup and use your iPhones to authenticate via Push notification.

If you want to stay tuned for the enterprise edition, please consider contacting the company NetKnights.

We are pleased to announce the release of privacyIDEA 3.0.1 today. In this release, we did not implement any new features, but instead focused on stability.

Our last major release privacyIDEA 3.0 came with several big changes. Most notably, it introduced a new PUSH token class. With this token class, a login request sends a push notification on the user’s smartphone that can be accepted or declined. You can read more about the PUSH token here. Thanks to a lot of feedback from the community, we were able to fix several issues with our initial implementation:

• Add logic checking to setup of PUSH token (#1592)
• Remove double enrollment notification of PUSH token in WebUI (#1598)
• Fix to allow spaces in Firebase configuration (#1599)
• Add support for iOS Firebase configuration (#1608)
• Fix to allow PUSH token enrollment, even with Label-policy (#1589)
• Fix to mark PUSH token challenge answered in the database (#1584)

privacyIDEA 3.0.1 also comes with usability improvements on the frontend side:

• Beautify the vertical alignment in the Web UI top menu (#1559)
• Fix user cache configuration read – defaults to 0 (#1596)
• Remove links in audit log for normal users (#1497)
• Fix placeholder in realm dropdown in login dialog (#1498)
• Allow the usage if “browserLanguage” in custom templates (#1620)
• Open all accordions when searching for policy action (#1558)
• Fix to hide support links also in menu (#1626)

Finally, we corrected some inconsistencies and bugs in the backend, and improved on the compatibility with Python 3:

• Fix the validity period of the registration token (#1587)
• Check UI rights for user resolvers (#1496)
• Fix enckey creation in Python 3 (#1594)

privacyIDEA 3.0.1 is available via the Python package index, and can be installed on Ubuntu 16.04 and 18.04 using our community repositories. Detailed installation instructions can be found in our documentation. Before upgrading your existing installation, be sure to read our update notes.

If you have any questions or suggestions, you are welcome to join our community forum. In case you require enterprise support, we refer to the privacyIDEA Enterprise Edition offered by NetKnights GmbH.

In Version 2.0 the privacyIDEA Authenticator implementes the Push Token. During Rollout the Push Token exchanges asymmetric keys between the privacyIDEA Server and the privacyIDEA Authenticator.

During authentication the privacyIDEA Server sends a cryptographic challenge via Firebase to the smartphone. The privacyIDEA Authenticator verifies the signature of the privacyIDEA Server and asks the user to confirm the login request. The App then signs the challenge and sends it back to the privacyIDEA Server.

The internals are described at our github wiki page.

Join the Beta Test

The privacyIDEA Authenticator 2.0 is available for Android phones at the moment. iOS will follow shortly.

We are happy if you want to participate in the public beta test. Simply go to this site and follow the steps to join the beta test. You can install the privacyIDEA Authenticator 2.0 on your Android device (Minimum version “kitkat” – we do not recommend this!

Set up for your tests

In this blog post we want to give you an overview to get started. For a deeper understanding you can read more about the push token in the online documentation and at github.

Get components

Get privacyIDEA 3.0 and the privacyIDEA Authenticator 2.0.

Network connectivity

Assure, that your smartphone can reach your privacyIDEA server, e.g. by placing your smartphone in the same Wireless LAN like your privacyIDEA Server. The smartphone needs to connect to privacyIDEA during enrollment and during authentication.

Firebase project

In the Firebase console you need to create your own Firebase Cloud Messaging project.

From the console you can download the relevant project information.

The relevant information is the “Web API Key”, “App ID”, “Project ID” and the project number, which is the number part of the “Public-facing name”. Copy these values to create a new provider in privacyIDEA.

Download the file google-services.json and fetch the values “project_number”, “project_id”, “mobilesdk_app_id” and “api_key” from this file.

In addition you need to create a new service account for your Firebase project:

You can download the settings of this service account in a JSON file, which you need to copy to the privacyIDEA machine and later add in your privacyIDEA SMS Provider in the next step.

Firebase SMS Provider

In privacyIDEA you need to create an “SMS Gateway” of type “Firebase” with the Firebase project you created in the previous step. The privacyIDEA Server will connect to Firebase with this project.

Enter the data and json file, you downloaded from the Firebase console. E.g. the JSON config file needs to be copied to the privacyIDEA Server and you need to specify a local path on the privacyIDEA Server.

Finally you also need to enter the registration URL. This is the URL of the privacyIDEA Server which the privacyIDEA Authenticator contacts during the enrollment process. So you need to be sure, that this URL is in a format (FQDN, IP), which the smartphone can connect to. Unless you know otherwise the path or the URL should be /ttype/push.

Policies

Now you need to configure your privacyIDEA system. You need to create two policies, one for the enrollment and the other one for the authentication.

The enrollment policy contains the name of the Firebase SMS Provider you created in the previous step.

The authentication policy can contain the text, that should be displayed in the notification:

Testing

You can now test you setup by

1. Enroll a new Push token and assign it to a user. Give the Push token a PIN.
2. In your browser you can simply issue an authentication request using the API https://your.privacyidea.server/validate/check?user=testuser&pass=yourpin
3. You should receive a notification on your enrolled smartphone, which you can confirm.

Your help and feedback

The missing link currently is the Application that is supposed to poll for the confirmed authentication.

We need your feedback, to know on which application we should start working first. As an alternative we are also planning to add a delayed response.

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.