5 ms·

Great article but if I wanted to explain it to somebody in one sentence I'd say "It's like sign-in with google, but for enterprises", by "enterprises" i mean "m

Great article but if I wanted to explain it to somebody in one sentence I'd say "It's like sign-in with google, but for enterprises", by "enterprises" i mean "more shit" - xml/soap/overcomplicated kind of shit.

sascha_sl 7y ago
as the resident keeper of the keycloak (aka RedHat SSO) which can and does do both SAML and OIDC (what google uses) in our organization I only sort of agree. SAML is overcomplicated, but OIDC also has a lot of bloat, although it's more optional there. It's just trying to solve too many problems for too many parties at once. Back and front channel logout, your choice of symmetric or asymmetric crypto, at least 3 types of different tokens, and 3 ways to get subsets of them with various subtypes, depending on if you're a client application, a web application that can redirect, a web application that can't redirect, an app on a TV... Oh, and did I tell you about the authorization framework? With assessment servers? There's that too! Thankfully in the real world both seem to be implemented in the absolute minimal way to get things working.
- Edmond 7y ago
  Cheers for keycloak, title pun intended :) We use it for Solvent (https://codesolvent.com https://codesolvent.com) login to product instances and it works excellently.
  - i_haz_rabies 7y ago
    How have you guys solved "from scratch" configuration for keycloak? I've worked with it a bit over the years and I've never found a way to get it into a state I want programmatically without hacky bash scripts and modifying the json templates.
    - Edmond 7y ago
      Maybe we got lucky with the configuration but we use the approach documented for the keycloak-saml-adapter with Jetty as the app server. There is still a lot work done to ensure keys are generated in the proper locations and that necessary product id values (corresponds to SAML SP entityID) are generated. In short, it is not a simple plug-n-play, lots of hacking to get the result we needed but the adapter itself does what it needs to do.
    - sascha_sl 7y ago
      believe it or not, but we do FROM jboss/keycloak:9.0.0, add a theme jar, throw it on k8s with 2 pods and a postgres behind it and that's it. Our clients are mostly SAML SaaS software and our own implementation of gatekeeper (which is also a kubernetes ingress) with short lifetime OIDC ID tokens, long lifetime refresh tokens and seamless background refreshing.
swiley 7y ago
So much easier than SSO would be installing certs on all the client machines when they’re provisioned. Support for client side certs on iOS sucks balls of course so no one does this.
- lvh 7y ago
  I love mTLS a lot more than the average bear[0], but the main reason I see companies deploy SSO is centralized access control and access management (particularly for offboarding), which client certs are only a tiny fraction of. Since they're typically long-held, you're now proposing either a rigorous revocation scheme or continuous reissuance, and neither seems to be deployed anywhere outside of maybe the DoD. (And Gemini? Maybe?) So: as much as I'd love that to be the case, I don't think that we're "iOS' UX for client certs" away from that being a plausible replacement. [0]: Thomas Pornin is far from average!
  - swiley 7y ago
    Why are the people who left taking corporate devices with them? Or alternatively, why are you trusting new employees phones? That’s absolute insanity.
    - lvh 7y ago
      They don't need to take a corporate device with them. They need to have exfiltrated a credential during the (long) time they had alone with the laptop. You trust new employees' phones the way you decided to trust anything else: a risk assessment based on what the company is willing to bear, taking into account compensating controls like MDM. Are you suggesting "no creds that live outside of trusted elements physically tied to a device we own" is an ubiquitous property of access management?
      - swiley 7y ago
        > no creds that live outside of trusted elements physically tied to a device we own. I’ve never worked full time at a software company that allowed credentials on employee personal devices. Supposedly because most consumers are up to their eyes in malware, often from the moment they buy the devices, not because the employees are untrustworthy (it would be difficult to have a functioning business where you can’t trust the employees.)

sascha_sl 7y ago

as the resident keeper of the keycloak (aka RedHat SSO) which can and does do both SAML and OIDC (what google uses) in our organization I only sort of agree. SAML is overcomplicated, but OIDC also has a lot of bloat, although it's more optional there. It's just trying to solve too many problems for too many parties at once. Back and front channel logout, your choice of symmetric or asymmetric crypto, at least 3 types of different tokens, and 3 ways to get subsets of them with various subtypes, depending on if you're a client application, a web application that can redirect, a web application that can't redirect, an app on a TV... Oh, and did I tell you about the authorization framework? With assessment servers? There's that too! Thankfully in the real world both seem to be implemented in the absolute minimal way to get things working.

Edmond 7y ago
Cheers for keycloak, title pun intended :) We use it for Solvent (https://codesolvent.com https://codesolvent.com) login to product instances and it works excellently.
- i_haz_rabies 7y ago
  How have you guys solved "from scratch" configuration for keycloak? I've worked with it a bit over the years and I've never found a way to get it into a state I want programmatically without hacky bash scripts and modifying the json templates.
  - Edmond 7y ago
    Maybe we got lucky with the configuration but we use the approach documented for the keycloak-saml-adapter with Jetty as the app server. There is still a lot work done to ensure keys are generated in the proper locations and that necessary product id values (corresponds to SAML SP entityID) are generated. In short, it is not a simple plug-n-play, lots of hacking to get the result we needed but the adapter itself does what it needs to do.
  - sascha_sl 7y ago
    believe it or not, but we do FROM jboss/keycloak:9.0.0, add a theme jar, throw it on k8s with 2 pods and a postgres behind it and that's it. Our clients are mostly SAML SaaS software and our own implementation of gatekeeper (which is also a kubernetes ingress) with short lifetime OIDC ID tokens, long lifetime refresh tokens and seamless background refreshing.

swiley 7y ago

So much easier than SSO would be installing certs on all the client machines when they’re provisioned. Support for client side certs on iOS sucks balls of course so no one does this.

lvh 7y ago
I love mTLS a lot more than the average bear[0], but the main reason I see companies deploy SSO is centralized access control and access management (particularly for offboarding), which client certs are only a tiny fraction of. Since they're typically long-held, you're now proposing either a rigorous revocation scheme or continuous reissuance, and neither seems to be deployed anywhere outside of maybe the DoD. (And Gemini? Maybe?) So: as much as I'd love that to be the case, I don't think that we're "iOS' UX for client certs" away from that being a plausible replacement. [0]: Thomas Pornin is far from average!
- swiley 7y ago
  Why are the people who left taking corporate devices with them? Or alternatively, why are you trusting new employees phones? That’s absolute insanity.
  - lvh 7y ago
    They don't need to take a corporate device with them. They need to have exfiltrated a credential during the (long) time they had alone with the laptop. You trust new employees' phones the way you decided to trust anything else: a risk assessment based on what the company is willing to bear, taking into account compensating controls like MDM. Are you suggesting "no creds that live outside of trusted elements physically tied to a device we own" is an ubiquitous property of access management?
    - swiley 7y ago
      > no creds that live outside of trusted elements physically tied to a device we own. I’ve never worked full time at a software company that allowed credentials on employee personal devices. Supposedly because most consumers are up to their eyes in malware, often from the moment they buy the devices, not because the employees are untrustworthy (it would be difficult to have a functioning business where you can’t trust the employees.)