5 ms·

I search 2 years ago a working server and not found ;(

by styczen 2y ago

personality1 2y ago
Have you tired https://www.keycloak.org/ https://www.keycloak.org/?
- dathinab 2y ago
  In my experience KeyCloak can be a very mixed bag. And if you are especially unlucky might be so painful to use that you could say it doesn't work. But for a lot of use cases it does work well. In some context it might safe you not just developer month, but years (e.g. certain use cases with certification/policy enforcement aspects). But it also can be a story from running from one rough edge into another where you project lead/manager starts doubling or tripping any time estimate of stories involving Keycloak. E.g. the REST API of Keycloak (for programmatic management of it) is very usable but full of inconsistencies and terrible badly documented (I mean there is a OpenAPI spec but it's very rarely giving you satisfying answers for the meaning of a listed parameter beyond a non descriptive 3 word description). (It's also improving with each version.) Similar multi tenancy can be a pain, depending on what exactly you need. UMA can be grate or a catastrophe, again depending on your specific use cases. SSO User management can just fine or very painful. There is a UI for customizing the auth flow, but it has a ton of subtle internal/impl. detail constraints/mechanics not well documented which you have to know to effectively use it so if you can't copy past someones else solution or only need trivial changes this can be a huge trap (looking like a easy change but being everything but that)... The build in mail templates work, but can get your mail delivery (silently) dropped (not sure why, maybe some scammers used Keycloak before). The default user facing UI works but you will have to customize it even if just for consistent branding and it uses it's own Java specific rendering system (and consistent branding here isn't just a fancy looks goal, one of the first things though on scam avoidance courses for non technical people is, that if it looks very different it's probably a scam and you shouldn't log in). I think Keycloak is somewhat of a no brainer for large teams, but can be a dangerous traps for very small teams.
  - twobiers 2y ago
    I cannot agree more on the very mixed bag. In general, Keycloak is a very solid Authorization server. There is a very active community around Keycloak, and if one need an authorization server, they should consider picking it. We use it in an internal multi-tenant environment as a central customer authentication platform. BUT there's also a lot of pain in using Keycloak, especially when you build on top of it. One of the great things about Keycloak is, that it can be seen as an extendible platform. Nearly everything is customizable. However, it takes a lot of time and effort to learn the programming model and especially the documentation is a PITA. It has been even worse 2 years ago, but it's still a lot of fiddeling around and usual I find myself in reading the Keycloak source (which has a very mixed quality btw.) as no documentation is available. Multi tenancy is indeed also a hard topic. We heavily utilize multiple realms (I think we should have hit 100 already) for that, but newer developments in Keycloak now offer an additional model based around organizations [1]. One thing that bothers me personally is that the storage model of keycloak does not offer zero-downtime migrations and the work on refactoring it has been paused for now. Since we have a solution based on Keycloak, we deploy Keycloak regulary with every feature. However, the embedded infinispan cache makes this hard on scale as during redeployments Keycloak become unresponsive due to cache leader synchronization and eventually drops some caches, leading to user sessions being terminated. Fortunally Keycloak finally has support for an external Infinispan cache [2] and moved to protocol buffers for serialization [3], which should make upgrades smoother, and grounds the road to zero-downtime deployments. After all this, let me emphasize that for most of it the Keycloak team is aware and is working hard in moving forward. I started using Keycloak with Version 11 and a lot has changed for the better. > I think Keycloak is somewhat of a no brainer for large teams, but can be a dangerous traps for very small teams. I would not agree on that. You don't necessarily need a large team for operating Keycloak and smaller teams are probably not that big of an issue. At least not for operating Keycloak. What I feel to be more a problem is, that many (at least of our) clients are not understanding OAuth 2.0 and OIDC well, and therefore puts a larger burdon on support work. Also there must be at least someone very knowledgable of Keycloak to give guidance to the rest of the team, but in general I would not say it's dangerous. We have even a team operating their own keycloak and using our keycloak to perform OIDC federation (don't ask me why tho, I never understood it). [1] https://www.keycloak.org/2024/06/announcement-keycloak-organizations https://www.keycloak.org/2024/06/announcement-keycloak-organ... [2] https://github.com/keycloak/keycloak/issues/28745 https://github.com/keycloak/keycloak/issues/28745 [3] https://www.keycloak.org/docs/latest/release_notes/index.html#infinispan-marshalling-changes-to-infinispan-protostream https://www.keycloak.org/docs/latest/release_notes/index.htm...
uj6re 2y ago
open source: keycloak connect2id dex gluu closed source self hosted: adfs hosted: okta (auth0) google microsoft github amazon these are just the ones that were viable 2 years ago
- mooreds 2y ago
  Another closed source option, which can be self-hosted or used as a SaaS: FusionAuth (my employer). It also has a full featured plan which is free if you self host and is available via docker, etc.
- orphea 2y ago
  also open source: zitadel
  - mffap 2y ago
    https://github.com/zitadel/zitadel https://github.com/zitadel/zitadel
- orra 2y ago
  Thanks, although connect2id doesn't look open source.
- vemgar 2y ago
  also open source: Authentik
mrweasel 2y ago
We run Apereo CAS pretty successfully. Originally to use the CAS protocol, but now that CAS (the protocol) has been deprecated, we're slowly migrating to OIDC. One sort of weird note about Apereo CAS, OpenID Connect can return data in two format, nested and flat. CAS is the only server I've ever worked with, that defaults to nested. Almost no clients supports this, but the server can be reconfigured to use flat. KeyCloak is also very good, but I'd run is as a container due to the quick release/update cycle. If I had to do our infrastructure over, I'd probably go for KeyCloak, just because it's the most used.
- mooreds 2y ago
  Hmmm. Here's details about using CAS as an OpenID Connect provider: https://apereo.github.io/cas/7.0.x/authentication/OIDC-Authentication.html https://apereo.github.io/cas/7.0.x/authentication/OIDC-Authe... Looks like it doesn't support multiple issuers: " CAS primarily supports a single issuer per deployment/host." Have you run into any issues with that? It also looks like it supports a number of optional standards: DPoP, JARM, PAR. Have you seen use cases for these?
  - mrweasel 2y ago
    > Looks like it doesn't support multiple issuers Yeah, we only have the one issuer, so it's not a concern. For pretty much every KeyCloak project I've done, we have also favored doing separate deployments for separate issuers, so I'd say it's not much of an issue, in most cases. Regarding the optional standards, no. We've not run into an clients that would require or in many cases even support anything but the most basic OpenID Connect. I'm sure there's a point to supporting them, but I've never seen it being needed for your average use case.
taberiand 2y ago
https://ory.sh https://ory.sh has an open- source self-hosted option Hydra (and a number of other services)

I search 2 years ago a working server and not found ;(

personality1 2y ago

Have you tired https://www.keycloak.org/ https://www.keycloak.org/?

dathinab 2y ago
In my experience KeyCloak can be a very mixed bag. And if you are especially unlucky might be so painful to use that you could say it doesn't work. But for a lot of use cases it does work well. In some context it might safe you not just developer month, but years (e.g. certain use cases with certification/policy enforcement aspects). But it also can be a story from running from one rough edge into another where you project lead/manager starts doubling or tripping any time estimate of stories involving Keycloak. E.g. the REST API of Keycloak (for programmatic management of it) is very usable but full of inconsistencies and terrible badly documented (I mean there is a OpenAPI spec but it's very rarely giving you satisfying answers for the meaning of a listed parameter beyond a non descriptive 3 word description). (It's also improving with each version.) Similar multi tenancy can be a pain, depending on what exactly you need. UMA can be grate or a catastrophe, again depending on your specific use cases. SSO User management can just fine or very painful. There is a UI for customizing the auth flow, but it has a ton of subtle internal/impl. detail constraints/mechanics not well documented which you have to know to effectively use it so if you can't copy past someones else solution or only need trivial changes this can be a huge trap (looking like a easy change but being everything but that)... The build in mail templates work, but can get your mail delivery (silently) dropped (not sure why, maybe some scammers used Keycloak before). The default user facing UI works but you will have to customize it even if just for consistent branding and it uses it's own Java specific rendering system (and consistent branding here isn't just a fancy looks goal, one of the first things though on scam avoidance courses for non technical people is, that if it looks very different it's probably a scam and you shouldn't log in). I think Keycloak is somewhat of a no brainer for large teams, but can be a dangerous traps for very small teams.
- twobiers 2y ago
  I cannot agree more on the very mixed bag. In general, Keycloak is a very solid Authorization server. There is a very active community around Keycloak, and if one need an authorization server, they should consider picking it. We use it in an internal multi-tenant environment as a central customer authentication platform. BUT there's also a lot of pain in using Keycloak, especially when you build on top of it. One of the great things about Keycloak is, that it can be seen as an extendible platform. Nearly everything is customizable. However, it takes a lot of time and effort to learn the programming model and especially the documentation is a PITA. It has been even worse 2 years ago, but it's still a lot of fiddeling around and usual I find myself in reading the Keycloak source (which has a very mixed quality btw.) as no documentation is available. Multi tenancy is indeed also a hard topic. We heavily utilize multiple realms (I think we should have hit 100 already) for that, but newer developments in Keycloak now offer an additional model based around organizations [1]. One thing that bothers me personally is that the storage model of keycloak does not offer zero-downtime migrations and the work on refactoring it has been paused for now. Since we have a solution based on Keycloak, we deploy Keycloak regulary with every feature. However, the embedded infinispan cache makes this hard on scale as during redeployments Keycloak become unresponsive due to cache leader synchronization and eventually drops some caches, leading to user sessions being terminated. Fortunally Keycloak finally has support for an external Infinispan cache [2] and moved to protocol buffers for serialization [3], which should make upgrades smoother, and grounds the road to zero-downtime deployments. After all this, let me emphasize that for most of it the Keycloak team is aware and is working hard in moving forward. I started using Keycloak with Version 11 and a lot has changed for the better. > I think Keycloak is somewhat of a no brainer for large teams, but can be a dangerous traps for very small teams. I would not agree on that. You don't necessarily need a large team for operating Keycloak and smaller teams are probably not that big of an issue. At least not for operating Keycloak. What I feel to be more a problem is, that many (at least of our) clients are not understanding OAuth 2.0 and OIDC well, and therefore puts a larger burdon on support work. Also there must be at least someone very knowledgable of Keycloak to give guidance to the rest of the team, but in general I would not say it's dangerous. We have even a team operating their own keycloak and using our keycloak to perform OIDC federation (don't ask me why tho, I never understood it). [1] https://www.keycloak.org/2024/06/announcement-keycloak-organizations https://www.keycloak.org/2024/06/announcement-keycloak-organ... [2] https://github.com/keycloak/keycloak/issues/28745 https://github.com/keycloak/keycloak/issues/28745 [3] https://www.keycloak.org/docs/latest/release_notes/index.html#infinispan-marshalling-changes-to-infinispan-protostream https://www.keycloak.org/docs/latest/release_notes/index.htm...

uj6re 2y ago

open source: keycloak connect2id dex gluu closed source self hosted: adfs hosted: okta (auth0) google microsoft github amazon these are just the ones that were viable 2 years ago

mooreds 2y ago
Another closed source option, which can be self-hosted or used as a SaaS: FusionAuth (my employer). It also has a full featured plan which is free if you self host and is available via docker, etc.
orphea 2y ago
also open source: zitadel
- mffap 2y ago
  https://github.com/zitadel/zitadel https://github.com/zitadel/zitadel
orra 2y ago
Thanks, although connect2id doesn't look open source.
vemgar 2y ago
also open source: Authentik

mrweasel 2y ago

We run Apereo CAS pretty successfully. Originally to use the CAS protocol, but now that CAS (the protocol) has been deprecated, we're slowly migrating to OIDC. One sort of weird note about Apereo CAS, OpenID Connect can return data in two format, nested and flat. CAS is the only server I've ever worked with, that defaults to nested. Almost no clients supports this, but the server can be reconfigured to use flat. KeyCloak is also very good, but I'd run is as a container due to the quick release/update cycle. If I had to do our infrastructure over, I'd probably go for KeyCloak, just because it's the most used.

mooreds 2y ago
Hmmm. Here's details about using CAS as an OpenID Connect provider: https://apereo.github.io/cas/7.0.x/authentication/OIDC-Authentication.html https://apereo.github.io/cas/7.0.x/authentication/OIDC-Authe... Looks like it doesn't support multiple issuers: " CAS primarily supports a single issuer per deployment/host." Have you run into any issues with that? It also looks like it supports a number of optional standards: DPoP, JARM, PAR. Have you seen use cases for these?
- mrweasel 2y ago
  > Looks like it doesn't support multiple issuers Yeah, we only have the one issuer, so it's not a concern. For pretty much every KeyCloak project I've done, we have also favored doing separate deployments for separate issuers, so I'd say it's not much of an issue, in most cases. Regarding the optional standards, no. We've not run into an clients that would require or in many cases even support anything but the most basic OpenID Connect. I'm sure there's a point to supporting them, but I've never seen it being needed for your average use case.

taberiand 2y ago

https://ory.sh https://ory.sh has an open- source self-hosted option Hydra (and a number of other services)