MFA for Identity Access Management and Single Sign-On
Why you need MFA for IAM and SSO
Web-facing Single Sign-on (SSO) is with no doubt the users’ preferred IT service. To the point that the first question asked by job applicants has become “do you have an SSO in place?”, so the story goes. With a simple browser, a connection, and a single set of credentials, users can access their applications and work from anywhere and without the headache of remembering, changing, and managing application-specific credentials. What a relief! The downside is that anyone finding (i.e guessing, hacking, eavesdropping, phishing…) a valid user password has a complete access to that user’s application accounts and to all the information stored in these accounts (documents, transactions, customer contacts, emails…). Someone taking over a user account can also impersonate that user, fool his contacts, and make transactions on his behalf. Ouch.
As a domain administrator or a security professional, you have two options: ask users to change their passwords very often and to use complex passwords such as d0*#g17!bk – which would definitely make your SSO less appealing… Or use a frictionless MFA solution adding a layer of security that defeats attackers, even if they know the user password. With MFA, passwords can be much simpler, without risk. Guess which option users prefer, and which one you can realistically expect them to use.
Which SSO and IAM vendors are supported by inWebo MFA?
Over the years, our partners and our customers have implemented inWebo 2-factor solutions with Identity & Access Management, Single Sign-On, and Federation solutions including Forgerock OpenAM, Microsoft ADFS, Ping Federate, Gluu Server, Memority, WSO2 Identity Server, Simeio Solutions, NetIQ, Gigya, Shibboleth, Ilex International, Auth0, SailPoint, CA SiteMinder (now CA SSO), and probably many more we’re not even aware since our SAML 2.0, radius, and web services connectors work out-of-the-box.
We’ve not listed Okta or OneLogin here because we don’t have a sales-ready integration with them yet, only proofs-of-concept. If you want to use either of these products with a universal and secure MFA such as inWebo (see below why or when it makes sense), please contact us for confirmation.
inWebo 2FA for IAM and SSO
When signing in the first time (on a given day, from a given network, in a given context) to an application linked to your SSO, the legitimate user has to confirm that she initiated the access request. This can be done by entering a one-time code received in a short-text or generated with the inWebo Authenticator App or, more conveniently, simply by confirming the access request in the inWebo Authenticator App or even in the browser where the connection takes place, making the whole process frictionless even for users who don’t have a work phone (see inWebo 2FA options for more details)
How to implement 2FA for IAM and SSO
It’s quite straightforward:
- First, create an inWebo account for your organization (you can start below).
- Then, configure both this account and your IAM or SSO to trust each other. There are several options here, depending on your IAM or SSO product. For on-prem products, check if we have developed a specific module (this is the case for Microsoft ADFS, Forgerock OpenAM, Ping Federate, Shibboleth and a few others) because this is going to be the easiest option. For cloud products, or if there’s no module, you might have to use radius or SAML 2.0 (in the latter case configure your IAM or SSO as a Relying Party and your inWebo account as an Identity Provider). Finally, there are a few cases such as Gluu Server or Auth0 where you need to adapt a custom authentication script calling our API (this is the equivalent of a module for a cloud product)
- Finally, adjust the authentication policies and user on-boarding rules from the inWebo administration console.
There’s no server or proxy to install and configure, therefore you will save 2 days for other projects. Also, please note that our pre-sales and support engineers are here to help if you face any difficulty.
IAM vendor MFA or inWebo MFA?
Tough question. However, here are the main reasons why you should prefer the latter over the former:
- Vendor lock: inWebo MFA is more universal and supports a lot more applications. Not only other SaaS applications (including Office 365, G Suite) for which your IAM or SSO vendor’s MFA solution works, but also VPN, remote access, SSO, CMS, Windows Logon…
- Convenience: inWebo MFA uses cellphones and smartphones (SMS OTP, offline OTP, push OTP), but also browsers, thus making the whole process frictionless, including for users who don’t have a work phone.
- Performance and security: inWebo MFA relies on 3 independent and certified datacenters, it’s literally always available. Authentication takes place in certified Hardware Security Modules (HSM).
It’s your turn. You may
- Sign up for free for a basic account (10 user licences) and start implement inWebo MFA for your IAM or SSO. You’ll be able to upgrade this account at any time to get more licences or options. Nothing to lose but an item on your to-do-list.
- Evaluate inWebo for free and without commitment for 30 days. This sounds like the procrastinator package but actually MFA is a serious topic and no one will blame you for taking your time to make sure that inWebo is the right fit. Note that we have project management, consulting, and integration partners trained in our solutions whom you can ask for an evaluation and a PoC.
- Request a customized demo. We’ll be happy to show and explain the basics of our solution and answer your questions.