6 ms·

> There's no need to start writing user login code tonight. I think it's worth pointing out that replacing Okta for most people isn't just doing login +MFA stu

> There's no need to start writing user login code tonight. I think it's worth pointing out that replacing Okta for most people isn't just doing login +MFA stuff. Sure, there's that part of it - but a lot of the value in going with Okta in particular is that so many third parties support integrating with them in ways that other Identity providers are just not supported. Account lifecycle stuff (via SCIM) is often limited to just Okta support for products. There's also the account lifecycle stuff so that HR doesn't have to tell you when they hire someone, they just add them into the HR system and all the things flow out from that. Similarly when someone leaves, you can have those workflows go and disable/delete their accounts.

Nextgrid 5y ago
But Okta is just hosted SAML or OIDC. The same can be achieved with self-hosted Keycloak. In fact, a third-party’s “Okta integration” should work out of the box with Keycloak or any other IdP.
- jiveturkey 5y ago
  It's not just that. The most important part of Okta is the directory integration, not the SSO part. For small companies that have never acquired anyone, it doesn't matter. It also makes user lifecycle someone else's problem. Very important. As a medium and larger sized company, when you have to tell your customers your homegrown IAM was pwned, you're in for a world of hurt. When you're just in the boat with everyone else who got popped, it's an easily recoverable incident.
  - ownagefool 5y ago
    If you have any sort of footprint, it's pretty much expected you'd have protective monitoring so you can articulate what these pwned accounts have actually achieved on your infrastructure. It doesn't really matter who runs your auth service, if the auth service getting pwned results in a reportable attack, you're in for a world of hurt. The next step is to articulate why this isn't your fault and that you did everything you reasonbly could have done to not get pwned. Do you have evidence to support you did your due dilligance on your provider?
- paxys 5y ago
  No, Okta also supports various forms of 2FA/MFA, Active Directory integration, LDAP and SCIM user provisioning. Not to mention the fact that even if there are open source alternatives out there, setting up servers, configuring them correctly and managing/updating them isn't exactly a simple enough operation for the average company admin.
  - compsciphd 5y ago
    for companies that are alrady gsuite users, what does okta provide over what one can get with gsuite saml integration?
    - paranoidrobot 5y ago
      GSuite's SCIM options are lacking. So for example if you want to use AWS SSO tied to GSuite, you have to manually manage users, group membership, etc inside AWS SSO. Similarly for a bunch of other products. A couple of companies I've worked for now use GSuite as their primary accounts, and while a ton of things authenticate through GSuite (either as a built-in integration, or as SAML) - when you onboard/offboard users it involves going into a bunch of different systems to create/invite, set up group memberships, and then later deactivate accounts. We're still considering Okta to solve all that workflow stuff. Yes, even after this event. I believe Okta can also do custom security flows that GSuite can't. So, if you're on a trusted device+network, then you might not need a 2FA challenge. Or conversely if you're trying to access a sensitive service - then always require a 2FA challenge every X hours.
      - compsciphd 5y ago
        yes my company makes us do the 2FA every 9 hours for github (so annoying) via okta, though apparently our gsuite logins via okta are much longer lived. though that sort of answers a followup Q, it would seem that there would be a market that punts the authentication to gsuite's saml, but automates the user creation and the like on the different services (and deactivation), but one still wouldn't have the "custom flows" as you said. but if the custom flows aren't that important, I'd rather trust google to handle my authentication than okta, and in my pseudo-okta without authentication scenario, even access to my pseudo-okta would authenticate via google.
- ryan_lane 5y ago
  Yes, you can achieve that specific part with Keycloak, and you may end up owned in a different, but equally awful way: https://www.keycloak.org/2021/12/cve https://www.keycloak.org/2021/12/cve There's nothing wrong with Keycloak, and me pointing at this CVE isn't meant as a gotcha. The point is that just because you're doing it yourself doesn't mean you're going to have better protection. Doing this well is difficult. Okta is a security company, and due to a well-organized, well-funded attacker, they were able to be breached. If a similar attacker is trying to breach you, you're likely going to get breached.
  - mbreese 5y ago
    > If a similar attacker is trying to breach you, you're likely going to get breached. I think the logic here is accepting that if an attacker is trying to breach you, you’re likely going to get breached. But, if an attacker is trying to breach someone else, you’re still safe(-ish). With a centralized service, you don’t have to be the target to feel the effect.
  - darkwater 5y ago
    But are $YOU, as one of the tens of thousand $YOU companies going to be spear headed in a dedicated, not automated way? Maybe, but I would say there is at least one or even two orders of magnitude difference with Okta or other well-known companies.
    - ivan_gammel 5y ago
      There's a cost efficiency point where this argument becomes valid. At small company sizes, where dedicated security team or an admin with sufficient expertise to do proper setup is unaffordable, risk of Okta breach is lower than risk of automated custom setup breach. When you are big enough to deploy self-hosted solution and maintain it for reasonable cost, then yes, I would agree with you, self-hosted setup may reduce risks. When does that happen? When your company has over 1000 people (to break even with your Okta spending) or when your revenue per employee is high enough to spend every year 200-300k€ just on security.
kevin_thibedeau 5y ago
Time for B2B services to support self-hosted installations so the security boundary stays in house.

Nextgrid 5y ago

But Okta is just hosted SAML or OIDC. The same can be achieved with self-hosted Keycloak. In fact, a third-party’s “Okta integration” should work out of the box with Keycloak or any other IdP.

jiveturkey 5y ago
It's not just that. The most important part of Okta is the directory integration, not the SSO part. For small companies that have never acquired anyone, it doesn't matter. It also makes user lifecycle someone else's problem. Very important. As a medium and larger sized company, when you have to tell your customers your homegrown IAM was pwned, you're in for a world of hurt. When you're just in the boat with everyone else who got popped, it's an easily recoverable incident.
- ownagefool 5y ago
  If you have any sort of footprint, it's pretty much expected you'd have protective monitoring so you can articulate what these pwned accounts have actually achieved on your infrastructure. It doesn't really matter who runs your auth service, if the auth service getting pwned results in a reportable attack, you're in for a world of hurt. The next step is to articulate why this isn't your fault and that you did everything you reasonbly could have done to not get pwned. Do you have evidence to support you did your due dilligance on your provider?
paxys 5y ago
No, Okta also supports various forms of 2FA/MFA, Active Directory integration, LDAP and SCIM user provisioning. Not to mention the fact that even if there are open source alternatives out there, setting up servers, configuring them correctly and managing/updating them isn't exactly a simple enough operation for the average company admin.
- compsciphd 5y ago
  for companies that are alrady gsuite users, what does okta provide over what one can get with gsuite saml integration?
  - paranoidrobot 5y ago
    GSuite's SCIM options are lacking. So for example if you want to use AWS SSO tied to GSuite, you have to manually manage users, group membership, etc inside AWS SSO. Similarly for a bunch of other products. A couple of companies I've worked for now use GSuite as their primary accounts, and while a ton of things authenticate through GSuite (either as a built-in integration, or as SAML) - when you onboard/offboard users it involves going into a bunch of different systems to create/invite, set up group memberships, and then later deactivate accounts. We're still considering Okta to solve all that workflow stuff. Yes, even after this event. I believe Okta can also do custom security flows that GSuite can't. So, if you're on a trusted device+network, then you might not need a 2FA challenge. Or conversely if you're trying to access a sensitive service - then always require a 2FA challenge every X hours.
    - compsciphd 5y ago
      yes my company makes us do the 2FA every 9 hours for github (so annoying) via okta, though apparently our gsuite logins via okta are much longer lived. though that sort of answers a followup Q, it would seem that there would be a market that punts the authentication to gsuite's saml, but automates the user creation and the like on the different services (and deactivation), but one still wouldn't have the "custom flows" as you said. but if the custom flows aren't that important, I'd rather trust google to handle my authentication than okta, and in my pseudo-okta without authentication scenario, even access to my pseudo-okta would authenticate via google.
ryan_lane 5y ago
Yes, you can achieve that specific part with Keycloak, and you may end up owned in a different, but equally awful way: https://www.keycloak.org/2021/12/cve https://www.keycloak.org/2021/12/cve There's nothing wrong with Keycloak, and me pointing at this CVE isn't meant as a gotcha. The point is that just because you're doing it yourself doesn't mean you're going to have better protection. Doing this well is difficult. Okta is a security company, and due to a well-organized, well-funded attacker, they were able to be breached. If a similar attacker is trying to breach you, you're likely going to get breached.
- mbreese 5y ago
  > If a similar attacker is trying to breach you, you're likely going to get breached. I think the logic here is accepting that if an attacker is trying to breach you, you’re likely going to get breached. But, if an attacker is trying to breach someone else, you’re still safe(-ish). With a centralized service, you don’t have to be the target to feel the effect.
- darkwater 5y ago
  But are $YOU, as one of the tens of thousand $YOU companies going to be spear headed in a dedicated, not automated way? Maybe, but I would say there is at least one or even two orders of magnitude difference with Okta or other well-known companies.
  - ivan_gammel 5y ago
    There's a cost efficiency point where this argument becomes valid. At small company sizes, where dedicated security team or an admin with sufficient expertise to do proper setup is unaffordable, risk of Okta breach is lower than risk of automated custom setup breach. When you are big enough to deploy self-hosted solution and maintain it for reasonable cost, then yes, I would agree with you, self-hosted setup may reduce risks. When does that happen? When your company has over 1000 people (to break even with your Okta spending) or when your revenue per employee is high enough to spend every year 200-300k€ just on security.

kevin_thibedeau 5y ago

Time for B2B services to support self-hosted installations so the security boundary stays in house.