Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: OpenID Connect authentication #22740

Open
jeritiana opened this issue Nov 3, 2022 · 36 comments
Open

Feature Request: OpenID Connect authentication #22740

jeritiana opened this issue Nov 3, 2022 · 36 comments
Labels
Feature request This is a feature request

Comments

@jeritiana
Copy link
Contributor

jeritiana commented Nov 3, 2022

There is already an "OpenID" support in Dolibarr, but it is actually OpenID version 2.0 (with the use of Yadis, XRDS document and such) and it is not well documented.

The "OpenID" protocol in today's world rather means OpenID Connect (third generation of OpenID), supported by Auth0, Keycloak, Google etc. Read here: https://openid.net/connect/.

This is a very simple implementation of the OpenID Connect Authorization flow (w/o PKCE) for Dolibarr. Read here: https://developer.okta.com/docs/guides/implement-grant-type/authcode/main/#grant-type-flow

This implementation focuses on providing the authentication with zero modification on the Dolibarr codebase. The integration only consists of copy-pasting a new file + application configuration, before going further.

Coming along with PR #22741. If you want to try, see how to sections below.

Use case

Leverage federated identity which is the way to go. Whether to use SAML vs OpenID #6600 is another story. In the meantime, Dolibarr may support both and it should be up to the end user to choose depending on his constraints.

How to use: OpenID Server requirements

OpenID Server configuration

  1. Check that grant type Authorization code is enabled.
  2. Allowed callback URLs: https://dolibarr.domain.com
  3. Allowed logout URLs: https://dolibarr.domain.com

A local URL like http://localhost:1234 can also be used for testing.

Note about Dolibarr user login

On the OpenID user profiles, there must be a claim (= user attribute) matching the Dolibarr user login, otherwise Dolibarr will say that the user could not be found in its database. Use this claim in MAIN_AUTHENTICATION_OIDC_LOGIN_CLAIM.

E.g.:
Bob used to log in into Dolibarr with login bob42 and password ********.
With OpenID Connect, Bob now uses his OpenID credentials to log in, for e.g. e-mail bob@domain.com and password **********. But Dolibarr still expects Bob's internal login bob42 to recognize him for authentication, his user permissions etc. We must then be able to retrieve this login from Bob's profile on the Identity Provider.

If this login cannot be retrieved from the Identity Provider for some reason, the Dolibarr database must be edited and all user logins have to be updated to an existing claim on the OpenID profile (e.g.: email, or nickname). Hint: in the Dolibarr database, see table llx_user, column login.

How to use: Dolibarr configuration

On the Dolibarr host

  1. Configure the authentication methods in conf.php (/var/www/html/conf/conf.php) and add openid_connect.
    For e.g.:
$dolibarr_main_authentication='openid_connect,dolibarr'
  1. Copy/paste the file functions_openid_connect.php from NEW #22740 Add OpenID Connect impl #22741 in the core/login directory.
    We then have /var/www/html/core/login/functions_openid_connect.php.

For Docker environments, the file can be mounted as a volume: -v $PWD/functions_openid_connect.php:/var/www/html/core/login/functions_openid_connect.php:ro.

Composing MAIN_AUTHENTICATION_OPENID_URL

This is the main OpenID Connect authentication URL, which allows the user to log in and then be redirected back to Dolibarr. It makes use of some already existing OpenID 2.0 features.

  1. Retrieve the /authorize endpoint. The value depends on the used Identity Provider.
    E.g.: https://tenant.us.auth0.com/authorize

  2. Build the URL parameters

Param name Description Example
client_id Application client ID My-Super-Awesome-Client-ID-1234
redirect_uri Dolibarr URL followed by /?openid_mode=true, then URL encoded. Must be authorized as callback URL Before URL encoding: https://dolibarr.domain.com/?openid_mode=true - After URL encoding: https%3A%2F%2Fdolibarr.domain.com%2F%3Fopenid_mode%3Dtrue
scope OpenID scope of required user info openid profile email
response_type OAuth flow name, here we use code for the Authorization Code flow code
  1. The final MAIN_AUTHENTICATION_OPENID_URL content should be like:
https://tenant.us.auth0.com/authorize?client_id=My-Super-Awesome-Client-ID-1234&redirect_uri=https%3A%2F%2Fdolibarr.domain.com%2F%3Fopenid_mode%3Dtrue&scope=openid profile email&response_type=code

Composing MAIN_LOGOUT_GOTO_URL

  1. Retrieve the /logout endpoint. The value depends on the used Identity Provider.
    E.g.: https://tenant.us.auth0.com/v2/logout

  2. Build the URL parameters

Param name Description Example
client_id Application client ID My-Super-Awesome-Client-ID-1234
returnTo URL to be redirected to after logout. Use Dolibarr URL. Must be authorized as logout URL https://dolibar.domain.com
  1. The final MAIN_LOGOUT_GOTO_URL content should be like:
https://tenant.us.auth0.com/v2/logout?client_id=My-Super-Awesome-Client-ID-1234&returnTo=https://dolibar.domain.com

Dolibarr application setup

The final configuration step is to create the following values in Home > Setup > Other Setup.

Name Example Comment Description
MAIN_AUTHENTICATION_OPENID_URL See above OpenID Connect URL Composed OpenID Connect URL
MAIN_LOGOUT_GOTO_URL See above Identity Provider logout URL Composed IdP logout URL
MAIN_AUTHENTICATION_OIDC_CLIENT_ID My-Super-Awesome-Client-ID-1234 OpenID Connect Client ID Application client ID
MAIN_AUTHENTICATION_OIDC_CLIENT_SECRET My-Very-Hidden-Client-Secret-1234 OpenID Connect Client Secret Application client secret
MAIN_AUTHENTICATION_OIDC_TOKEN_URL https://tenant.us.auth0.com/oauth/token OpenID Connect token URL /token endpoint
MAIN_AUTHENTICATION_OIDC_USERINFO_URL https://tenant.us.auth0.com/userinfo OpenID Connect userinfo URL /userinfo endpoint
MAIN_AUTHENTICATION_OIDC_REDIRECT_URL https://dolibarr.domain.com/?openid_mode=true OpenID Connect redirect URL Dolibarr URL followed by /?openid_mode=true
MAIN_AUTHENTICATION_OIDC_LOGIN_CLAIM email OpenID Connect login claim OpenID Connect claim matching the Dolibarr user login. If not set or empty, defaults to email

Limitations

  • Only authentication with OpenID is implemented i.e. check that username:password are valid. This does not provision Dolibarr users based on OpendID data like you would find in other applications, as user creation and authentication are handled separately in Dolibarr.
    So, users must first be created with the Dolibarr UI before they can login using OpenID credentials. This is also the case for LDAP authentication for example.
    Read more about user login handling in the OpenID Server requirements above.

  • Error messages are in English, there is no internationalization because that would require modification on the Dolibarr codebase.

  • Multicompany mode is not supported (I don't have any use case for it nor means for testing).

Notes for maintainers

The following are current considerations that any Dolibarr developper can change or contribute to.

Code

This implementation has no footprint on the Dolibarr codebase. Why? Because it is easier to maintain and contribute to, until (and if) it is merged officially into the Dolibarr repository.

I tried very much to use already existing Dolibarr functions like GETPOST, getURLContent etc. based on what I could find in the other auth methods. This also allows not to rely on third-party libraries (e.g. /~https://github.com/jumbojett/OpenID-Connect-PHP) because that would require adding new includes.

Naming

The name openid_connect is chosen carefully from what is already implemented in Dolibarr.

In login.tpl.php:
preg_match('/openid/') will match openid_connect, which allows us to display and use MAIN_AUTHENTICATION_OPENID_URL on the login page (implemented with OpenID 2.0 support).

return_uri in MAIN_AUTHENTICATION_OPENID_URL

The return_uri parameter is built specifically to include openid_mode=something. Here we used openid_mode=true.

This is because of main.inc.php:

if (GETPOST('openid_mode', 'alpha', 1)) {
    $goontestloop = true;
}

Using this technique, we can leverage the login page as the OpenID callback URL, then trigger the Dolibarr standard login pipeline which calls our new function.

MAIN_LOGOUT_GOTO_URL

This is an already existing feature from logout.php.

We can then make use of this hook to remove the session on the Identity Provider. If this is not done, the OpenID session would remain valid and clicking the MAIN_AUTHENTICATION_OPENID_URL on the login page would immediately authenticate the user without asking for credentials.

Configuration

The specific configuration variables (MAIN_AUTHENTICATION_OIDC_CLIENT_ID, CLIENT_SECRET etc.) have been added from the UI because this is the way it is done for the used built-in variables, as MAIN_AUTHENTICATION_OPENID_URL and MAIN_LOGOUT_GOTO_URL are already configured from the UI. It is practical to access all configuration variables on a single area.

Otherwise, they may have been provided in and retrieved from conf.php, something like $dolibarr_main_auth_oidc_client_id=.

Other implementations

I found there is another recent OpenID Connect support for Dolibarr here: #21333 but I am not sure of its intended scope.

@hregis
Copy link
Contributor

hregis commented Nov 3, 2022

@jeritiana wouhououou... And you have a bug?

@jeritiana
Copy link
Contributor Author

jeritiana commented Nov 4, 2022

@hregis I did not see any bug on the implementation when I tested with Auth0. Now, for sure it would be great if more people could try with different providers.

@ksar-ksar ksar-ksar added the Feature request This is a feature request label Nov 4, 2022
@battosai30
Copy link
Contributor

battosai30 commented Nov 16, 2022

Hi, I made some suggestions on core/login/functions_openid_connect.php, it was simply not working for me as it.

I now have a problem : when I log in using openid, it's just like CSS is not loading :

image

Standard login for the same user is ok.

EDIT : I checked, HTML source codes generated are exactly the same. I just don't get it how it simply happens :s
EDIT 2 : I found something. Checkin security events, I found a difference :

With direct login :

image

With Oidc :

image

The question is now : why Oidc leads to "TZ=;TZString=;Screen=x"

@AisukoHakumei
Copy link
Contributor

AisukoHakumei commented Nov 24, 2022

It appears that thoses variables are set here :

dolibarr/htdocs/main.inc.php

Lines 1030 to 1048 in 2e57cb1

// Is it a new session that has started ?
// If we are here, this means authentication was successfull.
if (!isset($_SESSION["dol_login"])) {
// New session for this login has started.
$error = 0;
// Store value into session (values always stored)
$_SESSION["dol_login"] = $user->login;
$_SESSION["dol_authmode"] = isset($dol_authmode) ? $dol_authmode : '';
$_SESSION["dol_tz"] = isset($dol_tz) ? $dol_tz : '';
$_SESSION["dol_tz_string"] = isset($dol_tz_string) ? $dol_tz_string : '';
$_SESSION["dol_dst"] = isset($dol_dst) ? $dol_dst : '';
$_SESSION["dol_dst_observed"] = isset($dol_dst_observed) ? $dol_dst_observed : '';
$_SESSION["dol_dst_first"] = isset($dol_dst_first) ? $dol_dst_first : '';
$_SESSION["dol_dst_second"] = isset($dol_dst_second) ? $dol_dst_second : '';
$_SESSION["dol_screenwidth"] = isset($dol_screenwidth) ? $dol_screenwidth : '';
$_SESSION["dol_screenheight"] = isset($dol_screenheight) ? $dol_screenheight : '';
$_SESSION["dol_company"] = getDolGlobalString("MAIN_INFO_SOCIETE_NOM");
$_SESSION["dol_entity"] = $conf->entity;

Maybe we could set some fallback entries ?
I haven't tried to set them manually in the code yet.

EDIT:
Apparently forcing those 4 variables in session did the trick
$_SESSION["dol_tz"] = '1';
$_SESSION["dol_tz_string"] = 'Europe/Paris';
$_SESSION["dol_screenwidth"] = '1740';
$_SESSION["dol_screenheight"] = '1080';

@battosai30
Copy link
Contributor

I think the problem comes from the fact that in "standard" login, it's the client who sends the login infos, so it's browser. In Oidc, the "final" response comes from the identity server : so no browser => no infos.

EDIT: Apparently forcing those 4 variables in session did the trick $_SESSION["dol_tz"] = '1'; $_SESSION["dol_tz_string"] = 'Europe/Paris'; $_SESSION["dol_screenwidth"] = '1740'; $_SESSION["dol_screenheight"] = '1080';

You directly put it in htdocs/core/login/functions_openid_connect.php ?

In case it's that we may be able to store browser info before doing Oidc stuff

@AisukoHakumei
Copy link
Contributor

AisukoHakumei commented Nov 25, 2022

I think the problem comes from the fact that in "standard" login, it's the client who sends the login infos, so it's browser. In Oidc, the "final" response comes from the identity server : so no browser => no infos.

Yep, you summed it pretty right !

You directly put it in htdocs/core/login/functions_openid_connect.php ?

No, I've mounted a copy of main.inc.php as a volume bind on my container and added those directely below (around line 1050) for testing.

volumes:
  - ...
  - /data/erp/test/main.inc.php:/var/www/html/main.inc.php

For the record, the values for the screen size are empirical and might mess with the mobile view.
This is not a good approach for production of course. I'm trying to find where else this could be implemented so that we do not need to touch the base code.

EDIT :

I think I got it working !
Notice how the GETPOST function is called here :

$dol_dst_observed = GETPOST("dst_observed", 'int', 3);
$dol_dst_first = GETPOST("dst_first", 'int', 3);
$dol_dst_second = GETPOST("dst_second", 'int', 3);
$dol_screenwidth = GETPOST("screenwidth", 'int', 3);
$dol_screenheight = GETPOST("screenheight", 'int', 3);
$dol_hide_topmenu = GETPOST('dol_hide_topmenu', 'int', 3);
$dol_hide_leftmenu = GETPOST('dol_hide_leftmenu', 'int', 3);
$dol_optimize_smallscreen = GETPOST('dol_optimize_smallscreen', 'int', 3);
$dol_no_mouse_hover = GETPOST('dol_no_mouse_hover', 'int', 3);
$dol_use_jmobile = GETPOST('dol_use_jmobile', 'int', 3); // 0=default, 1=to say we use app from a webview app, 2=to say we use app from a webview app and keep ajax

The third parameter (3) means that it will try to get the POST value THEN the GET value if the POST is not set.
So, we can fool the login flow into thinking that the GET params are set by modifying the redirect_url and adding the screen size
%3Dtrue%26screenwidth%3D1740%26screenheight%3D1080 for MAIN_AUTHENTICATION_OPENID_URL in the redirect_uri parameter.
And adding &screenwidth=1740&screenheight=1080 in MAIN_AUTHENTICATION_OIDC_REDIRECT_URL

I've tried it on my phone, it doesn't mess the layout so far so it might be a viable workaround without tinkering with the base code :)

@battosai30
Copy link
Contributor

Oh cool trick !
Can do better ? If we adjust dynamically the redirect uri (which is constructed when Dolibarr requests Token) we would, maybe, be able to get real variables from the login request, insert it in token request and get the good values.

@AisukoHakumei
Copy link
Contributor

I've though of it. Unfortunately, the link to perform the OIDC login is hardcoded here :

if (isset($conf->file->main_authentication) && preg_match('/openid/', $conf->file->main_authentication)) {
$langs->load("users");
//if (!empty($conf->global->MAIN_OPENIDURL_PERUSER)) $url=
echo '<br>';
echo '<div class="center" style="margin-top: 4px;">';
$url = $conf->global->MAIN_AUTHENTICATION_OPENID_URL;
if (!empty($url)) {
print '<a class="alogin" href="'.$url.'">'.$langs->trans("LoginUsingOpenID").'</a>';
} else {
$langs->load("errors");
print '<span class="warning">'.$langs->trans("ErrorOpenIDSetupNotComplete", 'MAIN_AUTHENTICATION_OPENID_URL').'</span>';
}
echo '</div>';
}

And the login flow fails if there is a mismatch between MAIN_AUTHENTICATION_OPENID_URL and MAIN_AUTHENTICATION_OIDC_REDIRECT_URL. At least, it happened when I did my tests... 😞

@battosai30
Copy link
Contributor

Humm not exactly : in htdocs/core/login/functions_openid_connect.php you find :

image

so you can still tweak it. The problem that could comes is you must have, on your identity server, an authorized redirect uri like https://example.com/* because the redirect will change with each user.

@AisukoHakumei
Copy link
Contributor

On this part, yes it's tweakable.
But how do you change the login url on the template ? Remember that the return_uri must be set on the login link as well as in the auth_param redirect_uri. If there is a mismatch, the login fails.

@Befisch
Copy link

Befisch commented Jan 17, 2023

Just wanted to let you know, that we implemented it using:

  • Keycloak 19.0.1

I used the code with ALL the changes @FlorentPoinsaut made. To work around this css Styling issue I used the recommended way of @AisukoHakumei .

Since our Keycloak Users are user@company.mail I included a small string check and used the substring infront of the mail to not have an "@" in the user name. Since dolibarr doesn't allow it, I didn't want to run in problems afterwards.

Here again the ENV-Variables I used:

Basevalues to create all necessary variables:

KEYCLOAK_OID_URL="https://yourkeycloak.company.com/realms/yourRealm/protocol/openid-connect/"
ERP_BASE_URL="https://erp.company.com/"
MAIN_AUTHENTICATION_OIDC_CLIENT_ID="company-erp" # created in Keycloak

Built from these basevalues:

MAIN_AUTHENTICATION_OIDC_TOKEN_URL=${KEYCLOAK_OID_URL}token
MAIN_AUTHENTICATION_OIDC_USERINFO_URL=${KEYCLOAK_OID_URL}userinfo
MAIN_AUTHENTICATION_OIDC_REDIRECT_URL=${ERP_BASE_URL}?openid_mode=true&screenwidth=1740&screenheight=1080
MAIN_AUTHENTICATION_OPENID_URL=${KEYCLOAK_OID_URL}auth?client_id=${MAIN_AUTHENTICATION_OIDC_CLIENT_ID}&redirect-uri=${MAIN_AUTHENTICATION_OIDC_REDIRECT_URL}&scope=openid profile email&response_type=code

Just remember to URL encode MAIN_AUTHENTICATION_OPENID_URL like in first comment.

MAIN_AUTHENTICATION_OIDC_CLIENT_SECRET="superSecretClientSecret" # from Keycloak

Very sincere thanks to all of you!

@fcharlaix-opendsi
Copy link
Contributor

This feature is awesome and work pretty well.

Since we don't want an unclean Dolibarr core, we have created a module only for functions_openid_connect.php.

Link to the public repo : openidconnect

eldy added a commit that referenced this issue Apr 13, 2023
@AurelienBISOTTI
Copy link

Feature is working for me (with Microsoft Entra ID), even if setting it up is not that easy, integration into core with guided configuration is the way to go

@AurelienBISOTTI
Copy link

AurelienBISOTTI commented Oct 12, 2023

Any work in progress to use
Response type = id token
Instead of code?

Seems that only "sub" claim is available with code (name or email claim are not good practices)
ID token should allow for "oid" claim instead which would ease by a lot the account logins we have to use in dolibarr

@cfoellmann
Copy link
Contributor

I am testing openid_connect as a login provider and it is working fine so far.
Problems:

  1. Can NOT be used together with LDAP.
  2. does not redirect back to the requested url. Always brings the user to the dashboard on successful auth

@uweschwennen
Copy link

I have still problems with the configuration of the client in keycloak. The instructions contain hardly any information on configuration in Keycloak. I have a few clients here that work wonderfully - such as Nextcloud, Matrix Synapse and Gitlab. But with Dolibarr I always get the error: Invalid parameter: redirect_uri. I think it is due to the client settings in Keycloak, the configuration of Dolibarr is exactly according to the instructions. Could someone help me with the clienet configuration in Keycloak?

Thank you very much!

@battosai30
Copy link
Contributor

Check the URL you get when you arrive on Keycloak, you should see an argument "redirect_uri".
redirect_uri error happens when allowed redirect url(s) in KC doesn't match the redirect_uri parameter in login request.
Two very common reasons :

  • Bad KC allowed URL configuration
  • Bad URL configuration from sender (Dolibarr in this case).

@uweschwennen
Copy link

Thanks for the quick reply!
I have authorized all addresses in KC with https://erp.char-num.fr/*.
The following address is stored in Dolibarr:
https://sso.char-num.fr/realms/CHAR-NUM/protocol/openid-connect/auth?client_id=dolibarr&redirect-uri=https://erp.char-num.fr/?openid_mode=true&scope=openid profile email&response_type=code

This contains the redirect-uri, doesn't it?

@irhad
Copy link

irhad commented Jun 4, 2024

I set up openid connect with dolibarr 19.0.2 installed in docker. I noticed that, by default, the “getURLContent” function filters out private IP addresses. So, according to the architecture, we get this error “Error bad hostname IP (private or reserved range). Must be an external URI", which is my case.

The only solution I've found is shown here: #25921.

My questions:
- Rather than changing the query in the “function_openid_connect.php” function as suggested (see link above) are there any other solutions?

  • When (which version) will this be fixed in dolibarr?

@battosai30
Copy link
Contributor

I don't know if it works but maybe you can modify your hosts file (I don't know your OS) and force an URL to localhost (test.example.net). It may "trick" the filter

@uweschwennen
Copy link

Now my link goes to Keycloak, I get the login page from Keycloak, can enter my credentials and am also redirected back to the Dolibarr page - but there is no login. Thanks for any further tips!
Here is the link:
https://erp.char-num.fr/?session_state=4c194726-4e6d-4234-8ba8-016bcf118e4e&iss=https%3A%2F%2Fsso.char-num.fr%2Frealms%2FCHAR-NUM&code=dc452f51-c026-44b3-95bb-5b42b16a1313.4c194726-4e6d-4234-8ba8-016bcf118e4e.942effef-861e-45f5-9be9-54501810fc3c

@dmajano
Copy link

dmajano commented Jun 10, 2024

Now my link goes to Keycloak, I get the login page from Keycloak, can enter my credentials and am also redirected back to the Dolibarr page - but there is no login. Thanks for any further tips! Here is the link: https://erp.char-num.fr/?session_state=4c194726-4e6d-4234-8ba8-016bcf118e4e&iss=https%3A%2F%2Fsso.char-num.fr%2Frealms%2FCHAR-NUM&code=dc452f51-c026-44b3-95bb-5b42b16a1313.4c194726-4e6d-4234-8ba8-016bcf118e4e.942effef-861e-45f5-9be9-54501810fc3c

I'm in the same situation. I'm trying to configure Dolibarr to authenticate with my keycloak.

This is the dolibarr error:

[Mon Jun 10 15:15:15.544509 2024] [php:error] [pid 505] [client 10.9.83.90:34426] PHP Fatal error: Uncaught TypeError: property_exists(): Argument #1 ($object_or_class) must be of type object|string, null given in /var/www/html/core/login/functions_openid_connect.php:72\nStack trace:\n#0 /var/www/html/core/login/functions_openid_connect.php(72): property_exists()\n#1 /var/www/html/core/lib/security2.lib.php(98): check_user_password_openid_connect()\n#2 /var/www/html/main.inc.php(863): checkLoginPassEntity()\n#3 /var/www/html/index.php(31): require('...')\n#4 {main}\n thrown in /var/www/html/core/login/functions_openid_connect.php on line 72 10.9.83.90 - - [10/Jun/2024:15:15:15 +0000] "GET /?openid_mode=true&session_state=3c4fd7ae-c49a-4554-877c-44492c8fe29a&iss=https%3A%2F%2FmyKeycloak.com%2Frealms%2FmyRealm&code=fb8a3124-da4c-4cae-92b9-434e2041853d.3c4fd7ae-c49a-4554-877c-44492c8fe29a.30ef539f-9fb4-4882-88ff-da9940f2bedc HTTP/1.1" 500 304 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:126.0) Gecko/20100101 Firefox/126.0"

But the session appears as started in Keycloak:

image

@SkyHyve
Copy link

SkyHyve commented Jul 6, 2024

Getting same issue with dolibarr/keycloak oidc
[php:error] [pid xx] [client x.x.x.x] PHP Fatal error: Uncaught TypeError: property_exists(): Argument #1 ($object_or_class) must be of type object|string, null given in /var/www/html/core/login/functions_openid_connect.php:72\nStack trace:\n#0 /var/www/html/core/login/

I do notice that unlike other applications using OIDC, there doesn't appear to be any state param set in the athoirsation request to the keycloak server and similarly there is no state param included in the redirect url request.
This may or may not have anything to do with the error, but I did notice it as different from other services using oidc to keycloak

@battosai30
Copy link
Contributor

I had this problem yesterday : I guess Dolibarr and Keycloak are on the same machine or at least the same network ?
So you're blocked by the getURLContent(). For safety reasons, by default special IPs are blocked (I'm pretty tired of this, in happpens in othher modules ....) This function used by functions_openid_connect.php

The best way to disable this is to modify geturl.lib.php this way :

function getURLContent($url, $postorget = 'GET', $param = '', $followlocation = 1, $addheaders = array(), $allowedschemes = array('http', 'https'), $localurl = 0, $ssl_verifypeer = -1)
{
....
}

To

function getURLContent($url, $postorget = 'GET', $param = '', $followlocation = 1, $addheaders = array(), $allowedschemes = array('http', 'https'), $localurl = 2, $ssl_verifypeer = -1)
{ ...
}

$localurl drives the IPs allowed, so by default with this modification you allow external and internal IPs.

@SkyHyve
Copy link

SkyHyve commented Jul 6, 2024

I had this problem yesterday : I guess Dolibarr and Keycloak are on the same machine or at least the same network ? So you're blocked by the getURLContent(). For safety reasons, by default special IPs are blocked (I'm pretty tired of this, in happpens in othher modules ....) This function used by functions_openid_connect.php

The best way to disable this is to modify geturl.lib.php this way :

function getURLContent($url, $postorget = 'GET', $param = '', $followlocation = 1, $addheaders = array(), $allowedschemes = array('http', 'https'), $localurl = 0, $ssl_verifypeer = -1)
{
....
}

To

function getURLContent($url, $postorget = 'GET', $param = '', $followlocation = 1, $addheaders = array(), $allowedschemes = array('http', 'https'), $localurl = 2, $ssl_verifypeer = -1)
{ ...
}

$localurl drives the IPs allowed, so by default with this modification you allow external and internal IPs.

Is there any way to do this with environment variables or something without changing code?
I am using truenas scale apps and it really isn't feasible to change the code every restart. I also would like to avoid copy/pasting this entire file and then mounting as a volume mount.

The keycloak server exists in a 192.168.x.x address, not the same as the dolibarr service

@battosai30
Copy link
Contributor

As I said :

or at least the same network

So 192.168.x.x is blocked

For now there is no env variable to avoid that, I think I will make a PR for this soon as it's a problem I meet regularly so I would like to solve it easyly (I work on Proxmox so it's always a local IP).

@uweschwennen
Copy link

Hi everybody,
what error log do you use for finding the errors? I use tail -f /var/www/html/dolibarr/documents/dolibarr.log. And now I have no failure message but I get this: 2024-07-07 10:36:33 DEBUG 192.168.1.254 sql=SELECT transkey, transvalue FROM llx_overwrite_trans where (lang='fr_FR' OR lang IS NULL) AND entity IN (0, 0,1) ORDER BY lang DESC
2024-07-07 10:36:33 INFO 192.168.1.254 --- End access to /index.php
And I cannot login....

@uweschwennen
Copy link

Now I have made some progress - something seems to have started moving! But now I get this error message: Identifiant ou mot de passe incorrect. But it is the right username and password and the account exists on keycloak and dolibarr in the same way.... Thanks for your help again!

@uweschwennen
Copy link

Here is what my mistake was: I had a small typo in the URL: redirect_uri I had a hyphen there!

@uweschwennen
Copy link

But the login is not working! But now I get this error message: Identifiant ou mot de passe incorrect.

@FlorentPoinsaut
Copy link
Contributor

@SkyHyve:

I do notice that unlike other applications using OIDC, there doesn't appear to be any state param set in the athoirsation request to the keycloak server and similarly there is no state param included in the redirect url request. This may or may not have anything to do with the error, but I did notice it as different from other services using oidc to keycloak

The addition of the state parameter is here: #29788

@uweschwennen
Copy link

This is the log entry:

[effective_method] => GET
[capath] => /etc/ssl/certs
[cainfo] => /etc/ssl/certs/ca-certificates.crt
[content] => {"sub":"08e205c0-7a7a-4b6c-87ee-1b453c8ea7ca","email_verified":true,"name":"Max Muster","preferred_username":"mmuster","given_name":"Max","family_name":"Muster","email":"max.muster@gmail.com"}
[curl_error_no] => 
[curl_error_msg] => 

)

2024-07-08 11:57:06 DEBUG 192.168.1.254 functions_openid::check_user_password_openid
2024-07-08 11:57:06 DEBUG 192.168.1.254 sql=SELECT login, entity, datestartvalidity, dateendvalidity FROM llx_user WHERE login = 'max.muster@gmail.com' AND entity IN (0,1)
2024-07-08 11:57:06 INFO 192.168.1.254 functions_openid_connect::check_user_password_openid_connect END
2024-07-08 11:57:06 NOTICE 192.168.1.254 Bad password, connexion refused (see a previous notice message for more info)
2024-07-08 11:57:06 DEBUG 192.168.1.254 sql=SELECT transkey, transvalue FROM llx_overwrite_trans where (lang='fr_FR' OR lang IS NULL) AND entity IN (0, 0,1) ORDER BY lang DESC
2024-07-08 11:57:06 INFO 192.168.1.254 Trigger 'BankImportApiTriggers' for action 'USER_LOGIN_FAILED' launched by /var/www/html/dolibarr-19.0.2/htdocs/custom/bankimportapi/core/triggers/interface_99_modBankImportApi_BankImportApiTriggers.class.php. id=0
2024-07-08 11:57:06 NOTICE 192.168.1.254 --- Access to GET /index.php - action= - actionlogin= - showing the login form and exit
2024-07-08 11:57:06 INFO 192.168.1.254 --- End access to /index.php

@battosai30
Copy link
Contributor

But the login is not working! But now I get this error message: Identifiant ou mot de passe incorrect.

OpenID doesn't create account in Dolibarr. The account must exists in Doolibarr with same username before trying to connect using OpenID

@uweschwennen
Copy link

I created the user beforehand with exactly the same login data. But the bug is still present. What could possibly still be wrong? Thanks for any help – I've been working on this for months now. By the way, I now have version 20.0.0.
Thank you very much.

@battosai30
Copy link
Contributor

it seems you are using email as username. It's possible, but usually username are more like m.muster
The only point to check is that uusername in Dolibarr is strictly max.muster@gmail.com
If not there is an issue getting the username, mostly caused by bad OpenID field mapping

@uweschwennen
Copy link

I've done it! The guy was helpful! I had entered my CLAIM email - but Dolibarr doesn't allow a username with an @! However, the user can be used if you enter CLAIM prefered_user. As soon as you do it right, it works!
Thanks for your effort!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature request This is a feature request
Projects
None yet
Development

No branches or pull requests