lemonldap-ng issueshttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues2019-09-17T18:42:14Zhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1919Customizable error message when a required SAML attribute is missing2019-09-17T18:42:14ZMaxime BessonCustomizable error message when a required SAML attribute is missing### Summary
Currently, when a SAML application is configured to require an attribute from session, the following code is run if the attribute is actually missing:
```
unless ( defined $value ) {
if ($mandatory) {...### Summary
Currently, when a SAML application is configured to require an attribute from session, the following code is run if the attribute is actually missing:
```
unless ( defined $value ) {
if ($mandatory) {
$self->logger->error(
"Session key $_ is required to set SAML $name attribute"
);
return PE_SAML_SSO_ERROR;
}
```
And a generic PE_SAML_SSO_ERROR is shown to the user.
However, some organizations might want to change this error message, but only in this particular error case.
For example.
"You are missing a required attribute, please connect to [Some client app] and complete your profile"
### Design proposition
I will add a new portal error code, and a corresponding defaut translation that users may customize through the translation system2.0.6Maxime BessonMaxime Besson2019-09-06https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2177OIDC: Allow additional audiences for ID Token2020-04-24T10:18:46ZMaxime BessonOIDC: Allow additional audiences for ID Token### Summary
Currently, `aud` field in our ID tokens only contain the Client ID
We have a use case for additional audiences, which will be configured in the manager
### Design proposition
Introduce a new option with a space delimited ...### Summary
Currently, `aud` field in our ID tokens only contain the Client ID
We have a use case for additional audiences, which will be configured in the manager
### Design proposition
Introduce a new option with a space delimited value2.0.8Maxime BessonMaxime Besson2020-04-24https://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/2185Append a rule to display sfaManager link2020-04-30T20:29:41ZChristophe Maudouxchrmdx@gmail.comAppend a rule to display sfaManager link### Summary
Display sfaManager link only if required### Summary
Display sfaManager link only if required2.0.8Christophe Maudouxchrmdx@gmail.comChristophe Maudouxchrmdx@gmail.com2020-04-30https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2178Make require old password option configurable by a rule2020-04-28T17:03:55ZChristophe Maudouxchrmdx@gmail.comMake require old password option configurable by a rule### Summary
To reset password, we can require or not old password.
By example, the rule does not require old password if authLevel equal 5### Summary
To reset password, we can require or not old password.
By example, the rule does not require old password if authLevel equal 52.0.8Christophe Maudouxchrmdx@gmail.comChristophe Maudouxchrmdx@gmail.com2020-04-30https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2345RGAA recommand alt tags to be empty for decoration images2020-10-31T23:06:06Zdcoutadeur dcoutadeurRGAA recommand alt tags to be empty for decoration images### Environment
LemonLDAP::NG version: 2, 3
### Summary
RGAA recommand alt tags to be empty for decoration images
See criterium 1.2 here: https://www.numerique.gouv.fr/publications/rgaa-accessibilite/methode/criteres/
Providing fix...### Environment
LemonLDAP::NG version: 2, 3
### Summary
RGAA recommand alt tags to be empty for decoration images
See criterium 1.2 here: https://www.numerique.gouv.fr/publications/rgaa-accessibilite/methode/criteres/
Providing fix soon2.0.10dcoutadeur dcoutadeurdcoutadeur dcoutadeur2020-10-16https://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/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/3117Add a hook before 2fa retry2024-03-08T10:17:50ZMaxime BessonAdd a hook before 2fa retryWe 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 retriedWe 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 retried2.19.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3115Date in login history is based on session _utime, not the very same time as t...2024-03-27T09:53:05Zphilippe lhardyphilha@worteks.comDate 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.0philippe lhardyphilha@worteks.comphilippe lhardyphilha@worteks.comhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3113Add possibility to store conf secrets in separated files2024-03-27T09:09:10ZYaddAdd possibility to store conf secrets in separated filesWhen 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.0YaddYaddhttps://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/3102Allow custom ordering in history session keys2024-03-18T13:07:55ZMaxime BessonAllow custom ordering in history session keysSurrently, 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 ChoicesSurrently, 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 Choices2.19.0Abhishek PaiAbhishek Paihttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3101OIDC offline session refresh has no access to previous session info2024-03-26T13:21:23ZMaxime BessonOIDC offline session refresh has no access to previous session infoFor 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 Main2.19.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3100Add PKCE option inside Auth::OpenIDConnect2024-02-28T04:51:07ZYaddAdd PKCE option inside Auth::OpenIDConnectYes 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.0YaddYaddhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3099second factor type is not stored in history in case of a 2FA failure2024-03-26T12:32:06ZMaxime Bessonsecond 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 history2.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/3095Add llngUserAttributes tools2024-03-27T09:16:32ZYaddAdd llngUserAttributes toolsThe 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.0YaddYadd