At the moment we are working on privacyIDEA 2.10. privacyIDEA 2.10 is about user self registration.
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.
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).
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.
Happy new year and happy authenticating!