Customization of the login process

Rational

Some implementations may require to have a custom login process like the Two-factor authentication. But actually the process is kinda hard coded in the client which leaves no room for such customization. Of course the login process should be customizable per database instance.

Proposal

We should let the login method request more data than just the password. This will be achieved by raising a specific exception which will describe what data is required to go further in the process. The client will fill a parameter dictionary with all the data requested and pass it to the login method. Once the login method has enough parameters, it will authenticate the user.
The same design will apply to renew an expired session.
As we will have many modules that could implement login methods, we will add a configuration option that will list in preferred order the methods to use. If a method can not authenticate the user, the next one will be used.
We will not change the design of the session as I don’t think it needs modification.

The drawback is that some login method will not be compatible with the basic HTTP authentication. It is quite normal as such method is basic. But developer could still add as default fall-back the current method and maybe with some check on which user is allowed to use this method.

Implementation

https://bugs.tryton.org/issue5521

This feature allow that session information will be stored on the client? When the user press F5, sao will be use the session before created, and dont ask for user login and password?

No. We don’t store session because its live time is very short 10min per default and I don’t think we want to change that.

After attempt to write some code to run a wizard without being logged, I think it is too much complicate. And as it is quite sensible code from the point of view of security, I think it is better to go for a simpler design.
My new proposal is to convert the login method to use a dictionary instead of the current password argument. And the login method will raise a specific exception for any missing parameters. In such case, the client will just request the missing parameter via a pop-up.
I think the design is simpler but still quite flexible. The only disadvantage is that the developer can only request one more parameters at a time.

I think the customization of the login process could be used not only for two-factor authentication but also to ask for other information, such as which company the user wants to be active in.

I can also think of the case where the user would like the employee to be set.

So I think it is a pitty we cannot make it possible to define something a bit more complex than one field per popup.

Would it not be an option to just send a form view from the server instead of managing a whole wizard?

You can define actions to run at login on the users. One of those actions could be a wizard that ask for the specific information. This is easier because at this moment the user is already authenticated and so he has access to every thing (like searching on Many2One etc.).

I tried but it is too much complex to give access to unauthenticated user to the all view/wizard machinery. And this is a very dangerous place here because it could be an attack vector for unauthenticated requests. So I really think KISS must apply more than anywhere else.

Base on the current patch, I wrote a module to authentication users via SMS: Issue 5530: RFC: authentication by SMS module - Tryton issue tracker