lemonldap-ng issues
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues
2021-01-08T17:21:51Z
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2423
LLNG cli tools are not in PATH after package install
2021-01-08T17:21:51Z
Maxime Besson
LLNG cli tools are not in PATH after package install
lemonldap-ng-cli, lemonldap-ng-sessions, convertConfig, convertSessions, etc, are not in PATH after a package install. This hurts the discoverability of these tools, and makes using them more inconvenient in general.
We should decide on...
lemonldap-ng-cli, lemonldap-ng-sessions, convertConfig, convertSessions, etc, are not in PATH after a package install. This hurts the discoverability of these tools, and makes using them more inconvenient in general.
We should decide on a consistant naming scheme (lemonldap-ng-convert-sessions for example) and install all these commands in /usr/sbin when using RPMs and DEBs
3.0.0
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3008
System to override any parameter using environment variables
2023-09-20T06:31:31Z
Yadd
System to override any parameter using environment variables
The idea here is to be able to override any LLNG parameter using an environment variable, especially when using docker images without manager.
Example:
```yaml
environment:
- LLNG_OVERRIDE_checkXSS = 0
- LLNG_OVERRIDE_ldapExpo...
The idea here is to be able to override any LLNG parameter using an environment variable, especially when using docker images without manager.
Example:
```yaml
environment:
- LLNG_OVERRIDE_checkXSS = 0
- LLNG_OVERRIDE_ldapExportedVars = {"Name":"cn"}
- LLNG_OVERRIDE_exportedVars_uid = cn
```
Then during configuration load, configuration changes to:
```js
{
"checkXSS": 0,
// Whole key changed
"ldapExportedVars": {
"Name": "cn"
},
// Only a subkey changed
"exportedVars": {
// ...
"uid": "cn",
// ...
},
}
```
Maybe useful to store secrets in env variables. Example:
```yaml
environment:
- LLNG_OVERRIDE_oidcRPMetaDataOption_tmail_clientSecret = mysuperpassword
- LLNG_OVERRIDE_key = mysecretkey
- LLNG_OVERRIDE_oidcServicePrivateKeySig = ...
```
Such system is implemented in my docker images.
In discussion
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2748
Fix UTF-8 encoding/decoding
2024-03-06T08:07:42Z
Maxime Besson
Fix UTF-8 encoding/decoding
Creating a global issue for all encoding bugs we intent to fix in 3.0 :
> In order to fully solve this issue, and the one affecting the other backends, I think LLNG should decode() UTF-8 values received by PSGI into proper Unicode stri...
Creating a global issue for all encoding bugs we intent to fix in 3.0 :
> In order to fully solve this issue, and the one affecting the other backends, I think LLNG should decode() UTF-8 values received by PSGI into proper Unicode strings, and encode() them before sending the response, this seems to be how PSGI is supposed to work:
>
> https://metacpan.org/pod/release/MIYAGAWA/PSGI-1.10/PSGI/FAQ.pod#I-want-to-send-Unicode-content-in-the-HTTP-response.-How-can-I-do-so
>
> But there are many places in the code where this will have to be done for it to have a globally positive impact on encoding issues. As long as it's not done everywhere, it will only appear to break things
We need to handle properly encoded (UTF-8 data + UTF-8 perl flag) UTF-8 strings in all LLNG methods, and only convert them to latin-1 when doing the PSGI render. Most modules (LDAP/DBI/JSON..) behave correctly when handed correct UTF-8 strings
This require a lot of refactoring and will break compatibility with saved conf/sessions. A migration step will be required when migrating to 3.0
3.0.0
Maxime Besson
Maxime Besson
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2705
uwsgi breaks special characters display on portal
2023-07-27T09:50:11Z
Albert Rinceau
uwsgi breaks special characters display on portal
Hi,
with llng 2.0.13
recently I moved from llng-fastcgi-server to uWSGI but all special characters were not encoded anymore at display, on portal.
for example, ã gives é with uwsgi, but is well displayed with llng-fastcgi-server.
I...
Hi,
with llng 2.0.13
recently I moved from llng-fastcgi-server to uWSGI but all special characters were not encoded anymore at display, on portal.
for example, ã gives é with uwsgi, but is well displayed with llng-fastcgi-server.
I tried to write it up directly into tpl files instead of translation json file but the final results are the same in both case.
EDIT: As workaround, using HTML entities into translation json file looks working. (like replacing all 'è' by `è`)
3.0.0
Maxime Besson
Maxime Besson
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2285
LLNG should not rely on virtual hosts so much
2023-11-13T13:34:01Z
Maxime Besson
LLNG should not rely on virtual hosts so much
The current model of LLNG is heavily based around "Virtual Hosts" and the notion of having a common domain for portal, manager, 'reload' and apps, but three (at least) different hostnames.
But we have many users who do not use the handl...
The current model of LLNG is heavily based around "Virtual Hosts" and the notion of having a common domain for portal, manager, 'reload' and apps, but three (at least) different hostnames.
But we have many users who do not use the handler at all, and instead only use the SAML/OIDC issuers. For them, having to dedicate an entire subdomain to LemonLDAP makes little sense.
We have users who would like to deploy LLNG components in a sub-path: the manager in /manager, for exemple. Or even, the portal in /portal, why not! And maybe apps in /test1 and /test2?
This would allow us to run an entire "demo instance" under a single URL, without even requiring apache or nginx, just plackup! No more DNS or /etc/hosts issues. Much easier for us devs, too, no more `make start_web_server`.
Good news: because the LLNG router uses `$req->path`, it wouldn't take a huge amount of work to achieve this. (but it will take a lot of testing). Mostly we would just have to write a new handler type that does not depend on the VHost name, but perhaps on a FastCGI environment variable set by the admin within a `location` block. The regexp in this new handler type would only be matched against `$req->path` instead of the entire URL. This handler could solve #2238 too.
Opening this low-priority ticket for discussion, and so I can have a reference to put in commits when I do little improvements towards this long-term goal.
3.0.0
Maxime Besson
Maxime Besson
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3061
lwpOpts and lwpSslOpts parameters not used in REST session module
2024-03-27T10:48:59Z
Clément OUDOT
lwpOpts and lwpSslOpts parameters not used in REST session module
When trying to use lwpOpts and lwpSslOpts for REST session backend, I noticed that these parameters are not used.
If we wen to set them, we need to add them in globalStorageOptions HASH, the values defined in global configuration are al...
When trying to use lwpOpts and lwpSslOpts for REST session backend, I noticed that these parameters are not used.
If we wen to set them, we need to add them in globalStorageOptions HASH, the values defined in global configuration are always ignored
It think this is a bug and that the global parameters should be used.
2.19.0
Clément OUDOT
Clément OUDOT
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3011
Cannot override configuration in lemonldap-ng.ini when value is "0"
2023-09-20T09:03:33Z
Maxime Besson
Cannot override configuration in lemonldap-ng.ini when value is "0"
### Concerned version
Reopening #2711 because it is still not fixed in branch v2.0, issue is the same
Version: 2.17.0
### Summary
* In config, set `portalDisplayRegister=1`
* In lemonldap-ng.ini, set `portalDisplayRegister=0`
* Expect...
### Concerned version
Reopening #2711 because it is still not fixed in branch v2.0, issue is the same
Version: 2.17.0
### Summary
* In config, set `portalDisplayRegister=1`
* In lemonldap-ng.ini, set `portalDisplayRegister=0`
* Expected: Register button is not displayed
* Actual: register button is not displayed
trying to clear the cache or restart llng-fastcgi-server doesn't help
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2999
Better Session API
2024-03-27T09:45:47Z
Maxime Besson
Better Session API
The current session API is not very satisfying:
* We use the same method to create and update a session (getApacheSession) which leads to bugs when $id is unexpectedly `undef`, or when creation works but setting attributes fail
* Error ...
The current session API is not very satisfying:
* We use the same method to create and update a session (getApacheSession) which leads to bugs when $id is unexpectedly `undef`, or when creation works but setting attributes fail
* Error reporting is difficult (we need to test `$session->error`) and incomplete (#2995)
* Locking is not supported in most backends, which may cause bugs on high load
* Implementation is difficult to debug (use of `tie` behind the scenes, etc)
We should work on a new session API with cleaner methods, maybe we could even replace Apache::Session completely since I'm pretty sure noone uses Apache::Session::Browseable except for us, and Browseable backends are the recommended way to deploy LemonLDAP::NG ?
2.20.0
Maxime Besson
Maxime Besson
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2995
No error reporting when session update fails on DBI based modules (probably o...
2024-03-27T09:45:52Z
Maxime Besson
No error reporting when session update fails on DBI based modules (probably on others too)
### Affected version
Version: 2.17
### Summary
* Simulate a SQL error by adding a die() in the update() method of an Apache::Session::Store module
* Try to login
* No error reporting, but a session is created with invalid data (just t...
### Affected version
Version: 2.17
### Summary
* Simulate a SQL error by adding a die() in the update() method of an Apache::Session::Store module
* Try to login
* No error reporting, but a session is created with invalid data (just the session ID)
### Possible fixes
Hard to fix because the update method is called in Apache::Session destructor, so we cannot easily catch when the Store module dies because of a SQL error.
2.20.0
Maxime Besson
Maxime Besson
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2941
Replace userLogger with a more flexible system
2024-03-25T16:13:33Z
Maxime Besson
Replace userLogger with a more flexible system
# Current situation
Currently, events are logged by the userLogger system, with the same semantic as technical logs:
Code:
```
$self->userLogger->notice( 'User '
. $ref->{ $self->conf->{whatToTrace} }
. " succes...
# Current situation
Currently, events are logged by the userLogger system, with the same semantic as technical logs:
Code:
```
$self->userLogger->notice( 'User '
. $ref->{ $self->conf->{whatToTrace} }
. " successfully authenticated at level $ref->{authenticationLevel}"
);
```
Result:
```
[notice] User dwho successfully authenticated at level 2
```
This system has limitations:
* Not enough information (ip address? authentication method? etc)
* Hard to parse for analysis tools (`/User (.+) successfully authenticated at level (\d+)/`)
* Fragile: if the error message changes sysadmins have to reconfigure their logging system
* Difficult to integrate to a third party system (storing events to a db, redis, or sending them to a security tool)
* There is no central list of all possible events
* Do levels even make sense? What is the difference between `userLogger->notice` and `userLogger->error`? They are both events.
# Proposal
I would like to replace userLogger with a more flexible system, for example by passing a hash with contextual data:
Code:
```
$self->auditLog($req,
event_code => "USER_AUTHENTICATED",
level => $ref->{authenticationLevel},
user_id => $ref->{ $self->conf->{whatToTrace});
);
```
What happens then could be completely delegated to a plugin, for example, one plugin could construct a template from the `event_code`:
```
"USER_AUTHENTICATED": "User $user_id successfully authenticated at level $level from IP $req->ipaddr"
```
and render it as:
```
User dwho successfully authenticated at level 2 from IP 127.0.0.1
```
Another plugin could simply log:
```
USER_AUTHENTICATED: user_id=dwho, level=2, ip=127.0.0.1
```
Another plugin could save the data into Redis, etc.
# Roadmap
I am hoping to have this feature sponsored and integrated into the 2.X branch, which means we have to preserve compatibility. In order to do this:
* We need to modify all $self->userLogger calls to use the new system in the existing code base
* The default configuration of the new system must match the old error messages, so that existing log parsing tools are not broken (this can be done by shipping a plugin that maps event codes to the previously logged string)
* For people who use userLogger in third-party plugins, we need to povide a userLogger adapter that plugs into the new system, like this:
```
sub error {
my ($message) = @_;
$self->auditLog( level => "error", message => $message );
}
```
2.19.0
Maxime Besson
Maxime Besson
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2890
Allow syslog to send logs to a remote host
2024-03-28T07:43:58Z
Yadd
Allow syslog to send logs to a remote host
### Summary
In a docker environment, it's annoying to have to instantiate a syslog to send logs to a remote server.
### Design proposition
[Sys::Sylog](https://metacpan.org/pod/Sys::Syslog#setlogsock()) provides a `setlogsock()` funct...
### Summary
In a docker environment, it's annoying to have to instantiate a syslog to send logs to a remote server.
### Design proposition
[Sys::Sylog](https://metacpan.org/pod/Sys::Syslog#setlogsock()) provides a `setlogsock()` function that allow to configure syslog to use a remote syslog (host, port, usd/tcp).
So we just have to add an option to call `setlogsock()` with custom parameters.
2.20.0
Yadd
Yadd
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2470
confTimeout does not work in every case
2022-06-16T14:48:10Z
Maxime Besson
confTimeout does not work in every case
### Concerned version
Version: %2.0.11
Platform: Nginx+Fastcgi
### Summary
* Store your config in DBI
* Restart FastCGI
* Make sure the FastCGI process has an existing DB connection in netstat
* filter network traffic to your DB
* Tr...
### Concerned version
Version: %2.0.11
Platform: Nginx+Fastcgi
### Summary
* Store your config in DBI
* Restart FastCGI
* Make sure the FastCGI process has an existing DB connection in netstat
* filter network traffic to your DB
* Try to access the app
### Logs
```
Feb 19 12:22:47 lemontest LLNG[21390]: [debug] Check configuration for Lemonldap::NG::Handler::PSGI::Main
*stuck*
*Processes receives SIGALRM*
*Still stuck*
```
Strace shows SIGALRM is received but the syscall resumes
```
recvfrom(5, 0x55bb21c77c38, 16384, 0, NULL, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn({mask=[]}) = -1 EINTR (Interrupted system call)
recvfrom(5,
```
### Possible fixes
* Make syscalls non resumable?
* :x: Use IO::Socket::Timeout ?
Backlog
Maxime Besson
Maxime Besson
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2147
LLNG should accept endpoints in any character case
2020-08-14T13:44:34Z
Yadd
LLNG should accept endpoints in any character case
This requires just to change Common/PSGI/Route to transform any route in lowercase
This requires just to change Common/PSGI/Route to transform any route in lowercase
In discussion
Yadd
Yadd
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2039
Session encryption
2020-04-16T14:39:16Z
Maxime Besson
Session encryption
### Summary
Some of our (usually large corporate) users are asking for some form of session encryption.
The current design lets any DBA read the content of user sessions (which might contain personal data), and since the lookup key is ...
### Summary
Some of our (usually large corporate) users are asking for some form of session encryption.
The current design lets any DBA read the content of user sessions (which might contain personal data), and since the lookup key is usually the session ID, they also can easily access valid session IDs, allowing identity spoofing.
### Design proposition
I have several ideas about how, and where, to implement this.
#### In ::Common::Session
* Pros: compatible with every existing session backend, does not require modifying Apache::Session::*
* Cons: We can only encrypt session content and session IDs, and not indexed fields. This might not be an issue because very large setups usually don't use the session explorer at all. And we don't use indexes all that much in the portal code. Some features won't work anymore at large scale (IP restrictions, some SAML use cases...)
#### In Apache::Session::*
* Pros: can be used to encrypt indexes, so we have (almost) feature parity with non-encrypted sessions.
* Pros: Works with any LLNG version
* Cons: requires a lot more work and more maintenance overhead. We probably will only do that work in the Apache::Session::Browseable module. If we go this way, I will only implement Redis and MongoDB first because that's where the current demand (for encrypted sessions) is, and the rest will come later.
### Caveats
Whatever we chose to implement
* searchOnExpr can not work anymore, or at least it won't be able to take advantage of indexes.
* we're expecting some performance penalty, to be measured
* Encrypting indexes with predictable values (_httpSessionType, etc.) might weaken the secret key, but I'm not sure about this. So we might need both an `Index` and and `EncryptedIndex` config option
* We'll need to use a good crypto lib, AES::CBC is not very future-proof, one of our users suggested [Crypt::NaCl::Sodium](https://metacpan.org/release/Crypt-NaCl-Sodium) but it's not packaged anywhere yet.
@guimard , @clement_oudot , what are your thoughts about this? Especially on ::Common::Session vs Apache::Session ?
3.0.0
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2032
Better uWSGI integration
2019-12-04T09:26:43Z
Christophe Maudoux
chrmdx@gmail.com
Better uWSGI integration
### Summary
Link to #2031
### Summary
Link to #2031
3.0.0
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2029
Create a specific subdomain on default installation to restrict visibility of...
2019-11-25T11:17:09Z
Clément OUDOT
Create a specific subdomain on default installation to restrict visibility of SSO cookie
Until now, we use a wide domain (example.com) as default value, which is not a good practice, as the SSO cookie is then visible for all applications on this domain.
We should instead configure a subdomain (sso.example.com) with portal a...
Until now, we use a wide domain (example.com) as default value, which is not a good practice, as the SSO cookie is then visible for all applications on this domain.
We should instead configure a subdomain (sso.example.com) with portal and manager inside it (auth.sso.example.com and manager.sso.example.com).
3.0.0
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2026
Simplify whatToTrace / LL::NG unique ID management
2024-02-06T08:53:30Z
Clément OUDOT
Simplify whatToTrace / LL::NG unique ID management
After discussions, we agree that the whatToTrace configuration is not very clear.
We suggest to keep whatToTrace parameter, but instead of beeing just a reference to a session key, it will be an expression that can be evaluated, so we d...
After discussions, we agree that the whatToTrace configuration is not very clear.
We suggest to keep whatToTrace parameter, but instead of beeing just a reference to a session key, it will be an expression that can be evaluated, so we don't need no more the _whatToTrace macro.
We also need to rename this parameter. Propositions for now are: lemon_uid, ll_uid, llng_uid.
3.0.0
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1854
Git configuration backend
2019-11-21T11:21:47Z
Yadd
Git configuration backend
### Summary
Configuration could be based on Git: this would be a wrapper around file which would use `git pull` and `git push` to download/upload configuration. Then only manager server repo will be configured using ssh and a key, other...
### Summary
Configuration could be based on Git: this would be a wrapper around file which would use `git pull` and `git push` to download/upload configuration. Then only manager server repo will be configured using ssh and a key, other will use https _(native git security)_
### Design proposition
JSON files will be beautified before upload to easy read differences
This needs also a git hook to be able to find commit by configuration number and some methods to get a non-last configuration (like `git archive`)
Backlog
Yadd
Yadd
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1823
[Security:improvement] Improved use of cryptography
2023-11-13T14:43:20Z
Raphael Geissert
[Security:improvement] Improved use of cryptography
Poking different parts of the code base it would appear that the use of cryptography by LLNG needs to be reviewed, updated, and simplified. Some examples:
* `Lemonldap::NG::Common::Crypto` has code to use md5 to what looks like a key-der...
Poking different parts of the code base it would appear that the use of cryptography by LLNG needs to be reviewed, updated, and simplified. Some examples:
* `Lemonldap::NG::Common::Crypto` has code to use md5 to what looks like a key-derivation function. PBKDF2 and similar HMAC-based algorithms exist to do that.
* data seems to be encrypted, again with the Crypto module, but not signed. Authenticated encryption should be critical if the encrypted data is ever sent to or received from an untrusted party.
* Use of non-crypto-safe rngs like in #1803 and #1633
* Lastly, but worrisome, by using a low-level primitive like AES directly it appears that some basics were forgotten: the same key appears to be used to sign multiple messages without ever setting an initialization vector! meaning that the IV in use is always a zero.
Libraries such as NaCl and libsodium were created to reduce the complexity of using cryptographic functions the right way. Perhaps using one of the perl binding to libsodium could be a way to address these problems.
E.g. for #1803 there's `randombytes_uniform`. For encryption? `crypto_secretbox_*`, data authentication? `crypto_auth`.
Marking this issue as confidential given that the IV reuse could be pretty serious. I have not tried to asses the impact in the case of LLNG.
C.f. https://cwe.mitre.org/data/definitions/329.html
3.0.0
Yadd
Yadd
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1808
Room for improvement in Apache::Session::Generate::SHA256
2021-10-16T06:04:16Z
Raphael Geissert
Room for improvement in Apache::Session::Generate::SHA256
The `Lemonldap::NG::Common::Apache::Session::Generate::SHA256` module could use an update, it:
* imports some methods like sha256 but doesn't use them,
* reads 64 bytes of urandom, but only because that's the length of the output of sha2...
The `Lemonldap::NG::Common::Apache::Session::Generate::SHA256` module could use an update, it:
* imports some methods like sha256 but doesn't use them,
* reads 64 bytes of urandom, but only because that's the length of the output of sha256_hex,
* does a second round of hashing for no documented reason,
* hashes the output of: `time`, `{}`, and `$$`, but at best they do no harm and at worst they could leak information
Moreover, it doesn't handle the fact that `Crypt::URandom` could croak. Not sure if that's handled nicely by other parts of LLNG?
3.0.0