Feature Request: OpenID Connect authentication

jeritiana commented 1 year ago

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 https://github.com/Dolibarr/dolibarr/issues/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

Check that grant type Authorization code is enabled.
Allowed callback URLs: https://dolibarr.domain.com
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

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'
```
Copy/paste the file functions_openid_connect.php from #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.

Retrieve the /authorize endpoint. The value depends on the used Identity Provider. E.g.: https://tenant.us.auth0.com/authorize
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`

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`

Retrieve the /logout endpoint. The value depends on the used Identity Provider. E.g.: https://tenant.us.auth0.com/v2/logout
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`

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: https://github.com/Dolibarr/dolibarr/issues/21333 but I am not sure of its intended scope.

hregis commented 1 year ago

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

jeritiana commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

It appears that thoses variables are set here :

https://github.com/Dolibarr/dolibarr/blob/2e57cb1acbdf3b7b0b23617411b18d471c5f96f2/htdocs/main.inc.php#L1030-L1048

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 commented 1 year ago

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 commented 1 year ago

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 : https://github.com/Dolibarr/dolibarr/blob/2e57cb1acbdf3b7b0b23617411b18d471c5f96f2/htdocs/main.inc.php#L678-L687 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 commented 1 year ago

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 commented 1 year ago

I've though of it. Unfortunately, the link to perform the OIDC login is hardcoded here : https://github.com/Dolibarr/dolibarr/blob/2e57cb1acbdf3b7b0b23617411b18d471c5f96f2/htdocs/core/tpl/login.tpl.php#L316-L332

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

AurelienBISOTTI commented 9 months ago

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 commented 8 months ago

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 commented 6 months ago

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

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

uweschwennen commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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: https://github.com/Dolibarr/dolibarr/issues/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 commented 1 month ago

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 commented 1 month ago

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 commented 3 weeks ago

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:

SkyHyve commented 1 day ago

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 commented 1 day ago

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 commented 17 hours ago

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 commented 8 hours ago

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 commented 6 hours ago

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

Dolibarr / dolibarr