TOPICA supports login as employee, with authentication based on username and password. An employee with the specified username and password must exist in the database, in order for the login to succeed.

Employees are created with relations to:

• organizational units

• profiles (consisting of permissions).

These relations take part in determining the user's access rights (e.g. authorization).

"Login as employee" may be turned on/off by the .config file key LogInAsEmployee, which per default has the value true. I.e. "Login as employee" is turned on by default.

Internally in TOPICA there is an object class called "Patient". This is pr. default labelled "Patient" in the user interface. But it is possible to change this label to something else, e.g. "Citizen". That is: everywhere "patient" is mentioned, it may be subsitituted for "citizen".

TOPICA supports login as patient, using only national ID for authentication.

Caution

In release 4.22 and older, the user interface displays a password field, but it is not used! In release 4.23, there is no password input field (but the label remains, suggesting the password field may reappear in the future). Because no password is used, and no other secret information is supplied, "Login as patient" (in the current implementation) has no security whatsoever, and is to be used for testing purposes only. It should never be used in production scenarios!

A patient with the specified national ID must exist in the database, in order for the login to succeed.

Why would you use this unsecure test login method? You may plan to develop one or more login modules (see below) that implement "login as patient" with better security - e.g. system(s) based on two-factor autehtication, certificates, PKI, biometrics, etc. Even if such module has not been developed yet, you could use this standard "login as patient" mechanism to test your configuration (application) in the "login as patient" scenario.

This built-in "login as patient" may be turned on/off by the .config file key LogInAsPatient, which per default has the value false. I.e. "Login as patient" is built into the system, but is per default turned off.

Release 4.23 of the TOPICA framework supports "custom login modules".

See Integration with Login Providers.

The user interface in the standard login form adapts to the number of configured login methods - depending on the version.

Note

In versions 4.23 and newer, both "Log in as employee" and "Login in as patient" may be enabled/disabled, and these releases also support "custom login modules". The user interface to deal with the various login metohds is based on a tabset. If no login methods are configured, the login form displays an error message, and login is not possible. If exactly one login method is configured, only the user interface of the this login mthod is displayed (e.g. no tabset is displayed). If more than one login method is configured, a tabset is displayed. This tabset will contain one tab for each configured login method (built-in or custom). Version 4.22 and earlier do not support "custom login modules". "Log in as employee" cannot be disabled. If "log in as patient" is enabled, the user selects the login method using radio buttons. When selecting "login as patient", the user must enter national id in the field "Username" - the value of the field "Password" is not used.

It is possible to display custom login modules directly - circumventing the standard login form. See Integration with Login Providers.

In cases where the user is known and has already been authenticated (e.g. when integrating with a context manager), a login form is not needed at all. But a session must still be created by using the TOPICA API to login - either as employee or as patient (a "silent" login).

Other Resources