•  
      request #9527 OpenID Connect plugin does not work with Keycloak
    Infos
    #9527
    José Franco Neto (jfranconeto)
    2018-08-28 13:17
    2016-09-29 14:11
    9794
    Details
    OpenID Connect plugin does not work with Keycloak
    When I trying to authenticate the provider can't handling the authentication request and don't redirect to Tuleap.
    Authentication & LDAP
    8.19
    Empty
    • [ ] enhancement
    • [ ] internal improvement
    Empty
    Stage
    Empty
    Closed
    2018-08-28
    Attachments
    Empty
    References

    Follow-ups

    User avatar
    Thomas Gerbet (tgerbet)2018-08-23 16:01
    A patch to fix the compatibility issue is under review: gerrit #12424.

    • Summary
      -Openidconnect plugin can't handling authentication request to identity provider. 
      +OpenID Connect plugin does not work with Keycloak 
    • Status changed from Verified to Under review
    • Platform cleared values: CentOS 6
    User avatar
    Thomas Gerbet (tgerbet)2016-10-04 09:48
    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.
    User avatar
    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!
    User avatar
    Thomas Gerbet (tgerbet)2016-10-03 09:10
    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.
    User avatar
    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"
    }
    User avatar
    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?
    User avatar
    Thomas Gerbet (tgerbet)2016-10-01 22:51
    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.
    User avatar
    Thomas Gerbet (tgerbet)2016-10-01 16:28
    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.
    User avatar
    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.
    User avatar
    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.
    User avatar
    Thomas Gerbet (tgerbet)2016-09-29 16:15
    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.
    User avatar
    Thomas Gerbet (tgerbet)2016-09-29 15:39
    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?
    User avatar
    Thomas Gerbet (tgerbet)2016-09-29 14:48
    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/
    User avatar
    Thomas Gerbet (tgerbet)2016-09-29 14:15
    Hi,

    Thanks for your report. Do you encounter your issue with a specific OpenID Connect provider?

    • Status changed from New to Acknowledged