seelink
Septembre 13, 2019, 11:17
1
Bonjour,
Je souhaite configurer OPENID avec Office 365.
J’ai fait une partie du chemin:
Par contre, je reviens sur la page de connexion dolibarr (c’est celle que j’ai défini coté 365).
Quelqu’un peut il m’éclairer ?
Xavier
pm17
Septembre 13, 2019, 12:47
2
Bonjour,
Avez-vous pu utiliser OpenID pour vous connecter?
En gros, j’en suis au même point que vous à savoir que je peux ouvrir la page d’authentification (dans mon cas c’est avec keycloak) et je reviens sur la page de connexion dolibarr, rien de plus.
J’ai bien lu les 2 messags de la réponse précédente amis impossible d’avancer plus.
Quelqu’un a-t’il pu se connecter avec openid?
Jimmy
Bonjour,
Je suis dans la même situation. Avez vous pu trouver un contournement ou une autre solution, payante ou gratuite ?
Merci à tous ceux qui répondront
Bonjour,
Il y a une implémentation OpenID récemment disponible sur GitHub (à priori je ne peux pas mettre le lien dans mon message ici). C’est l’issue #22740 sur le GitHub Dolibarr.
C’est fonctionnel sur Auth0 et vous pouvez sans doute l’utiliser pour tester avec d’autres fournisseurs. Si vous pouvez faire des retours ce serait top !
Je fais mon tour des sujets sur le forum car jusque là il manquait une réponse OK avec un guide : c’est bien fonctionnel
Inscription d’une application : je créé une application dédiée à la gestion de la connexion.
« dolibarr demo » peut être ignorée, je l’ai créée pour la synchronisation Dolibarr <=> Microsoft des agendas et l’envoi de mails par Dolibarr via exchange.
[Sélection_023]
Ici l’ID d’application est l’information importante, et sera à renseigner dans vos différentes URL dans les constantes Dolibarr.
Vous aurez aussi besoin d’aller regarder vos points de terminaison pour certaines URL à renseigner d…
opened 03:41PM - 03 Nov 22 UTC
Feature request
There is already an "OpenID" support in Dolibarr, but it is actually OpenID vers… ion 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
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 `[email protected] ` 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 #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](https://github.com/Dolibarr/dolibarr/blob/16.0/htdocs/core/tpl/login.tpl.php#L316):
`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](https://github.com/Dolibarr/dolibarr/blob/16.0/htdocs/main.inc.php#L766):
```
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](https://github.com/Dolibarr/dolibarr/blob/16.0/htdocs/user/logout.php#L75).
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.
