Beginning with LinOTP 2.9.3 a new type of UserIdResolver has been introduced. The InternalSQLResolver can be useful in setups where LinOTP can not or should not connect to existing external user storages. Instead users are directly managed in LinOTP. The handling is quite simple: a CSV is imported to InternalSQLResolvers. By reeimporting another file existing InternalSQLResolvers can be changed, i.e. users can be added/altered/deleted.
3.3.1. Create InternalSQLResolver¶
A new InternalSQLResolver can be created via the token management web gui https://<LINOTP>/manage: open Tools and select Import Users:
This is the Import User dialog:
A CSV file is required that contains at least the username and the userid of each user:
Data that are not mandatory can be left out:
Please mind - there is only a very limited sanity/syntax check performed by LinOTP. Lines which do not conform to the syntax or which are missing mandatory data are silently ignored. So please make sure the CSV conforms the requirements.
;and must be configured accordingly to the imported CSV.
'and must be configured accordingly to the imported CSV.
The password field contains plain text password and LinOTP will calculate and store the hashes.
The password field already contains password hashes.
Skip first line
Should be ticked if the first line of the CSV does not contain actual user data.
The name of the InternalSQLResolver the CSV should be imported to. It is possible to create a new InternalSQLResolver if required.
After the import the changes can be reviewed and have to be approved before they are actually performed:
Now the InternalSQLResolver can be made a member of existing or new realms the same way as traditional UserIdResolvers (https://LINOTP/manage -> LinOTP Config -> Realms)
3.3.2. Change InternalSQLResolver¶
It is also possible to change an existing InternalSQLResolver via the same dialog.
Please be aware - if an existing InternalSQLResolver is choosen the CSV will be applied. The users stored in the InternalSQLResolver after the import are exactly the same as in the CSV. So users existing in the InternalSQLResolver before which are not in the CSV will be deleted. Users already existing in the InternalSQLResolver and the CSV are changed accordingly to the new data from the CSV. New users are added (which implies existing users which are meant to be kept have to be stored in the CSV as well - otherwise they are lost).
It is strongly recommended to keep old versions of the CSVs in case a rollback is required. Because once the import is approved there is no going back to a previous InternalSQLResolver content without a CSV containing the desired data.
The changes can be reviewed in detail before they are applied to the system: