I would never advise anyone to write their own code to integrate with Open ID Connect.
An open source solution pre-built from professionals like Ory Kratos or Keycloak saves you a lot of time and pain.
An open source solution pre-built from professionals like Ory Kratos or Keycloak saves you a lot of time and pain.
Keycloak in itself is a pain to manage as well. Without Terraform, you're lost... and integrating stuff with Keycloak is a pain as well. I've tried and failed to integrate a self-hosted GitLab instance, for example - their docs [1] don't specify anything how the Keycloak config is supposed to look like, the next best Google hit doesn't either [2], and somewhen in the last two years the third Google hit [3] got outdated - the Keycloak OIDC configuration UI got completely reorganized and renamed. Other stuff like Atlassian is a pain to integrate with Keycloak OIDC as well.
So, if anyone could point me to a working configuration for modern Keycloak and GitLab, I'd be really thankful. And if doc writers could specify a working Terraform, Ansible or whatever code that specifies the Keycloak configuration the application understands, I'd be even more thankful. OIDC is a horrible mess, I get it, but if your users can't get it to work because you specify nowhere what exact flavor and quirks of OIDC your application need, it reflects badly not just on Keycloak but on your application as well.
Based on [1], I believe I can guide you through that:
Given that your keycloak instance is running (and accessible to the user browser) at https://mykeycloak.net, its version is 17 or higher and you are using the realm named _master_.
3 - Set args.issuer.client_options.identifier to `gitlab`
4 - Set args.issuer.client_options.secret to CLIENT_SECRET
Hope that helps. If that works for you, please write a public markdown github gist with this tutorial and the title "how to configure gitlab with keycloak?" this will help future google searchers. Be sure to reinclude the question "how to configure gitlab with keycloak?" as a title inside the gist, with the tutorial following, as google favors question and answer style.
I don’t have the code handy because I’m on my phone but we use keycloak for archlinux.org. You should be able to find the terraform and config for it all on our gitlab instance.
An open source solution pre-built ... saves you a lot of time and pain.
I haven't looked at the linked solutions specifically, but I've only rarely found this to be the case for generic protocols like this (especially anything around OAuth or OpenID). The open source solutions I've tried and given up on using always pull in hundreds of dependencies that have their own idiosyncracies as well as make a lot of undocumented assumptions and not be very well documented. Not to mention I still have to write code to use the "pre-built" solutions - usually more code than I would have had to write to just code the thing myself from scratch. They may be "better" from some perspective, but when I was working with OAuth, I tried (and tried and tried and tried) to use a pre-built solution for weeks until I finally gave up and just wrote my own in less than a day. Definitely longer and more painful to try to adopt somebody else's solution.
Correct, it's not that it's limited, it's just different components of ORY stack. Kratos only does identity management and authentication (including being OIDC client). Oathkeeper does Identity Aware Proxy part. Finally, Hydra acts as OAuth 2.0 and OpenID Connect server.
You can use either one of them separately or together. There is also no special glue to...glue them together, so you can use Hydra with different user management or Kratos with different OIDC server - my company at one point used Kratos for all user management, but Hydra was overkill, so we made our own OIDC server.
Hey Radek, I am good, thanks for asking.
Check in sometime!
Limited compared to a full Keycloak install probably, but I think Ory Kratos is much easier to use and enough for most use cases. IMO you often dont need to use OAuth2 or Oathkeeper if you are not doing SSO, API access control or m2m communication. But of course there are many good options and approaches.
I stopped comparing the Ory stack to Keycloak some time ago. As you know, I like the modularity of Ory better than the single Keycloak deployment. However, what always gets me when deploying authn is that it releases the cat from the bag. Authz and additional sessions almost always come as a requirement right after.
Last Kratos I looked at was 0.6 so fairly aged by now. Have you had a chance to make the Kratos/Hydra/Keto integration a little bit … less abstract? From memory, integrating Kratos and Hydra reqired a ton of glue code one had to write themselves. That’s the reason why I always reach for Keycloak.
Sorry for the somewhat late answer, but we recently released Hydra 2.0 which makes the Kratos/Hydra integration much easier. You can also get it out of the box on the managed service (+ a ton of other features).
You need a simple consent page for the integration and that is it basically.
Check it out sometime :-)
Comments
I would never advise anyone to write their own code to integrate with Open ID Connect. An open source solution pre-built from professionals like Ory Kratos or Keycloak saves you a lot of time and pain.
https://github.com/ory/kratos
https://www.keycloak.org/
Why, the protocol is clearly defined. Especially clients have an easy life. Maybe stop promoting your own product with fear mongering
Keycloak in itself is a pain to manage as well. Without Terraform, you're lost... and integrating stuff with Keycloak is a pain as well. I've tried and failed to integrate a self-hosted GitLab instance, for example - their docs [1] don't specify anything how the Keycloak config is supposed to look like, the next best Google hit doesn't either [2], and somewhen in the last two years the third Google hit [3] got outdated - the Keycloak OIDC configuration UI got completely reorganized and renamed. Other stuff like Atlassian is a pain to integrate with Keycloak OIDC as well.
So, if anyone could point me to a working configuration for modern Keycloak and GitLab, I'd be really thankful. And if doc writers could specify a working Terraform, Ansible or whatever code that specifies the Keycloak configuration the application understands, I'd be even more thankful. OIDC is a horrible mess, I get it, but if your users can't get it to work because you specify nowhere what exact flavor and quirks of OIDC your application need, it reflects badly not just on Keycloak but on your application as well.
/rant
[1] https://docs.gitlab.com/ee/administration/auth/oidc.html#con...
[2] https://github.com/ChathuminaVimukthi/Gitlab-SSO-implementat...
[3] https://dheeruthedeployer.medium.com/gitlab-integration-with...
Based on [1], I believe I can guide you through that:
Given that your keycloak instance is running (and accessible to the user browser) at https://mykeycloak.net, its version is 17 or higher and you are using the realm named _master_.
Given that your gitlab is at https://gitlab.example.com.
At keycloak:
1 - create a new client, name it `gitlab` and set https://gitlab.example.com/users/auth/openid_connect/callbac... as the root url (henceforth CALLBACK_URI)
At keycloak, in the `gitlab` client settings screen, tab settings:
1 - Set `acess type` to `confidential`.
2 - Set `Direct Access Grants Enabled` to off.
3 - Set `Valid Redirect URIs` to `https://gitlab.example.com/users/auth/openid_connect/callbac...`* (that is the CALLBACK_URI followed by a *)
4 - Save it (A previously hidden credentials appear in the settings screen.)
At keycloak, in the `gitlab` client settings screen, tab credentials:
1 - note down your client secret (something like HMPhR89hoxrcotAz9vWjEAlPCWRAx2MP), henceforth CLIENT_SECRET
At your gitlab instance config file, setting gitlab_rails['omniauth_providers']:
1 - Set the content as in [1]
2 - Set args.issuer to https://mykeycloak.net/realms/master
3 - Set args.issuer.client_options.identifier to `gitlab`
4 - Set args.issuer.client_options.secret to CLIENT_SECRET
Hope that helps. If that works for you, please write a public markdown github gist with this tutorial and the title "how to configure gitlab with keycloak?" this will help future google searchers. Be sure to reinclude the question "how to configure gitlab with keycloak?" as a title inside the gist, with the tutorial following, as google favors question and answer style.
[1] = https://docs.gitlab.com/ee/administration/auth/oidc.html#con...
Sadly, this does not work. The logs aren't exactly useful either:
==> /var/log/gitlab/nginx/gitlab_access.log <== 100.107.130.186 - - [23/Dec/2022:16:15:01 +0000] "POST /users/auth/openid_connect HTTP/1.1" 302 107 "https://git-xxx.xxx.de/users/sign_in" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36" -
==> /var/log/gitlab/gitlab-rails/application.log <== 2022-12-23T16:15:01.709Z: (openid_connect) Request phase initiated. 2022-12-23T16:15:01.735Z: (openid_connect) Authentication failure! Not Found: OpenIDConnect::Discovery::DiscoveryFailed, Not Found
==> /var/log/gitlab/gitlab-rails/application_json.log <== {"severity":"DEBUG","time":"2022-12-23T16:15:01.709Z","correlation_id":"01GMZW8DH3E10E8NBYKC65MCYR","message":"(openid_connect) Request phase initiated."} {"severity":"ERROR","time":"2022-12-23T16:15:01.735Z","correlation_id":"01GMZW8DH3E10E8NBYKC65MCYR","message":"(openid_connect) Authentication failure! Not Found: OpenIDConnect::Discovery::DiscoveryFailed, Not Found"}
Bring this to keycloak forum and I'll help.
I don’t have the code handy because I’m on my phone but we use keycloak for archlinux.org. You should be able to find the terraform and config for it all on our gitlab instance.
I haven't looked at the linked solutions specifically, but I've only rarely found this to be the case for generic protocols like this (especially anything around OAuth or OpenID). The open source solutions I've tried and given up on using always pull in hundreds of dependencies that have their own idiosyncracies as well as make a lot of undocumented assumptions and not be very well documented. Not to mention I still have to write code to use the "pre-built" solutions - usually more code than I would have had to write to just code the thing myself from scratch. They may be "better" from some perspective, but when I was working with OAuth, I tried (and tried and tried and tried) to use a pre-built solution for weeks until I finally gave up and just wrote my own in less than a day. Definitely longer and more painful to try to adopt somebody else's solution.
Dex is also an interesting project in this space. It can act as an OIDC provider, but can be extended with other providers via "connectors".
https://dexidp.io/
A bit like Keycloak?
I didn't used my own code - as mentioned I used Zitadel (a competitor to Ory and Keycloak) but it is still a pain in the ass.
Hi Vincent, hope you are well at Ory. Kratos without Hydra and Oathkeeper is pretty limited, no?
Correct, it's not that it's limited, it's just different components of ORY stack. Kratos only does identity management and authentication (including being OIDC client). Oathkeeper does Identity Aware Proxy part. Finally, Hydra acts as OAuth 2.0 and OpenID Connect server.
You can use either one of them separately or together. There is also no special glue to...glue them together, so you can use Hydra with different user management or Kratos with different OIDC server - my company at one point used Kratos for all user management, but Hydra was overkill, so we made our own OIDC server.
Hey Radek, I am good, thanks for asking. Check in sometime! Limited compared to a full Keycloak install probably, but I think Ory Kratos is much easier to use and enough for most use cases. IMO you often dont need to use OAuth2 or Oathkeeper if you are not doing SSO, API access control or m2m communication. But of course there are many good options and approaches.
Good to hear you are well.
I stopped comparing the Ory stack to Keycloak some time ago. As you know, I like the modularity of Ory better than the single Keycloak deployment. However, what always gets me when deploying authn is that it releases the cat from the bag. Authz and additional sessions almost always come as a requirement right after.
Last Kratos I looked at was 0.6 so fairly aged by now. Have you had a chance to make the Kratos/Hydra/Keto integration a little bit … less abstract? From memory, integrating Kratos and Hydra reqired a ton of glue code one had to write themselves. That’s the reason why I always reach for Keycloak.
Sorry for the somewhat late answer, but we recently released Hydra 2.0 which makes the Kratos/Hydra integration much easier. You can also get it out of the box on the managed service (+ a ton of other features). You need a simple consent page for the integration and that is it basically. Check it out sometime :-)