lemonldap-ng issueshttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues2020-04-08T09:41:49Zhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2137Redirecting in CAS with post method2020-04-08T09:41:49ZAndreas DeschkaRedirecting in CAS with post methodHello,
as far as I understand, it would be good for CASv3, if the redirect can be done with POST, because of javascript cross site scripting danger in the client.
(It would be also good for OIDC implicit flow, but there is the alternat...Hello,
as far as I understand, it would be good for CASv3, if the redirect can be done with POST, because of javascript cross site scripting danger in the client.
(It would be also good for OIDC implicit flow, but there is the alternative of the code flow.)
What I tried (for CAS), both did not work:
- added a method parameter with POST in the CAS URL as documented in the CASv3 specification ( https://apereo.github.io/cas/5.0.x/protocol/CAS-Protocol-Specification.html#211-parameters )
- set in lemonldap manager: redirectFormMethod = "POST"
But maybe it is also a bug (version 2.0.7)?
In the autoRedirect method it seems it will always be a GET request in the end:
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/blob/3b1b1b1997b4c7967cc452194aa92f77c512d0a8/lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Main/Run.pm#L352
By manually setting $req->data->{redirectFormMethod} = "post" it was possible to do the redirecting with POST.
Maybe I also have overlooked something...
Greetings
Andreas Deschka3.0.0https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2122Add a plugin entrypoint between setsessioninfo and setmacros2020-08-18T13:28:30ZMaxime BessonAdd a plugin entrypoint between setsessioninfo and setmacros### Summary
Several of our users have a need to enhance the session with extra attributes (from an external LDAP, DB, etc), and sometimes using Combination isn't an option (because we're already in Choice or because no userDB module doe...### Summary
Several of our users have a need to enhance the session with extra attributes (from an external LDAP, DB, etc), and sometimes using Combination isn't an option (because we're already in Choice or because no userDB module does exactly what we want).
In order to do that, we can create a plugin and populate session attributes in `afterData`
But usually, users want these plugin-provided attributes to be available earlier than `afterData` so they can use the new attributes for 2FA rules, macros...
The solution is to hook the plugin with:
```
use constant afterSub => {
setSessionInfo => 'run',
};
```
But since this is a pretty common use case, perhaps we should have a first-class entrypoint for this ?
### Design proposition
perhaps a `beforeMacros` or `earlyData` entrypoint that runs just after setSessionfo ?3.0.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2083Offline sessions do not work with delegated auth providers (saml, oidc...), c...2023-08-24T10:02:29ZMaxime BessonOffline sessions do not work with delegated auth providers (saml, oidc...), choice and combination### Concerned version
Version: 2.0.7
### Summary
The current implementation of offline sessions (see #813) calls getUser to refresh user attributes when the refresh token is exchanged for a new access token.
This is necessary because...### Concerned version
Version: 2.0.7
### Summary
The current implementation of offline sessions (see #813) calls getUser to refresh user attributes when the refresh token is exchanged for a new access token.
This is necessary because these sessions can be very long lived, and we might want them to "see" when an attribute is updated.
When using a delegated provider (SAML, OIDC, facebook...), getUser/setSessionInfo will not work outside of a a complete authentication flow. Which causes an error:
### Logs
```
[debug] OpenID Refresh Token: 27f0e30f46e54f4c37bc439c23d49566e529615a853b099f9e83f143402e949b
[debug] Processing getUser
[debug] Returned error: 9 (PE_FIRSTACCESS)
[error] Could not resolve user: df8a8d4d-e26d-4d5f-a323-ea35e17f26ce
[warn] [anonymous] invalid_grant
```
### Possible fixes
I can see several fixes:
* Ignore getUser errors when refreshing the token
* Avoid refreshing the user info entirely: we might need an "isRefreshable" method in each auth provider that tells LLNG if we can call UserInfo on this provider outside of an auth context. This could also be useful for cases like "Refresh My Rights" and password reset.BacklogMaxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2077Mail send error if SMTP connection reset2020-04-24T09:16:09ZClément OUDOTMail send error if SMTP connection resetSee this discussion: https://mail.ow2.org/wws/arc/lemonldap-ng-users/2020-01/msg00062.html
There is a cache for SMTP connection, in `lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Lib/SMTP.pm`
```
our $transport;
has transport => (
is...See this discussion: https://mail.ow2.org/wws/arc/lemonldap-ng-users/2020-01/msg00062.html
There is a cache for SMTP connection, in `lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Lib/SMTP.pm`
```
our $transport;
has transport => (
is => 'rw',
lazy => 1,
default => sub {
return $transport if $transport;
...
```
Commenting the "return" line seems to fix the issue, but maybe we can find a better way to test connection before using it.In discussionhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2062Multiple SAML signatures in authentication response2020-04-24T09:29:19ZClément OUDOTMultiple SAML signatures in authentication responseAfter a migration to 2.0, I notice that our SAML authn responses now have 2 signatures, for example:
```xml
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assert...After a migration to 2.0, I notice that our SAML authn responses now have 2 signatures, for example:
```xml
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_39AFA0A0E55174DB8DBE5F5E5FB82EDE"
InResponseTo="_WlAaKyUXroWlTtpL"
Version="2.0"
IssueInstant="2020-01-09T13:27:15Z"
Destination="xxxx"
>
<saml:Issuer>xxxx</saml:Issuer>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<Reference URI="#_39AFA0A0E55174DB8DBE5F5E5FB82EDE">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>jGKGtk/crirq2qgQLhaP7YUQoMw=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>XavE9YWAdC94nIaCF0tr5nXVt3yDPzdef/7SucI7sFE1NtSjKol/L7n0zvipCCZW
33GB/Zyd0sptgxIOpzka/4kkIulS6RkoGYgnff3wDnJcOAsitoAPaZU1CZ/7dXOI
doaQoRtdjJgfH8razX8vWxhqZdaMqOgcTnAME+Hc09GtCN+Cwh4JQFDybiAGajG0
80XatOaqouD0Xj9RC4LRqjcjubdd/MOerfpWhncw+DnnFE41VJUXIAfd0vhUH3Ot
HA5FB/uufHhSqEazzTm0pIgr3RkZkdvNYE5PO42TRgbcH4KRsSx2LIHILScJfLOl
YueWwBpO6tPPMePkV9TOhhJa2tK9uXTZTpkLeAJMQIRTTHQO556h+BqqKqh0MQny
rs1WxyLka6EifBu54fgmbKiEqvvw6GXi76/s2oNLhUv2ThopTO7IFxTfpPeayEyA
QmrbvL6Lwg6sokn/Q72/GWxNJCiPNfk95WFX9s8qcnGVgEO5VkwW0MO9Cci9pNNe
l9YImFLMTDBbKZPOiQTA4b2bq6IaYpfta7BDyBl912wLabYt1Olq8xp4EvuEfY/2
hONRLAXvaqkWwIHXAtZx4dT+mRcqbcvT49nzclDjcrWFJPCfOLF0Jvmdtmqt5nDp
XKm5uGazaFXbLO1FvH9pHkS+W3WrMYTcjacripUYiLA=</SignatureValue>
<KeyInfo>
<KeyValue>
<RSAKeyValue>
<Modulus>
nvq7kJ8bFXdTvnSJcJ0ci08uz+UuAFb9CkZPrAbLFS/7k73usQjBx0g5fLZlVkvn
+CAiaJhl/NTLh1P9NknKOK8nXDSMmoxix0HslICW+3/rAtbZ50/ATCZ6owjyMNk1
4AyjzUUgPgtGO5yoF7Ev1GxZTVW4STtQRdyxoN96eZZDir9XASZdPxQ8gBavZ2ys
0C15qK/vseiIaMLYoz0Hsi33xP6zvP+Tpnl8ext9Ok7txribIRyjfed8/QLfVwNx
2n4Fqr3l05rojyXnJm2MliaMdvkKWadA7CKnGfC9xhcVd0UwbMyESoO8A5XwlMlt
eR1wKg0jD/jnt8ghd8yZUA03XxfQEjrvIABi+LYSTXJ2U3SKHW/qo+JG2YBg6Dni
Em/qSLv59SIeedOpY9Hbe6oMoSXwWIjr1sZSvXffxRki9kREy+38JhJ6qoAafT+m
SVPOjR1nxrcsxZifs1u5s9O6ZdLJtX7ijXktn9IywKhBTj/t2IpjJ6ypYxPt9bBT
9R0+8F4elILG5sCfMCfpOd7mYSIFswMbPKEtpFvyCfcSfKaFlMJLOtVoXARcDmBk
RwXkSzVVZojbGXGphRys8rUtWZ+eT4BwvRk4m3SI6YqMGCqAw9qtwElzF2Q5bzg9
nzWs8Vm+YlsZJH/xcRhP4ssiIeHdpuAts7pOLsDU5LE=
</Modulus>
<Exponent>
AQAB
</Exponent>
</RSAKeyValue>
</KeyValue>
</KeyInfo>
</Signature>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</samlp:Status>
<saml:Assertion Version="2.0"
ID="_747ABBF254269028B433C7B6E793C82E"
IssueInstant="2020-01-09T13:27:15Z"
>
<saml:Issuer>xxxx</saml:Issuer>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<Reference URI="#_747ABBF254269028B433C7B6E793C82E">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>aCaze1q5G200EDQUg9keMcF/EXs=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>NpLQIcvOCdInJTJAW0M+qOSfBJs+0mXoNewFxoF/7QJFhPnuMDAl/Q1Zo8Luhbmq
2COInhqWsHCi4QwYmf4+hi0SUw5FyTMTUgXdIuY9f7OZjJ0MJopQkvUhEb4UJ4kP
CNxuZSY0I8fXG4uqUYaKk59sHnusa/vHZhH9/how5Dakx5HNZd0rqeCXp/mvDcx8
djw83TAM8I9v6FcSugTWyH1nDKwp+bHMQjhUMaGixR/LJd3WPppoKLX0Brfw4D2m
miQZCkfN2SrMF3FU2RdE+ea9Vozed+t7oqlOw/d8Bx2Z1W4zYm8Si1mSvg/mBsPI
qipiT37ohK0UD3UnGRsOVxbaZhrR1QzySiCArR+O4c7pkH//9T3NjIub+2A31/W4
xUTtrjOrPXGSV/pIkbiNZYkiROAVlql0ATFeFYDACFDWArOUJLPIvCD/f09iiWDA
6vTlmk9uhrJtjkxAZNgPzvzbLStKmLrjRUnrirGmRO3t4JgWF7V/TJ4suAAZ7BwE
JFuifvpbSjk3Z+qD81AYNetuoOjgpoQWCJKBDCxcmcR5g27EDjvGk+46w6ynidBK
z2InaSfN9MP814oZp7xx20gU4QewMZC0Guyv71H+CAyhbx04VYLJkabCbYmW25Vx
oYlUl/yxQHCSeeJEwSpGIkATzPn5gX2mrR8OxuCP9dY=</SignatureValue>
<KeyInfo>
<KeyValue>
<RSAKeyValue>
<Modulus>
nvq7kJ8bFXdTvnSJcJ0ci08uz+UuAFb9CkZPrAbLFS/7k73usQjBx0g5fLZlVkvn
+CAiaJhl/NTLh1P9NknKOK8nXDSMmoxix0HslICW+3/rAtbZ50/ATCZ6owjyMNk1
4AyjzUUgPgtGO5yoF7Ev1GxZTVW4STtQRdyxoN96eZZDir9XASZdPxQ8gBavZ2ys
0C15qK/vseiIaMLYoz0Hsi33xP6zvP+Tpnl8ext9Ok7txribIRyjfed8/QLfVwNx
2n4Fqr3l05rojyXnJm2MliaMdvkKWadA7CKnGfC9xhcVd0UwbMyESoO8A5XwlMlt
eR1wKg0jD/jnt8ghd8yZUA03XxfQEjrvIABi+LYSTXJ2U3SKHW/qo+JG2YBg6Dni
Em/qSLv59SIeedOpY9Hbe6oMoSXwWIjr1sZSvXffxRki9kREy+38JhJ6qoAafT+m
SVPOjR1nxrcsxZifs1u5s9O6ZdLJtX7ijXktn9IywKhBTj/t2IpjJ6ypYxPt9bBT
9R0+8F4elILG5sCfMCfpOd7mYSIFswMbPKEtpFvyCfcSfKaFlMJLOtVoXARcDmBk
RwXkSzVVZojbGXGphRys8rUtWZ+eT4BwvRk4m3SI6YqMGCqAw9qtwElzF2Q5bzg9
nzWs8Vm+YlsZJH/xcRhP4ssiIeHdpuAts7pOLsDU5LE=
</Modulus>
<Exponent>
AQAB
</Exponent>
</RSAKeyValue>
</KeyValue>
</KeyInfo>
</Signature>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">xxxx</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData NotOnOrAfter="2020-01-10T09:27:15Z"
Recipient="xxxx"
InResponseTo="_WlAaKyUXroWlTtpL"
/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2020-01-09T13:26:15Z"
NotOnOrAfter="2020-01-10T13:28:15Z"
>
<saml:AudienceRestriction>
<saml:Audience>xxxx</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2020-01-09T13:26:16Z"
SessionIndex="4f317d845fdcac41078ba09e4ae79c799850fa546c18b1710ab90307df5219ac"
SessionNotOnOrAfter="2020-01-10T09:26:16Z"
>
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
</saml:Assertion>
</samlp:Response>
```
There is one signature in the "reponse" level and another to the "assertion" level. We also see the "Issuer" markup is duplicated. Before 2.0, the signature was only in the "assertion" part.
I did not checked yet, but I am pretty sure this is valid. Anyway, some SAML SP do not like it, this is the cas of ArcGis for my case.
I tried to disable the signature for tests, and I noticed that the signature was still present in the SAML message, at "assertion" level, but no more at "response" level. This should not be the case as signature is disabled..., there should be no signature at all.
I don't know if this behavior is linked to Lasso or to our code.FAQhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2043Using session info in Combination rules2019-12-17T14:55:59ZClément OUDOTUsing session info in Combination rulesIn version 1.9, I had a rule in Multi that used a session attribute to enable/disable a module in the stack. The use case was to dismiss Kerberos for generic accounts, so users need to enter their personal login/password on the login for...In version 1.9, I had a rule in Multi that used a session attribute to enable/disable a module in the stack. The use case was to dismiss Kerberos for generic accounts, so users need to enter their personal login/password on the login form.
The Multi rule was something like this:
```
Kerberos $employeeType !~ /generic/; LDAP
```
So the Kerberos authentication was done, the user was found but before the final authentication step the rule was evaluated (with the Safe cage) and returned false (because at the end the $employeeType was filled), so the Kerberos authentication was refused and Multi was then using LDAP to authenticate user.
How could we reproduce the same behavior in Combination? In Combination, we only have access to $env.FAQhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2028Improve authentication workflow2020-11-29T17:13:41ZClément OUDOTImprove authentication workflowIn 2.0 we had a lot of bugs with authentication workflow. We need to think on how to improve the authentication workflow.
An idea was to be able to attach labels to authentication steps and plugins, so the workflow could dismiss already...In 2.0 we had a lot of bugs with authentication workflow. We need to think on how to improve the authentication workflow.
An idea was to be able to attach labels to authentication steps and plugins, so the workflow could dismiss already validated steps.3.0.0https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2027Remove SOAP webservices and XML notifications2019-11-25T15:30:55ZClément OUDOTRemove SOAP webservices and XML notificationsIn this new major release, we will remove support of SOAP services and XML format for notifications.In this new major release, we will remove support of SOAP services and XML format for notifications.3.0.0https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2023Manage prompt=none in OIDC2019-11-21T17:01:46ZClément OUDOTManage prompt=none in OIDCSection 3.1.2 from OpenID Connect core specification
We should redirect when user is not authenticatedSection 3.1.2 from OpenID Connect core specification
We should redirect when user is not authenticated3.0.0https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2022Link application item in menu to vhost/SP2024-02-08T11:18:18ZClément OUDOTLink application item in menu to vhost/SPThe goal is to be able to know which vhost/SP is targeted by the application in menu
Would be easier in API to declare a new application (SP + application in menu) and remove both
For visibility rule, the "auto" rule will directly use ...The goal is to be able to know which vhost/SP is targeted by the application in menu
Would be easier in API to declare a new application (SP + application in menu) and remove both
For visibility rule, the "auto" rule will directly use the access rule of the linked vhost/SP3.0.0https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2017Update local session cache when calling refresh my rights2023-02-04T15:33:19ZClément OUDOTUpdate local session cache when calling refresh my rightsAll is in the title :wink:All is in the title :wink:In discussionYaddYaddhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1959OIDC Client Configuration endpoint2019-11-15T22:49:38ZClément OUDOTOIDC Client Configuration endpointIn openid-connect-registration spec, an optional feature is the client configuration endpoint: https://openid.net/specs/openid-connect-registration-1_0.html#ClientConfigurationEndpoint
We could implement it, but the spec requires a spec...In openid-connect-registration spec, an optional feature is the client configuration endpoint: https://openid.net/specs/openid-connect-registration-1_0.html#ClientConfigurationEndpoint
We could implement it, but the spec requires a specific access token that is sent when client is registered. There is no precision about this token lifetime, it seems it could last forever.3.0.0https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1937CheckState - Return error 500 when user is disable2019-09-18T14:52:44ZMathieu Lecompte-melançonCheckState - Return error 500 when user is disable### Concerned version
Version: %2.0.5
Platform: Nginx
### Summary
We use CheckState as a check in our centreon(monitoring).
https://lemonldap-ng.org/documentation/latest/checkstate
When the check is OK
The result in json: {"result...### Concerned version
Version: %2.0.5
Platform: Nginx
### Summary
We use CheckState as a check in our centreon(monitoring).
https://lemonldap-ng.org/documentation/latest/checkstate
When the check is OK
The result in json: {"result":1}
When the test user fail, we receive a 500 error page with the error message:
![image](/uploads/7d6a414fab877e1b8477b806944491c1/image.png)
That generate an unknown state in our monitoring system because he expect a json return with state 200
The expected result should be something like:
{"result":0 , "message":"Bad result during auth 5"}
### Logs
```
Set here the logs using debug mode if possible. Attach it as file if it's too big
```
### Backends used
REST / MONGODB REPLICA CLUSTER
### Possible fixesIn discussionhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1920Use Password::Base in MailPasswordReset plugin2019-09-05T13:27:41ZClément OUDOTUse Password::Base in MailPasswordReset plugin`Plugin::MailPasswordReset` module and `Password::Base` module are both inheriting of `Lemonldap::NG::Portal::Main::Plugin`.
The code to change password in `Plugin::MailPasswordReset` is not using the verifications done in `Password::Ba...`Plugin::MailPasswordReset` module and `Password::Base` module are both inheriting of `Lemonldap::NG::Portal::Main::Plugin`.
The code to change password in `Plugin::MailPasswordReset` is not using the verifications done in `Password::Base`, there should be a cleaner way to let all password changing code only in `Password::Base` module.3.0.0https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1911Use Rest2F to allow user to change his password2019-11-21T17:10:30ZMathieu Lecompte-melançonUse Rest2F to allow user to change his password### Summary
Allow password change using the configured Rest2F
### Design proposition
An option in manager to allow usage of 2F in password change
If user password is expired or will expire, call Rest2F
If Rest2F succeed
ask user fo...### Summary
Allow password change using the configured Rest2F
### Design proposition
An option in manager to allow usage of 2F in password change
If user password is expired or will expire, call Rest2F
If Rest2F succeed
ask user for new password and call the configured database change (ex: (authrest -password)) in the last process: "Password change URL" to complete the changing password process3.0.0https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1895OIDC error code & RFC67502020-09-29T15:28:08ZAlexandre LINTEOIDC error code & RFC6750### Concerned version
Version: 2.0.5
Platform: Nginx
### Summary
Error code returned by token endpoint are not according to RFC6750
### Logs
All the use cases bellow return (try on /oauth2/userinfo endpoint):
HTTP 401 Unauthorize...### Concerned version
Version: 2.0.5
Platform: Nginx
### Summary
Error code returned by token endpoint are not according to RFC6750
### Logs
All the use cases bellow return (try on /oauth2/userinfo endpoint):
HTTP 401 Unauthorized
WWW-Authenticate: error=invalid_request, error_description=Access token not found in request
1/ Authorization header absent
2/ Authorization header without AT
3/ Authorization header with invalid token
4/ Authorization header with expired token
5/ Authorization header with revoked consents (and session closed on WebUI cf https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1894 => if session not closed on webui with revocated consent the response is 200 OK).
6/ Use of a wrong verb (PUT, DELETE, OPTIONS, HEAD), it should normally returned a HTTP 405 Method Not Allowed.
### Backends used
file
### Possible fixes
Follow RFC error code : https://tools.ietf.org/html/rfc6750#section-3.1
When a request fails, the resource server responds using the
appropriate HTTP status code (typically, 400, 401, 403, or 405) and
includes one of the following error codes in the response:
invalid_request
The request is missing a required parameter, includes an
unsupported parameter or parameter value, repeats the same
parameter, uses more than one method for including an access
token, or is otherwise malformed. The resource server SHOULD
respond with the HTTP 400 (Bad Request) status code.
invalid_token
The access token provided is expired, revoked, malformed, or
invalid for other reasons. The resource SHOULD respond with
the HTTP 401 (Unauthorized) status code. The client MAY
request a new access token and retry the protected resource
request.
insufficient_scope
The request requires higher privileges than provided by the
access token. The resource server SHOULD respond with the HTTP
403 (Forbidden) status code and MAY include the "scope"
attribute with the scope necessary to access the protected
resource.
If the request lacks any authentication information (e.g., the client
was unaware that authentication is necessary or attempted using an
unsupported authentication method), the resource server SHOULD NOT
include an error code or other error information.3.0.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1894AT and consents revocation2019-11-21T11:20:24ZAlexandre LINTEAT and consents revocation### Concerned version
Version: 2.0.5
Platform: Nginx
### Summary
OIDC Access Token still be usable when the user revoked its consents.
### Logs
No logs available but you can reproduce the use case :
1/ Get an authorization code wi...### Concerned version
Version: 2.0.5
Platform: Nginx
### Summary
OIDC Access Token still be usable when the user revoked its consents.
### Logs
No logs available but you can reproduce the use case :
1/ Get an authorization code with oauth2/authorize endpoint (give your consents)
2/ Then request an access_token and id_token through oauth2/token endpoint
3/ Connect to the lemonldap Webui and revoke your consents
4/ You can still use the access_token of point 2 to request oauth2/getuserinfo endpoint even if you revoke your consents
### Backends used
file backend
### Possible fixes
Delete access_token when consents are revokedIn discussionMaxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1859No default value lookup for OIDC/SAML providers2019-11-20T17:19:09ZMaxime BessonNo default value lookup for OIDC/SAML providers### Concerned version
Version: %2.0
### Summary
When creating a OIDC rp or a SAML sp from the CLI (lemonldap-ng-cli), most metadata options are not set (oidcRPMetaDataOptionsIDTokenSignAlg, oidcRPMetaDataOptionsIDTokenExpiration...)
...### Concerned version
Version: %2.0
### Summary
When creating a OIDC rp or a SAML sp from the CLI (lemonldap-ng-cli), most metadata options are not set (oidcRPMetaDataOptionsIDTokenSignAlg, oidcRPMetaDataOptionsIDTokenExpiration...)
Instead of using default ciphers and duration, the portal code sets null values, leading to errors
### Possible fixes
We should probably add subkey default values in ::Common::Conf:DefaultValues and use them in the issuer code when provider options are undefined.3.0.0https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1855Not sure if this is bug or or just my configuration missed thing2019-10-09T16:36:59ZMichal LisNot sure if this is bug or or just my configuration missed thing### Concerned version
Version:
lemonldap-ng-manager-2.0.5-2.el7.noarch
lemonldap-ng-2.0.5-2.el7.noarch
lemonldap-ng-doc-2.0.5-2.el7.noarch
lemonldap-ng-test-2.0.5-2.el7.noarch
lemonldap-ng-conf-2.0.5-2.el7.noarch
lemonldap-ng-portal-2....### Concerned version
Version:
lemonldap-ng-manager-2.0.5-2.el7.noarch
lemonldap-ng-2.0.5-2.el7.noarch
lemonldap-ng-doc-2.0.5-2.el7.noarch
lemonldap-ng-test-2.0.5-2.el7.noarch
lemonldap-ng-conf-2.0.5-2.el7.noarch
lemonldap-ng-portal-2.0.5-2.el7.noarch
lemonldap-ng-handler-2.0.5-2.el7.noarch
Platform: Apache
### Logs
```
auth.my.domian:80 192.168.10.107 - - [14/Jul/2019:07:49:22 +0200] "GET /?url=aHR0cDovL21hbmFnZXIubWxpcy5vbmUucGwv HTTP/1.1" 500 706
```
Hi just want to share my experience with installation procedure for CentOS/RHEL.
After going trough this (with version 2.0 as recommended) I was stuck for a while with 500 error on the manager site(redirected to auth )
I have got
"Unable to protect this server"
After commenting out lines 25:30 in Lemonldap/NG/Handler/Lib/PSGI.pm I go futher with errors
I was getting second error, which was pretty easy to resolve "yum install perl-String-Random.noarch"
That was missed (but I think it should be added to dependency in RPMs if is required)
My question is what is reason and or consequence of getting:
"Unable to protect this server"
I am testing this in isolated VM environment so I am not scary ;)
### Backends used
For any bug on configuration/sessions storage, give us details on backends
### Possible fixesIn discussionhttps://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 Besson