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.

Today I want to give you an idea about the current development in privacyIDEA. You may like privacyIDEA because it is probably the most flexible and extensible multi factor authentication system due to its sophisticated policies and event handler framework.

But I just pushed a small enhancement in regards to the policies, which my ease your life. You are now able to not only define policies based on realms, resolvers and list of users, but you may also use regular expressions for the users in policies. This will be part of privacyIDEA 2.18 which is scheduled for midth of March 2017.

This way you do not need to rely on the user realms and user resolvers. You can also specify, that a certain policy should be bound to all users matching customer_.* or admin_.*.

This can help to ease things, since you do not need to split up a realm into many resolvers.

Tell us, what you like. Join the Google Group, post your issues at Github or subscribe to the Youtube Channel.

The classical concept of privacyIDEA was: You have a user database – a user store – and privacyIDEA just reads this user store. In classical scenarios such as the enterprise environment with the Active Directory user base this is a perfect concept, because users are already existing. Over time I had to learn that this covers only 95% of the real world. So in version 2.4 we added user management – or editable userIdResolvers.

Editable UserIdResolvers

The editable UserIdResolvers that allow the administrator to manage users from within the privacyIDEA Web UI is an important step for the upcoming version 2.10. The editable UserIdResolvers are only implemented for SQL databases at the moment, but the connector for the LDAP databases like Active Directory or OpenLDAP could be easily enhanced accordingly. But at the moment I don’t think, that someone would like to have his Active Directory modified by privacyIDEA.

Anyway – privacyIDEA 2.4 already contained an importand method in the SQL connector, the method to created a new user in the SQL database.

User Self Registration

Thinking of new use cases with privacyIDEA we came up with the idea to provide a privacyIDEA instance to the public. Or a company or a hotel could provide a privacyIDEA instance to guests, where guests could register a guest account. If it is possible to restrict the registration of a new account to let’s say email addresses, we could control which email addresses are allowed to created a new account. This way it could also be used within an huge organization without reading the users from an existing user source but by having the users (identified by the email address) register their own account.

I am sure, at the moment we do not see the whole potential of this new feature.

How does it work

The administrator needs to define a policy, that allows the registration of a user in the defined UserIdResolver. If this policy is defined, an additional link “Register” is displayed in the login page. Then users may enter account information and will receive a registration token (a kind of registration code) to be able to login with these two factors (The password they defined and the registration code, they received via email).

Notification

During the registration process the user receives an email with the registration token. Again – privacyIDEA needs to notify the user via an email. privacyIDEA already sends emails for the Email token type or the SMTP SMS Gateway token. Also, there is the PIN handler, which could send the OTP PIN, if a random token PIN was created during enrollment.

So you see, that there already were several places in privacyIDEA, where it could be necessary to define an Email connection. Sending the notification during the registration process would be the fourth occasion to send an email.

Now is the time to refactor the email notification code in privacyIDEA.

System wide SMTP server configuration

So the privacyIDEA database for privacyIDEA 2.10 will come with a new database table, where the administrator can define as many SMTP servers as he needs to.

In all occasions, when privacyIDEA needs to send an email, the configuration will only refer to the identifier of this SMTP configuration. Usually defining one SMTP configuration will be enough an this single SMTP server will be used for sending the email of an Email token and the registration emails and all other notification information to come.

But privacyIDEA would not be privacyIDEA if it did not let you the freedom and choice to define as many different SMTP connections as you will need.

More to come

With all these building blocks

• editable UserIdResolvers
• simple token implementations
• simple email notification

new ideas can be implemented easily and quickly. You can see this in the really short release cycles of privacyIDEA.

We are anxious to hear of your ideas, which I am certain of, can be easily implemented, too. Please join us on the Google group or drop your idea at privacyIDEA’s Github issues.

Happy new year and happy authenticating!

privacyIDEA service

This can be used for different scenarios.

At the moment privacyIDEA connects to an existing user store with all the users of your company. In 99% of all cases this is the right behaviour, since noone likes to create users anew.

But in certain cases like when running privacyIDEA as a service, you do not know in advance who will be using it. So you need some means to either create users or let a user register himself. The good thing is, that privacyIDEA already lets you manage users, so that basic functionality is already there. But in addition a to-be-user now will be able to create an account on his own.

Enterprise scenario

There might also be certain scenarios in an enterprise environment. If the company wants to separate two factor authentication from the default user base or if the company wants to provide two factor authentication for previously not known guest accounts.

Stay tuned

So now we started on user self registration in privacyIDEA 2.10 which is due on February 11th. You are welcome to add any of your ideas to the github issue or simply keep track by joining the Google Group or following privacyIDEA on Github.

I already wrote about two interesting new features in privacyIDEA 2.4 – the User Management and Admin Realms.

Interesting: User Management may help to ease the scenrios of smaller installations, since you do not need to manage users in one system (like a central LDAP or SQL database) and manage the tokens in another. So in case you have a really simple VPN setup, you can manage users and tokens from within privacyIDEA. If you like to. On the other hand Administrative Realms will help you to handle really large installations. You can define realms, that are ment to be special help desk groups or super user groups, without enumerating each and every administrator. In scenarios where you have your central user repository and token administrators are not allowed to manage users, this helps to keep lean policies and easy user management (where it belongs). You could new help desk users by adding the user to the LDAP group.

A complete change log is available at github.

Another interesting new Feature is API keys. API keys can be used to protect the validation endpoint. This can be used in hosted environment to protect the the validation endpoint againt denial of service attack, when issuing fake authentication request and thus running into the maximum fail counter. You can define policies to require an API key depending on the users realm or the clients IP address. In connected with the User Management this improves privacyIDEA signigicantly for hosted environments.

privacyIDEA 2.4 lets you load your token data from PSKC Seed Files. The Portable Symmetric Key Container (PSKC) is defined in RFC6030 and defined by the OpenAuthentication Initiative to be used for seed deployment. So if you choose to use preseeded hardware tokens, you can ask the vendor to deliver the secret keys in a PSKC file. Anyway – I would recommend to use seedable tokens, whenever possible.

We improved the Logging and added the possibilty to define a logging configuration file. E.g. this way you can define errors that will be logged to email addresses. So the administrator or the monitoring system will get a notification on critical events.

In privacyIDEA 2.3 the registration token was introduced. This token could be used to ease enrollment processes when doing mass enrollment to widespread users. In privacyIDEA the registration token can also be enrolled from the WebUI.

Some more minor improvements were added to the WebUI like that only a limited list of tokentypes will be shown during token enrollment. The token seed can be displayed after enrolling a token. The WebUI now provides a login_mode policy, so that you can disable the login for users from certain realms.

privacyIDEA can be installed and downloaded in the usually ways. Users running privacyIDEA on Ubuntu 14.04 can update easily. See the documentation for install scenarios.