-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Comments
@jeritiana wouhououou... And you have a bug? |
@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. |
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 With direct login : With Oidc : The question is now : why Oidc leads to "TZ=;TZString=;Screen=x" |
It appears that thoses variables are set here : Lines 1030 to 1048 in 2e57cb1
Maybe we could set some fallback entries ? EDIT: |
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.
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 |
Yep, you summed it pretty right !
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.
For the record, the values for the screen size are empirical and might mess with the mobile view. EDIT : I think I got it working ! Lines 678 to 687 in 2e57cb1
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 :) |
Oh cool trick ! |
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
And the login flow fails if there is a mismatch between |
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. |
On this part, yes it's tweakable. |
Just wanted to let you know, that we implemented it using:
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:
Built from these basevalues:
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! |
This feature is awesome and work pretty well. Since we don't want an unclean Dolibarr core, we have created a module only for Link to the public repo : openidconnect |
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 |
Any work in progress to use Seems that only "sub" claim is available with code (name or email claim are not good practices) |
I am testing openid_connect as a login provider and it is working fine so far.
|
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! |
Check the URL you get when you arrive on Keycloak, you should see an argument "redirect_uri".
|
Thanks for the quick reply! This contains the redirect-uri, doesn't it? |
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:
|
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 |
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! |
I'm in the same situation. I'm trying to configure Dolibarr to authenticate with my keycloak. This is the dolibarr error:
But the session appears as started in Keycloak: |
Getting same issue with dolibarr/keycloak oidc 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. |
I had this problem yesterday : I guess Dolibarr and Keycloak are on the same machine or at least the same network ? The best way to disable this is to modify geturl.lib.php this way :
To
$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? The keycloak server exists in a 192.168.x.x address, not the same as the dolibarr service |
As I said :
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). |
Hi everybody, |
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! |
Here is what my mistake was: I had a small typo in the URL: redirect_uri I had a hyphen there! |
But the login is not working! But now I get this error message: Identifiant ou mot de passe incorrect. |
The addition of the state parameter is here: #29788 |
This is the log entry:
) 2024-07-08 11:57:06 DEBUG 192.168.1.254 functions_openid::check_user_password_openid |
OpenID doesn't create account in Dolibarr. The account must exists in Doolibarr with same username before trying to connect using OpenID |
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. |
it seems you are using email as username. It's possible, but usually username are more like m.muster |
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! |
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
Authorization code
is enabled.https://dolibarr.domain.com
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 loginbob42
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
, ornickname
). Hint: in the Dolibarr database, see tablellx_user
, columnlogin
.How to use: Dolibarr configuration
On the Dolibarr host
conf.php
(/var/www/html/conf/conf.php
) and addopenid_connect
.For e.g.:
functions_openid_connect.php
from NEW #22740 Add OpenID Connect impl #22741 in thecore/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
My-Super-Awesome-Client-ID-1234
/?openid_mode=true
, then URL encoded. Must be authorized as callback URLhttps://dolibarr.domain.com/?openid_mode=true
- After URL encoding:https%3A%2F%2Fdolibarr.domain.com%2F%3Fopenid_mode%3Dtrue
openid profile email
code
for the Authorization Code flowcode
MAIN_AUTHENTICATION_OPENID_URL
content should be like: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
My-Super-Awesome-Client-ID-1234
https://dolibar.domain.com
MAIN_LOGOUT_GOTO_URL
content should be like:Dolibarr application setup
The final configuration step is to create the following values in Home > Setup > Other Setup.
MAIN_AUTHENTICATION_OPENID_URL
MAIN_LOGOUT_GOTO_URL
MAIN_AUTHENTICATION_OIDC_CLIENT_ID
My-Super-Awesome-Client-ID-1234
MAIN_AUTHENTICATION_OIDC_CLIENT_SECRET
My-Very-Hidden-Client-Secret-1234
MAIN_AUTHENTICATION_OIDC_TOKEN_URL
https://tenant.us.auth0.com/oauth/token
/token
endpointMAIN_AUTHENTICATION_OIDC_USERINFO_URL
https://tenant.us.auth0.com/userinfo
/userinfo
endpointMAIN_AUTHENTICATION_OIDC_REDIRECT_URL
https://dolibarr.domain.com/?openid_mode=true
/?openid_mode=true
MAIN_AUTHENTICATION_OIDC_LOGIN_CLAIM
email
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 matchopenid_connect
, which allows us to display and useMAIN_AUTHENTICATION_OPENID_URL
on the login page (implemented with OpenID 2.0 support).return_uri
inMAIN_AUTHENTICATION_OPENID_URL
The
return_uri
parameter is built specifically to includeopenid_mode=something
. Here we usedopenid_mode=true
.This is because of main.inc.php:
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, asMAIN_AUTHENTICATION_OPENID_URL
andMAIN_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.
The text was updated successfully, but these errors were encountered: