lemonldap-ng issueshttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues2021-06-28T12:36:30Zhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2419Support JWT as OAuth 2.0 Bearer Access Tokens2021-06-28T12:36:30Zandy tanSupport JWT as OAuth 2.0 Bearer Access Tokens### Summary
We would like to use jwt access_token instead of opaque access_token.
With standard opaque bearer access tokens, the API Server needs to introspect the access tokens with the OAuth 2.0 authorization server by invoking its i...### Summary
We would like to use jwt access_token instead of opaque access_token.
With standard opaque bearer access tokens, the API Server needs to introspect the access tokens with the OAuth 2.0 authorization server by invoking its introspection endpoint
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-112.0.12Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3109Conf test: should warn when auth is Choice and userDB isn't set to Choice or ...2024-03-27T10:54:34ZYaddConf test: should warn when auth is Choice and userDB isn't set to Choice or SameNot an error but often a mistakeNot an error but often a mistake2.19.0YaddYaddhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3088Extend session lifetime when refreshing session/access token2024-01-27T19:11:12ZMaxime BessonExtend session lifetime when refreshing session/access tokenRelated to #2700
Currently, when the user obtains a new access token for a RP using a refresh token, the session is not extended (timeoutActivity/_lastSeen)
This action should be considered as session activity and thus extend the sess...Related to #2700
Currently, when the user obtains a new access token for a RP using a refresh token, the session is not extended (timeoutActivity/_lastSeen)
This action should be considered as session activity and thus extend the session duration
Maybe this should also be the case when sessions are refreshed by the Refresh session API plugin ?
OK for you @guimard / @clement_oudot ?2.19.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3054Cannot get the full otpauth URL when registering a new TOTP2024-03-27T09:19:28ZSoisik FrogerCannot get the full otpauth URL when registering a new TOTPAs 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.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2815Simplify OIDC claims configuration2023-04-06T15:21:41ZMaxime BessonSimplify OIDC claims configuration### Summary
In order to successfully transmit a simple claim (email, login, full name) to an OIDC application, an LLNG admin must:
* Be aware that OIDC claims have standard names (`email`, `preferred_username`, `name`)
* Map those stand...### Summary
In order to successfully transmit a simple claim (email, login, full name) to an OIDC application, an LLNG admin must:
* Be aware that OIDC claims have standard names (`email`, `preferred_username`, `name`)
* Map those standard names to LLNG variables in "Exported Attributes"
* Be aware that standard OIDC claims are released through standard scopes (profile, address...)
* Configure the client application to request those standard scopes
If they try to transmit a claim without using a standard name, or transmit a non-standard claim (groups, or any kind of custom attribute), they must:
* Map those non standard claims to LLNG variables in "Exported Attributes"
* Be aware that LLNG will only release claims declared in a scope UNLESS they are standard claims
* Create a scope value to encompass some, or all, of those claims in "Scope values content"
* Configure their application to request the new scope values, or use a scope rule to force it
This is VERY complicated to say the least, it trips many (if not all) or our users. They end up doing weird configurations in "Scope values content" such as one scope per attribute, or overriding the `profile` scope with new attributes, if they can make it work at all.
Our SAML configuration is MUCH simpler:
* Declare SAML attribute in "Exported attributes"
* That's all, the attribute will be sent to the application
### Design proposition
We need to simplify this.
My proposal:
* Declare OIDC claims in "Exported attributes"
* That's all, the claim will be sent to the application
#### For people who want to do complicated things
Some people might want to handle scopes, so we can still leave the "Scope value content" configuration in the product, but hide it in a sub-menu, and add a new option that keeps the old behavior, named "Only release claims if allowed by a scope" (enabled on existing installs, disabled on new installs).
### Discuss
Any objections ?2.0.16Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2780New lemonldap-ng-cli subcommand: merge2022-08-24T12:11:35ZMaxime BessonNew lemonldap-ng-cli subcommand: merge### Summary
I propose adding a new command in `lemonldap-ng-cli` to do batch config modifications, very useful when adding complex configuration objects such as applications, or when installing a new instance
### Design proposition
``...### Summary
I propose adding a new command in `lemonldap-ng-cli` to do batch config modifications, very useful when adding complex configuration objects such as applications, or when installing a new instance
### Design proposition
```
lemonldap-ng-cli merge myapp1.yaml [can specify more than one file, json/yaml is allowed]
```
`myapp1.yaml`:
```
# Comments are allowed in YAML!
samlSPMetaDataExportedAttributes:
newsp:
myattr: "0;myattr"
samlSPMetaDataOptions:
newsp:
samlSPMetaDataOptionsCheckSLOMessageSignature: 0
samlSPMetaDataOptionsCheckSSOMessageSignature: 0
samlSPMetaDataOptionsEnableIDPInitiatedURL: 0
samlSPMetaDataOptionsEncryptionMode: none
samlSPMetaDataOptionsForceUTF8: 1
samlSPMetaDataOptionsNotOnOrAfterTimeout: 72000
samlSPMetaDataOptionsOneTimeUse: 0
samlSPMetaDataOptionsSessionNotOnOrAfterTimeout: 72000
samlSPMetaDataOptionsSignSLOMessage: -1
samlSPMetaDataOptionsSignSSOMessage: -1
samlSPMetaDataOptionsSignatureMethod: ""
samlSPMetaDataXML:
newsp:
samlSPMetaDataXML:|
<md:EntityDescriptor
... metadata here ...
</md:EntityDescriptor>
# Add application to menu
applicationList:
mycategory:
newapp:
options:
description: "My new application"
display: auto
logo: app.png
name: "My new application"
uri: "https://test3.example.com/"
order: 1
type: application
```
I use [Hash::Merge::Simple](https://metacpan.org/pod/Hash::Merge::Simple) to combine input files with existing configuration2.0.15Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2756Allow customization of portal JS code with jQuery events2022-06-16T14:32:42ZMaxime BessonAllow customization of portal JS code with jQuery events### Summary
I sometimes need to add custom JS code to the portal. A typical example is doing something after a TOTP registration.
Currently, I have to modify `totpregistration.js` to do so. But this makes maintenance difficult.
I thin...### Summary
I sometimes need to add custom JS code to the portal. A typical example is doing something after a TOTP registration.
Currently, I have to modify `totpregistration.js` to do so. But this makes maintenance difficult.
I think the JS files provided by the portal should trigger events in some situations, and these events can be caught by custom code
### Design proposition
Example in totpregistration.js
```coffee
# Right after the AJAX call to register the TOTP device:
success: (data) ->
if data.error
if data.error.match /bad(Code|Name)/
setMsg data.error, 'warning'
else
setMsg data.error, 'danger'
else
# Trigger a mfaAdded event
$(document).trigger "mfaAdded", [ { "type": "totp" } ]
setMsg 'yourKeyIsRegistered', 'success'
```
And now, in your skin's custom JS file:
```js
$(document).on( "mfaAdded", { }, function( event, info ) {
console.log( "Added a new " + info.type + "MFA" );
// Your code here: info popup, redirection, etc.
});
```2.0.15Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2720importMetadata should be configurable2022-07-21T13:59:10ZMaxime BessonimportMetadata should be configurable### Summary
Every install that uses Renater or some other large federation needs to do some fine-tuning on certain SP/IDPs
Our doc currently states:
```
For Renater, you need to customize some settings of the script, copy it and edit ...### Summary
Every install that uses Renater or some other large federation needs to do some fine-tuning on certain SP/IDPs
Our doc currently states:
```
For Renater, you need to customize some settings of the script, copy it and edit configuration
```
Instead, the script should use a configuration file to customize services
### Design proposition
Example:
```
# Default exported attributes for IDPs
[exportedAttributes]
cn=0;cn
eduPersonPrincipalName=0;eduPersonPrincipalName
...
# Default options for SPs
[defaultSpOptions]
CheckSLOMessageSignature=1
...
# Specific SP config
[sp:https://test-sp.federation.renater.fr]
attribute_required=0
attribute_required_uid=1
NameIDFormat=persistent
```2.0.15Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2657Hidden attributes, custom functions and plugins declarations are inconsistent2021-11-23T16:35:22ZChristophe Maudouxchrmdx@gmail.comHidden attributes, custom functions and plugins declarations are inconsistent### Concerned version
Version: %2.0.X
Platform: All
### Summary
Custom functions and hidden attributes are declared by using a space separated list like this "Custom::Function1 Custom::Function2 Custom::Function3" or "_password sessi...### Concerned version
Version: %2.0.X
Platform: All
### Summary
Custom functions and hidden attributes are declared by using a space separated list like this "Custom::Function1 Custom::Function2 Custom::Function3" or "_password session_id".
Custom plugins are declared by using a comma separated list like this "Plugin::One, Plugin::Two, Plugin::Three".
### Possible fixes
To be more consistent, we could use the same regex like "split /[,\s]+/, ..." to avoid regression.2.0.14Christophe Maudouxchrmdx@gmail.comChristophe Maudouxchrmdx@gmail.comhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2415Append a field to set a comment for each IdP or SP2022-12-13T14:30:46ZChristophe Maudouxchrmdx@gmail.comAppend a field to set a comment for each IdP or SP### Summary
A comment can be useful to track or explain why a provider has been appended.
### Design proposition
A long text input to set a comment.### Summary
A comment can be useful to track or explain why a provider has been appended.
### Design proposition
A long text input to set a comment.2.0.16Christophe Maudouxchrmdx@gmail.comChristophe Maudouxchrmdx@gmail.comhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2381Append a hook to be able to overwrite access log2021-03-26T21:15:51ZChristophe Maudouxchrmdx@gmail.comAppend a hook to be able to overwrite access log### Summary
Access are logged by using whatToTrace or customToTrace.
whatToTrace and customToTrace are static values because they are computed at log in process.
The aim here is to be able to log a dynamic value that can be different de...### Summary
Access are logged by using whatToTrace or customToTrace.
whatToTrace and customToTrace are static values because they are computed at log in process.
The aim here is to be able to log a dynamic value that can be different depending on the virtualHost like the group or profile used by the user to match the access rule.
### Design proposition
Append a hook to overwrite customToTrace by using a custom function.2.0.10Christophe Maudouxchrmdx@gmail.comChristophe Maudouxchrmdx@gmail.comhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2372Add a domain whitelist to Auth::Kerberos2020-11-09T08:55:03ZMaxime BessonAdd a domain whitelist to Auth::Kerberos### Summary
* When using Kerberos to authenticate users from multiple domains we use a combination rule like this:
```
[Kerberos, AD1] or [Kerberos, AD2] or [Kerberos, AD3]
```
But the ordering of the rule means that a user@DOMAIN2 wi...### Summary
* When using Kerberos to authenticate users from multiple domains we use a combination rule like this:
```
[Kerberos, AD1] or [Kerberos, AD2] or [Kerberos, AD3]
```
But the ordering of the rule means that a user@DOMAIN2 will be authenticated as user@DOMAIN1 if there is a user with the same name in DOMAIN1.
### Design proposition
I would like to add a krbAllowedDomains parameter to the Kerberos Auth module, so that the rule can be rewritten like this:
```
[Kerberos1, AD1] or [Kerberos2, AD2] or [Kerberos3, AD3]
```
Kerberos1, Kerberos2, Kerberos3, will have overloaded krbAllowedDomains, so that a Kerberos domain can be precisely matched to its home LDAP server.2.0.10Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2330Allow to configure OIDC claims type2020-12-22T10:01:04ZClément OUDOTAllow to configure OIDC claims typeOIDC claims can be a string, number, boolean. We should be able to force the claim type in our JSON export (in ID token or in UserInfo response).
This could be done by adding the type to the OIDC exported attributes configuration, with ...OIDC claims can be a string, number, boolean. We should be able to force the claim type in our JSON export (in ID token or in UserInfo response).
This could be done by adding the type to the OIDC exported attributes configuration, with the same format as we do for SAML attributes. If no type is configured (current confg format), string should be the default.2.0.10Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2295Erroneous use of NTLM should be explicitely reported to the user2020-08-25T18:04:22ZMaxime BessonErroneous use of NTLM should be explicitely reported to the userAs seen in #2294 , misconfiguration of Windows clients are likely to lead to NTLM being attempted against LLNG when Kerberos auth is used.
The current error message might lead users to believe there is an issue with the server-side of t...As seen in #2294 , misconfiguration of Windows clients are likely to lead to NTLM being attempted against LLNG when Kerberos auth is used.
The current error message might lead users to believe there is an issue with the server-side of things. We need a more explicit error message.
NTLM tickets are easy enough to spot:
```
00000000 4e 54 4c 4d 53 53 50 00 01 00 00 00 97 82 08 e2 |NTLMSSP.........|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 0a 00 ba 47 00 00 00 0f |...G....|
00000028
```2.0.9Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2214add option to make convertConfig easier in most cases2020-07-13T14:56:41ZMaxime Bessonadd option to make convertConfig easier in most cases### Summary
When setting up a new LLNG instance, users would typically
* edit lemonldap-ng.ini to change their config backend
* discover that convertConfig needs the original lemonldap-ng.ini
* copy lemonldap-ng.ini to oldlemonldap-ng....### Summary
When setting up a new LLNG instance, users would typically
* edit lemonldap-ng.ini to change their config backend
* discover that convertConfig needs the original lemonldap-ng.ini
* copy lemonldap-ng.ini to oldlemonldap-ng.ini and revert it to the file storage
* run convertConfig, possibly mixing up --current and --new because --current is supposed to be the oldlemonldap-ng.init
Long story short, this whole process is needlessly complicated and error prone.
Not all users change configuration backend once they have migrated to DB/LDAP, but ALL users have to go to the process of converting their config when setting up LLNG for the first time.
### Design proposition
Several possibilities:
* When started without any arguments, convertConfig could convert the default conf storage (/var/lib/lemonldap-ng/conf) to what is currently in lemonldap-ng.ini. User would be prompted for confirmation to avoid accidental use.
* Or perhaps add a new option to explicitely trigger this same behavior: ``convertConfig --default``
* Or simply a flag to select the default conf backend: ``convertConfig --from-default --new /etc/lemonldap-ng/lemonldap-ng.ini``
The same could be done with convertSessions too2.0.9Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2042Add per-service macros2020-02-05T14:49:27ZMaxime BessonAdd per-service macros### Summary
Some of our users have a large amount of oidc/saml/cas services, and might need different macros.
For instance: isAdmin might be calculated very differently from one service to another.
Currently, we need to define isAdmin...### Summary
Some of our users have a large amount of oidc/saml/cas services, and might need different macros.
For instance: isAdmin might be calculated very differently from one service to another.
Currently, we need to define isAdmin_service1, isAdmin_service2 etc in global macros.
This slows down session creation, and may lead to sessions with hundreds of attributes.
### Design proposition
I have implemented per-service macros, available for CAS, SAML and OIDC. This system allows the creation of macros that are only evaluated when a particular SP/RP/Cas APP is accessed. These macros are added to the session, and must be released through CAS Attributes, SAML Attributes or OIDC claims, like any other session variable.2.0.7Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1835[Security:improvement] Do not accept a "none" signature in JWT if we enforce ...2019-09-17T18:43:57ZClément OUDOT[Security:improvement] Do not accept a "none" signature in JWT if we enforce signature verificationThis issue is an open question.
Today, in `verifyJWTSignature`, we accept a JWT with `none` algorithm, as this is a valid algorithm:
```perl
if ( $alg eq "none" ) {
# If none alg, signature should be empty
if ( $jwt...This issue is an open question.
Today, in `verifyJWTSignature`, we accept a JWT with `none` algorithm, as this is a valid algorithm:
```perl
if ( $alg eq "none" ) {
# If none alg, signature should be empty
if ( $jwt_parts->[2] ) {
$self->logger->debug( "Signature "
. $jwt_parts->[2]
. " is present but algorithm is 'none'" );
return 0;
}
return 1;
}
```
But if there is no signature, I think we should not accept this JWT. If an admin need to allow `none`, it means he does not want to verify signature.
From a security point of view, an attacker can modify a JWT to remove signature and change `alg` to `none`. In this case, our verification method will not detect the attack. It is not very risky in LL::NG, as the ID Token is not used as cookie value, so the attacker needs to inject the hacked ID Token between LL::NG RP and the OpenID Connect provider.
From my point of view, we should change the behavior of our verification method to refuse the `none` algorithm. What do you think?2.0.6Clément OUDOTClément OUDOThttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1781Impersonation does not work with 2FA2019-06-01T21:26:44ZMaxime BessonImpersonation does not work with 2FA### Concerned version
Version: %2.0.4
Platform: Nginx + Debian
### Summary
On a clean install
* Enable Impersonation (rules and identity rules don't matter much)
* Enable mail or external 2FA
* Go to portal
No impersonation:
* Lo...### Concerned version
Version: %2.0.4
Platform: Nginx + Debian
### Summary
On a clean install
* Enable Impersonation (rules and identity rules don't matter much)
* Enable mail or external 2FA
* Go to portal
No impersonation:
* Login with dwho/dwho
* Enter 2F code
* The portal displays a login error
* Browse to the portal again
* You are logged in (if 2F code was valid)
With impersonation:
* Logout and try to login as dwho/dwho impersonating rtyler
* Same error behavior, and you end up getting logged in as "dwho"
### Logs
```
LLNG[18172]: Session granted for dwho by Demo (10.128.239.1)
LLNG[18172]: Processing code ref
LLNG[18172]: Launching ::Plugins::Impersonation::run
LLNG[18172]: No impersonation required
LLNG[18172]: Malformed spoofed Id
LLNG[18172]: Impersonation tried with spoofed Id:
LLNG[18172]: Rename real attributes...
... [ attribute related logs ] ...
LLNG[18172]: Processing getUser
LLNG[18172]: Prepare token
LLNG[18172]: Token 1559065148_-20052 created
LLNG[18172]: Returned error: 5
LLNG[18172]: Impersonation requested for an unvalid user ()
LLNG[18172]: Process returned error: 5
```
### Possible fixes
I think this happens because of
```
my $spoofId = $req->param('spoofId') || $req->{user};
```
When doing the 2F code verification, the request only contains the 2F code and a token used to preserve login information. So obviously `$req->param('spoofId')` no longer exists. And apparently `$req->{user}` does not exist yet either, maybe the impersonation plugin triggers too early during the flow?
Either way, we'll need to store the *spoofId* inside the 2F token so that we can preserve it during the login flow.
That being said, I think that the impersonation feature should not be presented to users on the login form. What about kerberos users? It should perhaps be presented at the very end of the login process, and only on users who are authorized to use it. That way, regular users will never know it's there. I'm pretty sure some day this feature will be used for real, and not just for dev/testing.In discussionChristophe Maudouxchrmdx@gmail.comChristophe Maudouxchrmdx@gmail.comhttps://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/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 Pai