I have been tasked with spearheading an initiative at work to migrate our SSO off of Google onto Authentik. I know Fly can use Google SSO, we have that setup as required for our orgs. I don’t see a way to use a custom SAML or OAuth or OIDC provider instead, unless I am missing something (which is always possible)? Or is this something on the roadmap?
Our company’s owner recently had his Google Workspace account suspended for several days due to “suspicious logins” that were completely legitimate from his normal devices and even as our Workspace’s super admin I could not unsuspend him, it took a ticket to Google support and several days. Needless to say he wasn’t happy about being locked out of literally every company system for several days so the mandate is we need to own our auth system now and after looking into the different options I am going to move us to Authentik. With Fly being such a core system for our engineering team, I’d hate to have to fall back on passwords and a password manager for it.
You’re not missing anything, we only support Google and GitHub as identity providers for organization SSO. There currently isn’t a way to point an org at a custom SAML, OAuth or OIDC provider and I also don’t have a roadmap or an ETA to share on custom OIDC or SAML either.
For such an important account, I’d myself prefer zero dependencies. Just set up username, password, and 2FA. It’s sensitive to losing a phone of course, but that’s not a disadvantage against another SSO provider.
Apps like 2FAS or an iPhone’s built-in TOTP support are backed securely to iCloud and thus would survive phone loss. I’m sure there are similar alternatives on Android.
The nice thing about an idp is its one source of truth for access, and we can enforce very strict requirements like Yubikeys for 2FA which strangely there are a lot of services that still don’t support those, but our Google Workspace did, and Authentik does.
There’s no way of setting a custom IdP; only Google and Github are supported for SSO. There’s also nothing in the roadmap for this. I know it’s not the answer you wanted to hear but it bears being transparent so you can plan accordingly.
True, but I assume there’s an even easier route back in - have more that one person in an organisation, and ask a colleague to temporarily reset one’s 2FA requirement.
> have more that one person in an organisation, and ask a colleague to temporarily reset one’s 2FA requirement.
Native TOTP is per user/person, not per organization. So if user A and user B are in org Z and user A loses their TOTP codes, user B can’t do anything - we need a full identity verification process to reset A’s TOTP.
I’ve not done that with Fly, but it seems to me to be a normal workflow on self-service admin systems - GitHub, Bitbucket, etc. The security check is the colleague, having at least the same permissions as the locked-out user, who is permitted to remove the 2FA from that user. The user can then go through the reset password workflow before adding 2FA again (with a different provider if they wish).
See that makes using usernames and passwords even more of a terrible solution because we’re stuck with Fly 2FA which idk that we can force users to use, doesn’t support Yubikeys, and if someone loses their authenticator IT can’t reset it, we’re back to several days for a ticket.
Honestly given other hosting providers do support this we many have to seriously reconsider I use of Fly over this.
Hi again - You’re correct that native TOTP cannot be enforced at the organizational level. Using a third-party IdP (Google, Github) allows you to centralize that enforcement and is the solution we recommend - though I have the full context here and understand it might not be ideal for your use case.
You can use a Yubikey in TOTP mode, though if someone loses the physical token that’d be an issue requiring a support ticket to get sorted out.
As mentioned, the way it’s currently implemented may not be a good fit for you, but it bears being clear about the available functionality. Hope this information helps you make an informed decision either way!
(@fnfvdb - a backgrounder on post title changes. Myself and @mayailurus are customers and volunteer helpers on the forum. Since we’ve contributed a fair bit, we get small permission bumps, one of which is to edit titles. We often use this power, like editors on Stack Overflow, to make threads more findable for future users; since others may have the same question.
There isn’t an editing culture here, but rollbacks are non-optimal, as it may result in future users posting a duplicate question, if they are not easily able to find an earlier instance.)