Unity 3.6.0 is another major milestone in Unity development. Please note that in this release the authentication architecture – naturally the most fundamental part of Unity platform – was heavily refactored.
New remote authentication experience
The main highlight of the 3.6.0 release is related to change of the remote authentication handling.
So far Unity was loading authentication screen to handle results of every remote authentication. This step was, most of the time, unnecessary: in case of successful authentication a final UI could be instantly loaded or (in case when Unity was using as a proxy IdP) a return redirect could be performed right away. This behavior was not only slowing down the authentication process, but also forcing users to see (for a short while) the Unity authentication screen – what could cause a confusion.
Unity 3.6.0 addresses this issue and the complete processing of the remote authentication result is done before loading of any UI. Authentication screen is only loaded when remote authentication was not successful and user interaction is required (e.g. to show an error or a registration form).
On the way to fix this issue, we addressed couple of other smaller problems related to authentication:
- Authentication failure messages are less intrusive, do not require clicking them, do not steal focus.
- All UIs available prior to authentication, like the authentication UI or registration form UI are now handling browser’s refresh in a more intuitive way, resetting the UI state
- Unity now supports parallel authentications, from different tabs of the browser. So far trying to start subsequent authentication was showing a warning that the previous authentication process is going to be broken.
- “No OAuth context” and “No SAML context” errors won’t show up anymore when using unity as a client for other IdP. Note that we are also working on addressing the same errors which can happen when using Unity as IdP, and the situation was improved here as well, however the ultimate fix will be delivered in further release.
- Cookie which is setting the last used authentication method is now set only after a successful authentication, not at the moment of starting an authentication.
Note that this change required heavy redesign of the whole authentication subsystem.
There were two, rather rare, but reappearing problems with the use of invitations:
- invitations sent to a user using wrong email address – especially frustrating if the invited user already has an account in Unity, but with another email.
- invitations sent to a not existing user who has signed-up before using the invitation. This scenario sounds unlikely but happens often when a prospective user is invited multiple times – for all such invitations except of the first clicked by the user.
We have developed a special kind of invitations, called combo invitations. Combo invitations are linked at the same time to a registration form and to an enquiry form. At the time when user is opening a form from a combo invitation, it is checked whether the invited user is already present in the system and a proper form is shown.
What is more a user, after opening a form with invitation sent to not existing email address, can move the invitation to her/his existing account. This operation requires authentication.
Combo invitations are used by default in UpMan and can be used by any other Unity integrations.
Enhancements of forms
Registration and enquiry forms got couple of enhancements:
- Registration may be finished with an auto-redirect which happens after a configured amount of time, user will also see a manual redirect button with countdown of the automatic redirect.
- It is possible to include dynamic variables in texts shown by the forms (title, information) which are supposed to be used with invitations. The variables are resolved using data set in invitations.
- It is possible to use dynamic groups (as filled by invitation or selected by the user) in form automation setting user’s attributes.
The changes above allow for creating more flexible forms, and reuse of the same form for multiple similar use cases.
OTP with LDAP backend
A new type of authenticator was added, which allows to verify OTP (more precisely TOTP) using secret and other parameters retrieved from LDAP.
Upgrade from 3.5
This upgrade will perform a data migration. It is advised to take a backup. Pre-production deployment testing is also advised due to significant changes especially in the authentication subsystem. There might be need to update your logging configuration file – details are provided in the Unity manual, in the upgrading chapter.