Feature Request: OpenID Connect authentication

[jeritiana]

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'

2. 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

3. 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

3. 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]

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

[jeritiana]

@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.

[battosai30]

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 :

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 :

With Oidc :

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

[AisukoHakumei]

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]

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]

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 :

dolibarr/htdocs/main.inc.php

Lines 678 to 687 in 2e57cb1

	$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]

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]

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

dolibarr/htdocs/core/tpl/login.tpl.php

Lines 316 to 332 in 2e57cb1

	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]

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

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]

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]

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]

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