Server requirements

[yrammos]

Dear Nicolas (@babelouest),

First off, congratulations on an awe-inspiring piece of work.

I'm just emerging from three days of graceless mucking around with FusionAuth, Keycloak, Gluu and other such behemoths, all of which deplete my server's resources and lack this or that vital feature.

Feature-wise, Glewlwyd seems to fit my bill perfectly. I'm interested in integrating my Moodle, NextCloud, and a couple of other forthcoming self-made apps.

Would be grateful for answers to a handful of questions:

1. Is glewlwyd significantly more lightweight than the aforementioned behemoths? Do you have a sense of its memory footprint?
2. To your knowledge has it been tested in contexts with tens or hundred of users?
3. In addition to the webapp UI, is it possible to internationalize the emails, as well?

Many thanks!

[babelouest]

Hello @yrammos ,

Thanks for the support! Let's try to help you with your questions:

1. I don't know what significantly means, I don't use other SSO servers and I only know them by reputation and a little bit of what they offer. All I can say is that Glewlwyd backend is programmed in C especially to run in tiny environments. My minimum requirement is a Raspberry PI Zero. The program should run fast enough on this kind of machine. Although in a rpi zero, I don't expect more than one user. The memory footprint is around 15MB in my production server in idle mode. To provide some answers for you, I've ran some stress tests in a dev environment and the memory footprint doesn't go very higher, barely 20MB.

2. I tried to provide some measurements to help you. On one side, I have my Ubuntu Focal running Glewlwyd in debug mode, using a sqlite3 database, and setup with a OIDC plugin providing RSA256 signatures. On the other side, I run apache ab with the following command:

$ ab -n 300 -c 30 -C "GLEWLWYD2_SESSION_ID=<cookie_value>" "http://host:4593/api/oidc/auth?client_id=client&redirect_uri=https://example.com&scope=openid&response_type=id_token+token+code&nonce=abcd&g_continue"

This command asks Glewlwyd to provide a code, an access token and an id_token in the redirection with a valid user who has a valid session. Glewlwyd answers with a code, an id_token and an access_token in its response. => The request is quite needy in terms of resources...

This command is executed 300 times with a maximum of 30 concurrent clients.

Here is the output of the command

host:~ $ ab -n 300 -c 30 -C "GLEWLWYD2_SESSION_ID=<cookie>" "http://host:4593/api/oidc/auth?client_id=client&redirect_uri=https://example.com&scope=openid&response_type=id_token+token+code&nonce=abcd&g_continue"
This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking host (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Finished 300 requests

Server Software:        
Server Hostname:        host
Server Port:            4593

Document Path:          /api/oidc/auth?client_id=client&redirect_uri=https://example.com&scope=openid&response_type=id_token+token+code&nonce=abcd&g_continue
Document Length:        0 bytes

Concurrency Level:      30
Time taken for tests:   22.599 seconds
Complete requests:      300
Failed requests:        0
Non-2xx responses:      300
Total transferred:      736200 bytes
HTML transferred:       0 bytes
Requests per second:    13.27 [#/sec] (mean)
Time per request:       2259.903 [ms] (mean)
Time per request:       75.330 [ms] (mean, across all concurrent requests)
Transfer rate:          31.81 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2    4   2.6      3      27
Processing:   238 2197 872.3   1940    4933
Waiting:      232 2196 872.4   1939    4932
Total:        260 2201 872.3   1943    4937

Percentage of the requests served within a certain time (ms)
  50%   1943
  66%   2175
  75%   2355
  80%   2515
  90%   3522
  95%   4458
  98%   4832
  99%   4907
 100%   4937 (longest request)

I don't know if someone uses Glewlwyd with a medium or large user database. I helped someone to configure Glewlwyd 1.x for something like 1000 ldap users, I remember someone was trying to run Glewlwyd 1.x in an environment with ~300 users. I never knew in those cases if it was successful.

For what I've seen, the performance bottleneck is usually the database.

3. It is possible, just not implemented yet. The user must have a property telling its language, then the part where the e-mail is generated must use the template corresponding to the specified language (or the fallback if not provided) If you need it I can implement this for the email scheme and the registration plugin, this can be available in next release 2.3 which will be available soon-ish

[yrammos]

@babelouest thank you for this excellent reply and the expert benchmarking. Writing backends in C is a sadly waning art; once again, congratulations on this beautiful piece of engineering.

Your offer to implement i18n support in emails is very kind. I'm reluctant to ask, however, until I'm confident that I'll deploy the software. The question is not only technical—I'd need to add several new language translations, for instance, and I'm working under a strict (if self-imposed) deadline. Also, my understanding is that glewlwyd doesn't (yet?) provide support webhooks/events, and this could erect obstacles in the long run.

Back to the drawing board for a while… Thanks again, will write back if/as needed.

[babelouest]

Hello @yrammos ,

As I said, i18n support for the e-mails (i.e. e-mail scheme and registration) can be added right after I finish my current task (OAuth 2.0 Mutual-TLS Client Authentication). Although I can't guarantee a delivery date. Since it's kindly asked, I'll add it to my bucket list anyway, other people would need it.

If you add other languages in the front-end, the documentation will help you making them available in your install: https://github.com/babelouest/glewlwyd/blob/master/docs/INSTALL.md#internationalization Don't mind sending a pull request with the new translation though :)

Glewlwyd doesn't provide webhooks, mostly because I don't need them and I don't have that much experience in this area. If you describe the use case where you would use webhooks and how you would use them, that would be appreciated, or (even better!) send a patch, that would be awesome!

[yrammos]

@babelouest use-cases for webhooks include the propagation of data changes to other apps, receiving alerts, and sending context-specific guidance to the user via email. Too stubbornly, perhaps, I'm resisting the addition of an LDAP layer to my setup, and in the absence of such a central identity store of some sort my workflows tend to be event-driven.

Also, one of the features I find useful in at least one of the clunky Java-based "behemoths" is their support for "Lambdas," or event-triggered routines, which "massage" data before serving it via REST or storing it in the database. This is useful for implementing complex mappings, for instance algorithmically massaging "display names" based on registration form data and a random number generator.

[babelouest]

@yrammos , do I understand that webhooks must be wide-open as in

• Day1: I'm adding webhook-1 where the external webservice is triggered when 10 new users registered to the application
• Day2: my colleague adds webhook-2 to trigger when a user fails a certificate authentication
• Day15: I update webhook-1 to add the condition that the webservice is triggered when 10 new users that will authenticate via their google account
• Day 42: Another colleague adds webhook-3, similar to webhook-2 except that it target clients

i.e. a programming interface?

If so then I don't know how to make it in order to respect Glewlwyd's philosophy: small, fast and easy to configure. It would require to create something like a meta-language or implement an existing one.

Nevertheless, since Glewlwyd uses the database to store all data and can log lots of information, I think it would be possible to implement webhooks for many events in a separate application.

Concerning the Lambda queries, it's not possible yet as well. A few month ago, I took a look at GraphQL, it could be useful to provide such Lambda queries I think, but I haven't found GraphQL C implementation stable enough at that time.

The problem I see with these new features, is that it would make Glewlwyd closer to the behemoths you mention where it isn't what I intent Glewlwyd to be, and also because I'm programming Glewlwyd on my own, in my free time, and I don't have the time nor resources as the behemoths.

[yrammos]

@babelouest my comments were not meant as feature requests or, alas, suggestions! I wish the behemoths would trade some of their features and Java baggage for a smaller footprint closer to that of glewlwyd. I will be exploring my options and constraints for the next few days and hope to be able to adopt this on my production server some day.

[babelouest]

@yrammos , I don't take it as a demand, it is a feature request but it doesn't mean I'll implement it in a near future.

Except for the emails translation, that I'll do :)

If you'll adopt glewlwyd in your infrastructure I'll be thrilled, but if you don't, I won't take it bad at all, you have your requirements.

[babelouest]

Hello @yrammos ,

I've added multi-lang e-mails in the email scheme and the registration plugin, can you take a look and give me some feedback if you have some time?

You need to build from the source or build your docker image from the source to test the last commit.

[yrammos]

@babelouest I’m thrilled and grateful to hear. Will be able to take a good look after Friday due to an imminent professional deadline this week. All the best meanwhile.

[babelouest]

If you find bugs or wish changes in the multi-lang e-mails feature, please open a new issue, it will be easier to follow and better for other people to understand the context.

Happy hacking!