Explore our platform and learn how it can help your application shine.
Learn about modern authentication techniques and best practices.
Learn about access management practices and technologies.
Learn to manage user accounts and access at scale.
Understand multi-tenancy, a foundation of shared computing.
Learn how to design and build successful SaaS applications.
Understand what is required to provide an enterprise-ready product.
Understand the uses and benefits of Attribute-Based Access Control.
Learn how Single Sign On (SSO) can improve security and UX.
Learn about OpenID Connect, an open authentication protocol.
Learn about SAML, a popular SSO protocol.
Learn about our history, our team, and our mission.
In our previous posts we discussed in detail the generation of JWT tokens, how to secure them, and how to secure your users’ credentials and data on the databases.
That’s all great. But as the latest incidents — particularly Twitter’s Breach and Garmin’s ransomware — show, we need to question ourselves on how we should enhance the protection of our SaaS application users in order to eliminate the risk of sophisticated account takeovers and password breaches.
One of the most popular methods for enhancing SaaS application security is by applying SSO and MFA. But how do we implement them and what exactly does it mean for our users?
Learn first hand how easy it is to get your SaaS enterprise ready.
When looking at enterprise grade applications, you can see that most of them allow signing in using Single Sign On. Enterprise ready applications will also support SAML as the SSO method.
The concept is clear. IT management wants to manage the employees’ identity in a central place. When a user leaves the organization his identity goes with him. IT cannot allow John.firstname.lastname@example.org to keep on using his acme.com identity after leaving the organization, right?
From the users’ perspective the motive is clear as well. Users sign up on multiple SaaS applications and websites and need to set their password on each of the applications and sites. In the best case scenario they will use a random password for each sign up. In the worst case and more common scenario they will use the same password for all SaaS applications. In case of a breach in one of them, the attacker will gain access to all of the other applications on which the user is registered.
So IT wants control, and users want to avoid “password hell”. What’s the solution in this case? We need to use a Single Sign On (SSO) approach that will be controlled, monitored and provisioned by the IT administrator of the company which wants to use our SaaS service.
One of the most popular methods for enterprise SSO is the use of SAML
Security Assertion Markup Language (SAML) is an open standard that allows identity providers (IDP) to pass authorization credentials to service providers (SP). In other words, assuming you have a single identity at your identity provider, you should be able to login to all surrounding applications using that single identity.
The SAML flow has 2 main actors:
Let’s see this flow in action.
For our example we’ll use a SaaS application called DemoSaaS. DemoSaaS is used by acme.com users. In our flow DemoSaaS is the SP and acme.com’s ActiveDirectory is the IDP.
So we discussed the SAML requests and SAML responses. But what exactly is SAML?
SAML is basically XML with assertion units. The spec and protocol for SAML2 was written and maintained by OASIS where the full specifications of the protocol can be found.
An example of SAML authentication request will look like this for DemoSaaS (Our service provider):
Upon successful login, the IDP will return the following Authentication Response:
ℹ️ There are a few items to pay attention to in the flow above:
Multi-factor authentication (MFA) refers to an authentication method where the user is required to present at least 2 valid “evidences” that he is actually the user he claims to be.
Before he does that? He cannot login…
One of the common types of MFA is Two-factor authentication (also known as 2FA). 2FA verifies that in addition to “something you know” (for example username and password) you can verify your identity via “something you have” (for example phone for SMS / Authenticator app).
The common factors you can find out there, sorted by security level, are:
The second factor of authentication here proves that the user which is trying to perform the action in the system is actually the one that he claims to be.
The common flows on which we find requirements for 2FA validation:
OK. So we have the flows. But what actually happens behind the scenes?
Let’s take the login challenge for example (the components were simplified for the visibility of the flow):
Cool! We now have a validated user through two different factors of authentication! The login process is secured!
As per the usual, there are a few considerations for choosing the right 2FA method:
So the key here is to balance between your security requirements and user experience goals.
The essentials of security on every SaaS application require us to protect the users of our SaaS application.
This is basically a non-negotiable requirement, both from a compliance point of view and especially in the face of the growing scope and sophistication of breaches.
As SaaS owners we need to enable an SAML IDP sign on and enhance account security by providing an additional factor for our users’ authentication method.
Start For Free
Rate this post
0 / 5. 0
No reviews yet