Best Practices for Two-Factor Authentication: Centralized IdP vs Duo Web SDK

0
3
Asked By TechieTurtle93 On

I'm exploring effective ways to enforce two-factor authentication for various internal web applications such as NetBox and Grafana. My initial plan is to set up a centralized identity provider, like Keycloak or Authentik, and integrate it with our LDAP for MFA through Duo. This approach would centralize our authentication, simplify app configurations, and allow for better scalability in the long run.

However, my team has some reservations. They worry that if the IdP fails, we could potentially lose access to multiple applications, forcing us to SSH into servers to recover access and modify backend authentication settings. Because of this concern, they prefer the idea of using Duo's Web SDK directly within NGINX or Apache in front of each application, aiming to avoid introducing another critical service into our infrastructure.

I'm finding it hard to understand this perspective since using the Web SDK seems like it could complicate maintenance and distribute authentication across many services, as opposed to centralizing it. What I'm really looking for is real-world feedback from those who have tried the Duo Web SDK over a centralized IdP for solid operational reasons rather than just ease of setup. Are there instances where the SDK approach works better?

As a middle ground, my manager suggested we run Authentik while also having the Web SDK ready to go, which feels like it might add unnecessary complexity. I just want a reliable, maintainable MFA setup without the headache of future issues. Has anyone navigated these waters and can share what went well or poorly regarding failure recovery and long-term operations?

5 Answers

Answered By MfaMaster93 On

Consider Duo's SAML proxy option. It directly connects to LDAP and manages MFA without the extra complexity of the Web SDK. Keycloak is indeed powerful but can be complicated, especially for setups that require multiple tenants. If you're looking for a straightforward solution that still offers robust features, the SAML proxy might be the way to go.

Answered By TechSavvyNerd7 On

It's important to implement a 'break glass' account on your IdP to avoid being locked out during outages. While the team worries about adding one central point of failure, moving to multiple critical services could be counterproductive. We successfully use NetIQ as our IdP, which allows for easy management and multiple accounts for emergencies. This setup helps reduce the risk of a 'maintenance nightmare' later on.

Answered By FailSafeGuy88 On

Either way, if Duo or LDAP goes down, you're facing downtime. But centralized authentication has its advantages. If it breaks, you'll still have some level of control, while managing multiple instances of Duo across different applications can get messy very quickly. My approach has always favored centralized systems; they streamline management when built correctly.

Answered By UserFriendly101 On

In my experience, Keycloak has proven to be very reliable for authentication. If you adhere to a good rollout strategy—test in development, let it run in non-production, and then move to production—you'll find it robust. The risk of a single point of failure usually lies with LDAP, as we experienced multiple outages there, while our Keycloak had minimal issues. Centralized authentication is a lot easier to manage as you scale up. If you're really concerned, you could always have a backup Keycloak instance as a failsafe.

Answered By SsoAce202 On

Having SSO is key; it simplifies managing various accounts across different applications. A centralized IdP might seem like a risk, but if you have contingency plans in place for when it goes down, it can work quite well. Just keep in mind that Duo could become a vulnerability as well, as it has had outages. Balancing security with access is crucial here!

Related Questions

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.