Best solution for kiosk login

[r-xyz]

Hi all,

First of all thanks to NIST, Prometheus Computing and all the community for making this great piece of software possible! :)
We configured an instance of NEMO in our facilities, currently testing it before final deployment.

We are using NEMO_allauth for authentication, and works great (currently tested with Google only).
We also have deployed a DIY kiosk solution which works through a specific user. It works fine after logging it through NEMO_allauth, still after a while (probably a few hours) it gives permission error when you try to scan a badge.

I guess it is due to the NEMO_allauth cookie expiration.
I would like to ask, then, what would the recommended setup for kiosk authentication. In particular:

1. Do you suggest adding a different authentication method/backend for the kiosks, which is not affected by token expiration?

2. Would it be ok to run multiple instances of NEMO against the same PostgreSQL database? An alternative to # 1 would be to have a specific instance for the kiosks, using a different authentication method (IP-based?). Similarly, we could also run the publicly exposed instance with ALLOW_CONDITIONAL_URLS = False to reduce attack surface.

Thanks in advance for any suggestion.
R.

[rptmat57]

Hi,
Let me start by answering # 2, it should be ok to run multiple instances of NEMO against the same database (as long as it's a full-fledged database, i.e. not file based like SQLite). At NIST we have 2 instances running against the same Oracle database and have no issues.
Just make sure to only run timed services (cron jobs) on only one of the instances (the non-public one). Also if you set ALLOW_CONDITIONAL_URLS = False on a public instance you can limit installed apps to just a few:

INSTALLED_APPS = [
  'django.contrib.auth',
  'django.contrib.contenttypes',
  'django.contrib.sessions',
  'django.contrib.messages',
  'django.contrib.staticfiles',
  'django.contrib.humanize',
  'mptt',
  'NEMO',
]

Now as for # 1, you should be able to increase SESSION_COOKIE_AGE to keep the Kiosk user connected for longer.

So in theory, you could set up a separate instance of nemo with a really high value for SESSION_COOKIE_AGE (like a few years) and not have to worry about it for quite a while.

[r-xyz]

Dear @rptmat57,
Thanks for your reply.

We tested multiple instances and they seem to work well.
As you suggested, we looked at limiting installed apps on the public instance with ´ALLOW_CONDITIONAL_URLS = False´, but that seems to also disable some interesting features (e.g. safety datasheet page).
We tried to remove the django.contrib.admin instead, but that breaks the start_NEMO_in_Docker.sh script as it is calling django-admin migrate.
Would it be ok to omit the django-admin migrate from the startup sequence of the public/kiosk instance? Such command would still run from the "admin" instance, and in particular on the first run after an upgrade.
Thanks again for your help,
R.

[rptmat57]

We have our public instance running without django.contrib.admin and with ALLOW_CONDITIONAL_URLS = False.
If you set ALLOW_CONDITIONAL_URLS to True then you have to include django.contrib.admin
I will just mention you could in theory mount your own version of urls.py in your public instance and set whichever URLs you want to be conditional or not. Probably not the best option (could break on updates), but if your goal is to only have a handful of URLs available, it could work.

And Yes, the migrate could be omitted (for example by mounting your own start_NEMO_in_Docker.sh in the docker container) and probably should be omitted on all instances but the main one.
You just have to remember to update the main instance first when there is a new version.

Another thing I forgot to mention when running multiple instances on different servers, is that you will need to find a way to save/access media files in a centralized server that can be mounted on both servers (or use S3 or some other cloud storage).
Or at least if you are using any media files uploaded in nemo like tool documents or sds etc.

[r-xyz]

Thanks again for the useful insight!
We managed to configure different instances (removing the migrate command) and it works great.
In the process of doing so, I noticed that the main instance, running the original script, had a delayed shutdown compared to the secondary instances running directly one command. This is a minor annoyance when restarting, but I opened a PR which fixed it for us.
I hope it helps.

PS: The same media folder is currently mounted on all instances, no problems so far. Also new files are usually uploaded by main instance.