0

My company provides a single SaaS product for corporate clients.

For one client we are implementing SSO with them as authentication provider (via Azure AD/SAML for now, but the library we are using is extensible).

The same client has asked us to implement MFA.

My gut reaction is that this would result in a weird hybrid system where both client and service provider would be responsible for managing authentication systems with (canonical) user data. I would much prefer to have a single owner for authentication stages, and have SSO defer to the client who can choose to add/enforce MFA as they see fit.

However, I think what they are asking is technically feasible, by implementing a two-step MFA login process using secure cookie for the SaaS system (not considering hand-rolling, just an assumption about mechanism from the library).

Is there any industry standard advice for this kind of setup? E.g. is it inadvisable due to split responsibilities, or even considered insecure? Or if is this a more normal setup (and my concerns overblown), are there important details that need to be taken account of?

Neil Slater
  • 51
  • 6

1 Answers1

1

I don't think there's a full-fledge best practice doc out there (could be wrong), but what you describe is not uncommon. In services like Auth0, you can enforce 2FA at the Auth0 level (let's call this SSO level), while still using an external idp. It does get very weird when the idp itself enforces 2FA though.

For example, I use Auth0 to SSO into a SaaS account. In Auth0 I can configure 2FA, but the idp also enforces 2FA as well. Hence every login requires me to tap my yubikey twice. Not a big deal, but imagine if it were a soft-token.

It's also worth noting that centralizing the 2FA requirements at the SSO provider reduces the need to replicate it across multiple idps. But from a user perspective, it could be quite cumbersome, as logging onto multiple SaaS would require individual registered 2FAs (at best this is tapping the yubikey multiple times) but at worst it could be registering different soft-tokens on their phone. Centralizing 2FA at the IDP level, would require the user to login only once to their IDP, and from there on be able to seamlessly login into different SaaS providers without requiring additional authentication.

Pro's and cons I guess.

keithRozario
  • 3,571
  • 2
  • 12
  • 24
  • Interesting to mention a split between SSO and IDP services (I was considering Azure AD/SAML to be provding both in one service in my question, unless I am misunderstanding what you describe?). In my scenario, the company is asking to enforce 2FA in the SaaS system, but we will not be provding any IDP services - all user identity held in Azure. All user data will be held by a third party - although of course if we implement 2FA in the SaaS we will need to hold 2FA secrets. Does your answers still apply in that case, would you consider the SaaS to be an IDP (or us adding 2FA makes it an IDP)? – Neil Slater Apr 20 '22 at 06:17
  • You're quite right, in most case the IDP and SSO provider are the same. But there are different functions -- for example, AWS SSO provides SSO functionality, and can also act as the IDP, but can also utilize AzureAD, Okta etc as IDPs. I think the industry is moving in a direction where these two functions would be provided by different systems (just my guess!). – keithRozario Apr 21 '22 at 01:14