lemonldap-ng issueshttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues2024-03-16T11:40:53Zhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3030Implement ANSSI recommendations for securing the implementation of the Openid...2024-03-16T11:40:53ZYaddImplement ANSSI recommendations for securing the implementation of the Openid-Connect protocolRef: [Recommendations for securing the implementation of the Openid-Connect protocol _(fr)_](https://cyber.gouv.fr/publications/recommandations-pour-la-securisation-de-la-mise-en-oeuvre-du-protocole-openid-connect)
> Most of the items a...Ref: [Recommendations for securing the implementation of the Openid-Connect protocol _(fr)_](https://cyber.gouv.fr/publications/recommandations-pour-la-securisation-de-la-mise-en-oeuvre-du-protocole-openid-connect)
> Most of the items are included into %2.18.0 except if mentioned below.
## Items related to LLNG
### [LLNG as OIDC Relying Party](lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Auth/OpenIDConnect.pm):
* [X] Already implemented and enabled
* [X] Always send `state` _(R10)_
* [X] Randomly generate `state` and `nonce` _(R11, R15)_
* [X] Verify "state" _(R22)_
* [X] Verify `id_token` _(R26, R28)_
* [X] Check that `/userinfo` response and `id_token` have the same `sub`
* [X] [Doc about items to check](!430)
* [X] `oidcOPMetaDataOptionsUseNonce` required _(R14)_
* [X] Disable `HS*` algorithms _(to workaround "distinct client_secret" R27 recommendation + R39)_
* `/token` calls:
* [x] [implement JWS authentication](#3031) _(level+)_
* `code` requests
* [X] Implement optional [Passing Request Parameters as JWTs](#3073) during `code` request _(R8 and R8+)_ - release %2.19.0
### [LLNG as OIDC Provider](lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Issuer/OpenIDConnect.pm):
* [X] Already implemented and enabled
* [X] randomly generate `code` _(R18)_
* [X] randomly generate `access_token` _(R24)_
* [X] associate `access_token` with RP _(R20)_
* [X] disable `code` after `/token` call _(R30)_
* [X] don't write `access_token` in logs _(R32)_
* [X] limit `access_token` TTL _(R33)_
* [X] Use session cookie
* [X] [Doc about items to check](!430)
* [X] hybrid and implicit flows must be disabled _(R1)_
* [X] disable `HS*` algorithms _(to workaround "distinct client_secret" R27 recommendation + R39)_ _**[Restrict]**_
* [X] disable automatic enrollment _(R49)_
* [X] limit `access_token` validity in endpoints to a short time _(R19)_
* [X] reject open redirections _(R17)_
* `code` request
* [x] [support JWS authentication](!397) _(R8, R8+)_
* [x] [accept only one mode per RP](!397) _(R9)_ _**[Restrict]**_
* [X] accept JWT _(R8 and R8+)_
* [X] [require it](!427) _**[Out]**_ - release %2.19.0
* [X] [require `state` and `nonce`](!428) _(R12, R16)_ _**[Restrict]**_ - release %"2.19.0"
* `/token` calls:
* [x] [implement JWS authentication](#3031) _(level+)_
* [X] [require it](!397) _**[Out]**_
* `/userinfo` calls:
* [X] [authentication using access_token only inside `Authorization: Bearer` header](!429) _(R31)_ _**[Restrict]**_ - release %2.19.0
* [ ] ToDo:
* Auto-discover
* [ ] Disable `/.well-known/openid-configuration` _(R48, given by hand, but then give a way to download the document using the manager)_ _**[Out]**_
* `code` requests
* [ ] [store `code` and `access_token` using hash](!462) _(R21, R25)_ - release %"2.19.0"
----
Notes:
* _**[Restrict]**: Restrict the OpenID-Connect spec, may break some clients_
* _**[Out]**: out of OpenID-Connect Spec, will break a lot of clients_2.19.0YaddYaddhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3123JWKS timeout is not implemented2024-03-27T10:40:19ZMaxime BessonJWKS timeout is not implemented### Affected version
Version: 2.18.2
### Summary
* Configure Auth::OpenIDConnect with a test OP
* set oidcOPMetaDataOptionsJWKSTimeout = 30 (or any non zero value)
* When restarting portal, JWKS is downloaded :white_check_mark:
* Aft...### Affected version
Version: 2.18.2
### Summary
* Configure Auth::OpenIDConnect with a test OP
* set oidcOPMetaDataOptionsJWKSTimeout = 30 (or any non zero value)
* When restarting portal, JWKS is downloaded :white_check_mark:
* After 30 seconds, JWKS is not refreshed :x:2.19.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3091Send mail on password change doesn't work corretcly2024-03-27T10:46:54ZGabriele LicariSend mail on password change doesn't work corretcly### Affected version
Version: 2.18.1
Good Morning,
The option "Send a mail when password is changed" is activated, but users receive confirmation of the password change only when they force the reset (forgotten password) but not when ...### Affected version
Version: 2.18.1
Good Morning,
The option "Send a mail when password is changed" is activated, but users receive confirmation of the password change only when they force the reset (forgotten password) but not when they change it independently once logged in. What can I check to fix
this?
This seems to be a bug.2.19.0Clément OUDOTClément OUDOThttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3061lwpOpts and lwpSslOpts parameters not used in REST session module2024-03-27T10:48:59ZClément OUDOTlwpOpts and lwpSslOpts parameters not used in REST session moduleWhen 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.0Clément OUDOTClément OUDOThttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3048Error in Notification DBI backend2024-03-27T10:53:14ZClément OUDOTError in Notification DBI backendOna production environment, we encounter this error:
```
DBD::Pg::st execute failed: aucune connexion au serveur at /usr/share/perl5/Lemonldap/NG/Common/Notifications/DBI.pm line 283.
```
The DB is well started, so I suspect a bad conne...Ona production environment, we encounter this error:
```
DBD::Pg::st execute failed: aucune connexion au serveur at /usr/share/perl5/Lemonldap/NG/Common/Notifications/DBI.pm line 283.
```
The DB is well started, so I suspect a bad connection management in Notification DBI module.
Not easy to reproduce.2.19.0Clément OUDOTClément OUDOThttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2822Nginx FastCGI error SAML related "Can't call method "data" on an undefined va...2024-03-27T10:54:11ZYannick BELUCHENginx FastCGI error SAML related "Can't call method "data" on an undefined value"### Concerned version
Version: %2.0.15.1-1
Platform: (Nginx)
### Summary
I encountered the following error in nginx LLNG portal logs and I couldn't figured out where that came from.
### Logs
In portal-nginx.log:
```
2022/11/17 11:...### Concerned version
Version: %2.0.15.1-1
Platform: (Nginx)
### Summary
I encountered the following error in nginx LLNG portal logs and I couldn't figured out where that came from.
### Logs
In portal-nginx.log:
```
2022/11/17 11:18:43 [error] 3283#3283: *576932 FastCGI sent in stderr: "Can't call method "data" on an undefined value at /usr/share/perl5/Lemonldap/NG/Portal/Lib/SAML.pm line 3240" while reading response header from upstream, client: <IP>, server: auth.mydomain.com, request: "POST /saml/proxySingleLogoutSOAP HTTP/1.1", upstream "fastcgi://unix:/var/run/llng-fastcgi.sock:", host: "auth.mydomain.com"
```
### Backends used
Apache::File
### Possible fixes2.19.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2461Session cache not invalidated when upgrading session with 2FA2024-03-26T12:45:04ZDaniel BerteaudSession cache not invalidated when upgrading session with 2FA### Concerned version
Version: 2.0.11
Platform: CentOS Stream 8 / nginx 1.19 (openresty with lua support) / MariaDB 10.5
### Summary
When using 2FA for session upgrade, it looks like the local session cache is not invalidated. So :
-...### Concerned version
Version: 2.0.11
Platform: CentOS Stream 8 / nginx 1.19 (openresty with lua support) / MariaDB 10.5
### Summary
When using 2FA for session upgrade, it looks like the local session cache is not invalidated. So :
- I log in with simple login + password against Samba4, with an authentication level of 2
- I try to access an app which requires an auth level of 5
- I'm redirected to the session upgrade form, and I'm prompted for my 2FA (I've setup TOTP, Mail and Yubikey)
- I use my Yubikey to upgrade my session
- 2FA is validated, my auth level is now 5
- Instead of being redirected to the secured app, I'm again on the session upgrade page
- I need to wait a few minutes, or auth with my 2FA 3 or 4 times before I'm granted the access
### Logs
```
févr. 11 18:30:09 proxyin LLNG[140746]: [notice] User dani successfully authenticated at level 2
févr. 11 18:30:09 proxyin LLNG[140746]: [notice] dani connected
févr. 11 18:30:20 proxyin LLNG[140746]: [warn] User rejected due to insufficient authentication level -> Session upgrade enabled
févr. 11 18:30:24 proxyin LLNG[140980]: [info] Second factor required for dani
févr. 11 18:30:24 proxyin LLNG[140980]: [info] dani is allowed to update 2FA
févr. 11 18:30:24 proxyin LLNG[140980]: [info] dani is allowed to update 2FA
févr. 11 18:30:29 proxyin LLNG[141003]: [info] No cookie found
févr. 11 18:30:31 proxyin LLNG[140980]: [notice] yubikey2F verification for dani
févr. 11 18:30:31 proxyin LLNG[140980]: [notice] User dani successfully authenticated at level 5
févr. 11 18:30:31 proxyin LLNG[140980]: [notice] User dani successfully authenticated at level 5
févr. 11 18:30:31 proxyin LLNG[140980]: [notice] dani connected
févr. 11 18:30:31 proxyin LLNG[140746]: [warn] User rejected due to insufficient authentication level -> Session upgrade enabled
```
### Backends used
Session is using DBI (MariaDB), config is CDBI (MariaDB). Localcache is defined as
```
localSessionStorage = Cache::FileCache
localSessionStorageOptions = { \
'namespace' => 'sessions', \
'default_expires_in' => '300', \
'directory_umask' => '007', \
'cache_root' => '/var/cache/lemonldap-ng', \
'cache_depth' => 3 \
}
```
I guess it's a local cache issue (because if I just wait a few minutes after my first 2FA auth, it's working)2.19.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3124Allow users to configure WebAuthn relying party ID2024-03-20T13:29:26ZMaxime BessonAllow users to configure WebAuthn relying party ID### Summary
Some users want to use an external system to register WebAuthn credentials
This requires a given WebAuthn device to share credentials between the portal and the registration system
### Design proposition
Allow the RP ID t...### Summary
Some users want to use an external system to register WebAuthn credentials
This requires a given WebAuthn device to share credentials between the portal and the registration system
### Design proposition
Allow the RP ID to be configured in 2F::WebAuthn2.19.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3092Display an error message when issuer context is not restored2024-01-25T15:49:33ZMaxime BessonDisplay an error message when issuer context is not restored### Affected version
Version: 2.18.1
### Summary
* Configure LLNG as an SAML/OIDC or CAS issuer
* Initialize login from a SP
* Log in using 2FA, SAML or something else that longer than issuersTimeout to perform
* Login works, but yo...### Affected version
Version: 2.18.1
### Summary
* Configure LLNG as an SAML/OIDC or CAS issuer
* Initialize login from a SP
* Log in using 2FA, SAML or something else that longer than issuersTimeout to perform
* Login works, but you are redirected either to the portal (SAML/CAS) or an error message (OIDC)
### Logs
```
[INFO] Bad (or expired) token 1706124567_32351
[ERROR] Unknown response type:
```
### Possible fixes
The user often gets confused about ending up on the portal, we should at least give them an error message that says they took too long so that they can understand why the application isn't displayed2.19.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3040Allow auto-detection of portal URL and domain2024-03-28T16:34:28ZMaxime BessonAllow auto-detection of portal URL and domainOne of my LLNG instances needs to be reached by internal and external users but on a different URL.
The portal uses $self->conf->{portal} and $self->conf->{domain} to get its own URL and cookie domain. But it doesn't work in this partic...One of my LLNG instances needs to be reached by internal and external users but on a different URL.
The portal uses $self->conf->{portal} and $self->conf->{domain} to get its own URL and cookie domain. But it doesn't work in this particular use case, because in my use case the portal and domain depends on `$req`.
This is similar to #933, but I think the fix proposed there no longer works since the migration to PSGI.
In the handler: it's probably not too difficult to do because every access to the portal URL goes through $class->tsv->portal. We just need to pass `$req` to it.
In the portal: we need to replace all calls to `$self->conf->{portal}` and `$self->conf->{domain}` to methods such as `getPortalUrl($req)` and `getDomain($req)`. This will require a lot of refactoring, but I think its a good idea because users will no longer have to define the `portal` and `domain` configuration variables anymore in most cases.
This is also a requirement of #2285
If I can find sponsorship for this feature I might implement it in 2.192.19.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2941Replace userLogger with a more flexible system2024-03-25T16:13:33ZMaxime BessonReplace 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.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2700session extension hook2024-03-27T10:57:12Zdcoutadeur dcoutadeursession extension hook### Summary
This feature is asked by a customer, but can be interresting for other, especially if it is design in a generic way.
The main feature is to intercept some events and trigger a SSO session extension.
### Design proposition...### Summary
This feature is asked by a customer, but can be interresting for other, especially if it is design in a generic way.
The main feature is to intercept some events and trigger a SSO session extension.
### Design proposition
After some basic researches, I didn't found any sort of norms or standards for this.
Here is the design proposition:
1. the hook will intercept some events. Possible events are:
- when user call /ping endpoint on the portal, with a valid cookie
- when user authenticates,
- when user reauthenticates,
- when user asks for a "refresh my rights from the portal",
- when user is asked for a session upgrade (he must enter a second factor for accessing a more secure application)
- when an application sends a direct call to /ping, with the user session id passed in the Authentication header (we should think about security risks. Maybe replay attacks?)
- when refreshing an access token with a refresk token
- any other event I haven't think about?
The list of triggering events must be customizable.
2. it possibly triggers two actions:
- if timeoutActivity is set, it performs the same actions as in `Handler/Main/Run.pm` (function `retrieveSession`): it verifies if session is valid, checks the session is not expired (timeoutActivity), and updates _lastSeen in session. Note: thus it may be interresting to factorize this code if possible.
- if triggers an AT refresh thanks to the refresh token. The list of OIDC provider on which it is triggered must be customizable. Obviously, the refresh must occurs only if the user has authenticated against the given OIDC provider.
Do not hesitate to discuss this proposition and give your ideas.2.19.0dcoutadeur dcoutadeurdcoutadeur dcoutadeurhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1848select authentication scheme according to authentication level2024-03-18T11:43:02Zdcoutadeur dcoutadeurselect authentication scheme according to authentication level### Summary
It would be nice to have a feature allowing the portal to choose the authentication scheme according to an authentication level.
This feature is to be considered as an evolution of:
```
https://lemonldap-ng.org/documentation...### Summary
It would be nice to have a feature allowing the portal to choose the authentication scheme according to an authentication level.
This feature is to be considered as an evolution of:
```
https://lemonldap-ng.org/documentation/latest/writingrulesand_headers
Instead of returning a 403 code, “minimum level” returns user to a form that explain that a higher level is required and propose the user to reauthenticate himself.
```
in other words, make the application "decide" the authentication scheme of the portal.
### Design proposition
[manager]
add a new parameter: desiredAuthenticationLevel for each vhost
[handler]
handler checks if desiredAuthenticationLevel is set
if desiredAuthenticationLevel > 0, handler redirects the user to <portal>?url=base64(url)&desiredAuthenticationLevel=n
[portal]
if portal is configured for "combination" module (and maybe also for choice module), then he tries to honor the desiredAuthenticationLevel only in case of scheme testing (ie combination using OR).
**example1:**
* desiredAuthenticationLevel = 5
* SSL = 5
* Kerberos = 4
* LDAP = 2
if after evaluating the if conditions in the combination rule, we get:
```
[Kerberos, LDAP] or [SSL, LDAP] or [LDAP, LDAP]
```
the OR components should be rearranged to make SSL appear first:
```
[SSL, LDAP] or [Kerberos, LDAP] or [LDAP, LDAP]
```
**example2:**
* desiredAuthenticationLevel = 2
* SSL = 5
* Kerberos = 4
* LDAP = 2
if after evaluating the if conditions in the combination rule, we get:
```
[SSL, LDAP] or [Kerberos, LDAP] or [LDAP, LDAP]
```
the OR components should be rearranged into:
```
[LDAP, LDAP] or [SSL, LDAP] or [Kerberos, LDAP]
```
if the authentication is set to "Choice", then we could also rely on the desiredAuthenticationLevel to display by default the tab corresponding to the desired authentication scheme.
### Security considerations
It might be dangerous to let desiredAuthenticationLevel be passed as an unencrypted GET parameter.
It might be used by an attacker to prevent a user to access an application.
What do you think about this proposition? Is there already some attempts to do something similar? Do you think about a better architecture / conception for this feature? It's opened to discussion.2.19.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3111Hide Code2F secrets even from debug logs2024-03-27T10:25:25ZMaxime BessonHide Code2F secrets even from debug logsCurrently, secrets such as OTP codes (Code2F.pm) are displayed in cleartext in debug logs.
This is useful for debugging
Some users want to be able to hide the values even from error logs
We should find a way to do this, maybe a special ...Currently, secrets such as OTP codes (Code2F.pm) are displayed in cleartext in debug logs.
This is useful for debugging
Some users want to be able to hide the values even from error logs
We should find a way to do this, maybe a special value in hiddenAttributes ?2.19.0Clément OUDOTClément OUDOThttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3103Add a plugin/issuer for Jitsi Meet JWT authentication2024-03-27T04:30:33ZMaxime BessonAdd a plugin/issuer for Jitsi Meet JWT authenticationThe popular Jitsi Meet application does not use OIDC or SAML, but relies on a custom JWT format.
Some projects already bridge the gap between Jitsi and standard SSO protocols
https://github.com/Renater/Jitsi-SAML2JWT
(and others)
But ...The popular Jitsi Meet application does not use OIDC or SAML, but relies on a custom JWT format.
Some projects already bridge the gap between Jitsi and standard SSO protocols
https://github.com/Renater/Jitsi-SAML2JWT
(and others)
But they require deploying yet another piece of software, usually from Docker
We could include a plugin that does the same job, directly inside LLNG2.19.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3097manager API: allow registration of 2FA2024-03-27T08:34:27ZMaxime Bessonmanager API: allow registration of 2FAFor now the 2FA endpoints of the manager API do not support creating new 2F devices
We should provide endpoints for writing to _2fDevices conveniently
TODO: create new persistent sessionFor now the 2FA endpoints of the manager API do not support creating new 2F devices
We should provide endpoints for writing to _2fDevices conveniently
TODO: create new persistent session2.19.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3086Make systemd timers taken from debian directory available globally2024-03-27T10:01:48ZXavier BachelotMake systemd timers taken from debian directory available globally### Summary
Make systemd timers taken from debian directory available globally
### Design proposition
Also make sure variables set when calling make are properly replaced in the various provided systemd/cron/etc... files.
General house...### Summary
Make systemd timers taken from debian directory available globally
### Design proposition
Also make sure variables set when calling make are properly replaced in the various provided systemd/cron/etc... files.
General housekeeping of the Makefile.
See !4352.19.0Xavier BachelotXavier Bachelothttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3038OKTA 2FA module2024-03-19T12:02:04ZClément OUDOTOKTA 2FA moduleThis feature request is about a new 2FA module which will use OKTA API: https://developer.okta.com/docs/reference/api/factors/
The use case:
* An organization is using LL::NG as main authentication portal
* For some power users, it choo...This feature request is about a new 2FA module which will use OKTA API: https://developer.okta.com/docs/reference/api/factors/
The use case:
* An organization is using LL::NG as main authentication portal
* For some power users, it choosed to buy some OKTA accounts, including MFA
* The user will register its MFA on OKTA (mail, SMS, mobile app, ...)
* The user will authenticate on LL::NG portal and use OKTA MFA as second factor
This requires of course that the user login on OKTA is known by LL::NG to request to correct MFA account.2.19.0Clément OUDOTClément OUDOThttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3096No more logs Session granted for *2024-02-01T17:14:32Zdcoutadeur dcoutadeurNo more logs Session granted for *As stated by the documentation:
https://lemonldap-ng.org/documentation/2.0/logs.html#user-log-samples
we should have a log displaying the user logged and his IP address:
```
[notice] Session granted for dwho by LDAP (81.20.13.21)
```
...As stated by the documentation:
https://lemonldap-ng.org/documentation/2.0/logs.html#user-log-samples
we should have a log displaying the user logged and his IP address:
```
[notice] Session granted for dwho by LDAP (81.20.13.21)
```
However, now, the log is managed by the GrantSession plugin, which is not enabled by default, as in configuration we have:
```
'grantSessionRules' => {}
```
and empty hash is considered as disabled.
This issue is just to discuss the desired behaviour:
- set a default value:
```
'grantSessionRules' => {
'always allowed##default_rule' => 1
}
```
- fix the documentation to indicate that there is no log by default, except if the admin set a grantSessionRule2.19.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2466GD::SecurityImage seems unmaintained2021-02-18T08:17:25ZYaddGD::SecurityImage seems unmaintained### Concerned version
Version: %2.0.x
Platform: any
### Summary
Looking at [GD::SecurityImage upstream repo](https://github.com/burak/CPAN-GD-SecurityImage) _(and the [lack of responses](https://github.com/burak/CPAN-GD-SecurityImage...### Concerned version
Version: %2.0.x
Platform: any
### Summary
Looking at [GD::SecurityImage upstream repo](https://github.com/burak/CPAN-GD-SecurityImage) _(and the [lack of responses](https://github.com/burak/CPAN-GD-SecurityImage/issues) to our bugs)_, this library looks unmaintained. I think we should replace it either by a better maintained library, either building our own _(using a fork of GD::Security ?)_.
For now, there are no known security issue, that's why I assigned this issue to %"3.0.0"3.0.0