Nice. We would gladly accept a contribution but we will not take a patch for the library that is not accepted upstream.

I do not understand your questions. The field sub of the ID Token is used to identify a user as mentioned in the OpenID Connect Core specification. For now, when a user decides to unlink his Tuleap account from a OpenID Connect provider, Tuleap just removes the tuple user, sub and provider from the database. The front and back channel logout are still drafts specifications so we do not implements them yet.

I decided as follows:
To transform the answer to array I checked if there is any value with dash and turned using the DashToCamelCase case did not use what was already the UnderscoreToCamelCase and it worked: D

Only one doubt Thomas as the control for the SSO is done with other applications that have? For example it is saved a token? When I sign out I was not meant to erase and I can choose another user based on the provider?

Thank you for your all support!

Ok, I will try to solve this. Thank you!!

What is expected during the authentication flow can be found can be found in the OpenID Connect Core specification and yes, the character used to separate words in these responses is an underscore not a dash. I wanted to say that Keycloak uses an non standard with dashes.

The proper way to fix it is to either fix the lib or do a bit a refactoring so we don't use the library when we process the token endpoint response. We already do a lot of things ourselves at this level so it should not be too hard to do.

What is entry? The library you use speech that works with the provider of the google and here's an example I tested using the provider google the standard of separation is not the underscore?

And I'm sorry for all this questioning, I do not have much experience in this area;)


Request / Response

POST /oauth2/v4/token HTTP/1.1
Host: www.googleapis.com
Content-length: 163
content-type: application/x-www-form-urlencoded
user-agent: google-oauth-playground

client_secret=************&grant_type=refresh_token&refresh_token=1%2Fj3lgtdGvCDjwsk09yNmSvUyG2pK2pAiXnilncrxwwbk&client_id=407408718192.apps.googleusercontent.com

HTTP/1.1 200 OK
Content-length: 1227
X-xss-protection: 1; mode=block
X-content-type-options: nosniff
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Vary: Origin,X-Origin
Server: GSE
Pragma: no-cache
Cache-control: no-cache, no-store, max-age=0, must-revalidate
Date: Mon, 03 Oct 2016 01:51:04 GMT
X-frame-options: SAMEORIGIN
Content-type: application/json; charset=UTF-8

{
"access_token": "ya29.Ci9xAwrr9GzvlTz7hkBgcbvOcDlvO_eMm90VIbYvY3fNhwwvBKxyBbDp_WRRN627nQ",
"token_type": "Bearer",
"expires_in": 3600,
"id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6ImVmMDJjNDkyYTFjMTUzMWQxNDg4ODY1NGNhMzA3ZjBlNDE1OWU0YjEifQ.eyJpc3MiOiJodHRwczovL2FjY291bnRzLmdvb2dsZS5jb20iLCJhdF9oYXNoIjoiY0IzazJxeXN6NjRaS3VzVHNXc3JsQSIsImF1ZCI6IjQwNzQwODcxODE5Mi5hcHBzLmdvb2dsZXVzZXJjb250ZW50LmNvbSIsInN1YiI6IjEwNDc2MzQwMzYzNDgwNTg4MTQwMSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJhenAiOiI0MDc0MDg3MTgxOTIuYXBwcy5nb29nbGV1c2VyY29udGVudC5jb20iLCJlbWFpbCI6ImpmcmFuY29uZXRvOTBAZ21haWwuY29tIiwiaWF0IjoxNDc1NDU5NDY0LCJleHAiOjE0NzU0NjMwNjQsIm5hbWUiOiJKb3PDqSBGcmFuY28iLCJwaWN0dXJlIjoiaHR0cHM6Ly9saDQuZ29vZ2xldXNlcmNvbnRlbnQuY29tLy1Xb2VITE5fRW1hNC9BQUFBQUFBQUFBSS9BQUFBQUFBQUFKay9ETmdhY0R3S3Ffay9zOTYtYy9waG90by5qcGciLCJnaXZlbl9uYW1lIjoiSm9zw6kiLCJmYW1pbHlfbmFtZSI6IkZyYW5jbyIsImxvY2FsZSI6InB0In0.QrNZTe74iOMSVIqoT49Rs1nZF8L1AmMCEw1oTTtKjf7QyM48mu7AtiQ7yC1drtrzA7P2L4Tblg6czcHYropgiv_M1szPUecbusbvA4eXBGXuYG9VzlR3naRFhd31fGZpIvcO-uf-BxRyorPNjT7Tqi_B9pk5NRDDfUXdOP491W9CsF1dNpad7GCIIMnWOhlvUYN71qpf2exu43CZMUuEtVkL_68K-y1Cy5-s4UZb4dABtT4-1D00-nAC3NanY04w_sLxZkt8jy4bG4d2uD6SJutNDgTjiiV_IKMmkErylAEhEOp1aGplwkG08QZ7lCdFU_djSNSmS-jREXhJsQrAJQ"
}

I not adopted this "solution": D, just saw that the error was in the token request. But as you said it was in keycloak token response which is the best way to solve it modify the code Keycloack?

I have found the issue. Keycloak adds a non standard entry to the response of the token endpoint. This entry uses underscore as separator instead of a dash like other standard properties. The library we use to manage OpenID Connect will throw an exception when encountering this property putting an end to the authentication flow.

Knowing that, I can definitively confirm that the proposed solution is dangerous and does not work.

Do not do this! It is definitively not the right way to solve the issue, by doing that you are simply removing an important part of the process. At best you just made yourself vulnerable to CSRF attack, at worst anyone trying to log in your instance using OpenID Connect will be logged as the first user which has used the OpenID Connect provider to log into your instance.

OpenID Connect is not a simple protocol, I highly suggest reading the specifications before hacking the code just to make it work. Otherwise you potentially put your Tuleap instance at risk.

The error probably is in this part of the code:
Flow.php
...
try {
$token_request = $this->createTokenRequest($authorization_code);
$token_response = $this->getTokenDispatcher()->sendTokenRequest($token_request);
$access_token = $token_response->getAccessToken();
$encoded_id_token = $token_response->getIdToken();
$id_token = $this->id_token_verifier->validate($provider, $state->getNonce(), $encoded_id_token);
} catch (Exception $ex) {
throw new TokenRequestException(
sprintf("Exception during token request: [%s] %s", get_class($ex), $ex->getMessage()),
null,
$ex
);
}
...

I don't know why, but I remove the throw of catch and work correctly.

What can it be ?

Thomas, I put the certificate and I can run this: curl https://192.168.1.118:8543/auth/realms/<realm>/.well-known/openid-configuration with correct realm
But the error continue. "Request seems invalid, please retry"

Ok so we know why it does not work.

Either the store of CA certificates is not up to date or your Keycloak server use a certificate signed by a CA not (yet ?) recognized by the store on CentOS6. As an alternative you can explicitly add the certificate used by your Keycloak server in the store of the Tuleap server: https://tuleap-documentation.readthedocs.io/en/latest/administration-guide/howto.html#add-a-new-certification-authority-to-the-ca-bundle

curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
More details here: https://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.

Just working from the browser.

Just a hunch here: Could you please execute directly from your Tuleap server the following command (do not forget to replace <realm> by the realm you are using): curl https://192.168.1.118:8543/auth/realms/<realm>/.well-known/openid-configuration

I put my domain and now the redirect is working, but when go back to Tuleap the message is shown "Request seems invalid, please retry" and going to /account/login page. The same error wich I reported in http://superuser.com/questions/1129022/how-do-i-configure-the-openidconnect-plugin-in-tuleap/1129198?noredirect=1#comment1617765_1129198.
What can it be?

Ok so it explains why it does not work. Please update these accordingly to your environment.

If you are using our Docker image you probably have forgotten to set the environment variables on the first run.

Hummm, they are empty.

The URL redirect should be something like https://<tuleap_url>/plugins/openidconnectclient/ if you only have https:///plugins/openidconnectclient/ something is probably wrong with your local.inc file.

Can you check what you have in sys_default_domain, sys_https_host and sys_cookie_domain?

Yes here is:

Authorization endpoint: https://192.168.1.118:8543/auth/realms/<realm>/protocol/openid-connect/auth
Token endpoint: https://192.168.1.118:8543/auth/realms/<realm>/protocol/openid-connect/token
User Information endpoint: Token endpoint: https://192.168.1.118:8543/auth/realms/<realm>/protocol/openid-connect/userinfo

I have one doubt... The url_redirect must be only https:///plugins/openidconnectclient/ ?

I'm not familiar with this one. I took a quick look to their documentation, it should work.

They have a Docker image available [1] so it should not be too hard to test on our side, I will investigate when I got some time.


Just to be sure, what URLs do you specify in the provider configuration on the Tuleap side?



[1] https://hub.docker.com/r/jboss/keycloak/

Hi Thomas, yes with Keycloack.