Frontegg https://frontegg.com Platform for SaaS Applications Thu, 29 Jul 2021 19:27:44 +0000 en-US hourly 1 https://frontegg.com/wp-content/uploads/2020/06/favicon.png Frontegg https://frontegg.com 32 32 Best Practices for SaaS Development Using Microservices https://frontegg.com/blog/best-practices-for-saas-development-using-microservices https://frontegg.com/blog/best-practices-for-saas-development-using-microservices#respond Thu, 29 Jul 2021 12:17:41 +0000 https://frontegg.com/?p=6987 One question startups always face when developing software for their product is: Which SaaS architecture pattern to choose—monolith or microservices? How to Choose the Right SaaS Platform Architecture for Your Startup I would suggest starting with what’s simplest for now, and planning for the future. That being said, when starting a quick POC it might […]

The post Best Practices for SaaS Development Using Microservices appeared first on Frontegg.

]]>
SaaS Development Using Microservices
Image by Markus Spiske

One question startups always face when developing software for their product is: Which SaaS architecture pattern to choose—monolith or microservices?

How to Choose the Right SaaS Platform Architecture for Your Startup

I would suggest starting with what’s simplest for now, and planning for the future. That being said, when starting a quick POC it might be easier to do a quick monolith, but when planning a full production environment, microservices is the proper way to do it. Architectural decisions, once taken, shouldn’t be considered final for the whole life of the product. Hence, a change from a monolith to a microservice Saas architecture is a possibility to be considered, even though it might get harder to change once the product starts to grow in complexity. Sam Newman’s book Monolith To Microservices addresses this topic pretty well and gives an idea of what to expect when planning this architectural change.

Another aspect to consider is this: How do you provide your product to your customers?
Customers always come first.  And customers worry about data protection when using software.

What Are the Features of a Good SaaS Architecture Design?

To provide a complete service to your customer, you must consider three components when thinking about SaaS application architecture.

Security

This component’s scope is related to how your solution will handle user data and access to that data. It is imperative to create a robust security process that can keep up with a growing customer base. This way, the product will be able to scale without risking security breaches and cement its position in the market.

Data Privacy

Nowadays, data privacy is a hot topic and a significant aspect of every publicly available online service. This topic is also related to legal and regulatory norms depending on the country of operation and can be a complex topic. It is essential that your solution architecture keeps data privacy in mind.

Customization

A product can increase its possibilities of success by engaging with more users and onboarding them as regular customers of the service. This will be easier if you can customize the solution to target a broader range of users and allow product growth.

With the previous points in mind, let’s have a look at the benefits of SaaS architecture under two different architectural approaches for structuring your product: single and multi-tenancy.

Image Source

The Best Use Case for Single-Tenant Architecture

First of all, let’s understand what single tenancy means and its pros and cons.

If you plan your product as a single tenancy architecture, you’ll have to provide a single instance of the software and the respective infrastructure to a single customer. This approach will give the customer their own version of the code and independent database.

Pros

  • Security: increases the protection of each customer’s data and decreases the possibility of data leakage between customers since each software instance has its own database.
  • Customization: increases the possibility of custom evolution of the solution throughout time.
  • Controlled Evolution: each customer can choose which solution updates to apply and when to do it.

Cons

  • Provisioning: every time a new customer is onboarded, new infrastructure needs to be provisioned.
  • Increased Cost: having multiple infrastructures increases operational costs.

This is the best SaaS enterprise architecture in situations where the product core value is related to security and reliability. You want to evolve different customizations of the product per customer.

An example is a FinTech startup that provides unique and customized models for financial data processing for each of its customers. Each customer can choose the continent/country they want to store their data in. In this case, each customer will have their own implementation of the software and database, which means that each customer will have the code in a separate repository. Each repository will be deployed to a cloud provider and evolved with its own CI/CD process. Similar to the code, each database will also need to be handled separately and hosted in the customer’s geographic region.

The Best Use Case for Multi-Tenant Architecture

Now that we know what to expect from a single tenancy architecture, let’s look at the multi-tenancy approach.

With a multi-tenant approach, the software and respective infrastructure are shared by multiple customers. All customer data lives in a shared database.

Pros

  • Cost Reduction: one infrastructure to support all customers helps decrease operational costs.
  • Easy Updates: changes to the solution are rolled out to all customers at once.
  • Customer Onboarding: a single onboarding process for all customers makes the process of acquiring new customers easier.

Cons

  • Performance:  if all customers start to use the solution heavily, performance might decrease due to the number of requests.
  • Security:  if an external malicious party has access to the system data, it might access all customer’s data.
  • Single Point of Failure:  if the solution is down, it is down for all customers.

Multi-tenant SaaS architecture is the best architecture for SaaS in a case where the startups start growing their customer base and wish to take advantage of the pros listed above. An example is an online book store with one website for all customers. The data relating to books and all customer’s purchases are stored in the same database. In this case, a single implementation of the software and respective database can be deployed to a cloud provider and evolved with a single CI/CD process. A cloud-based SaaS architecture would be great for this.

Single-tenant vs. Multi-tenant: Which is Better?

As we can see from the previous sections, each architecture type has its own value and can be useful in the right use cases. If you are concerned about security, go with a single-tenant architecture, but if your worries are related to operational costs, pick a multi-tenant architecture.

Nowadays, multi-tenancy architectures are more popular as they don’t require much maintenance, and the product evolution is automatically propagated to all customers. Multi-tenancy is also the easiest way to maintain intensely developed product solutions.

Five Enterprise Architecture Frameworks for SaaS Startups

When a startup starts to get traction and needs to scale, there is time to pick a framework to help structure the company and create a path for the future.

To achieve structured growth, the company can choose to adopt one of the following enterprise architecture frameworks. Let’s have a quick look at what each of these frameworks stands for.

Zachman Framework for Enterprise Architecture

The Zachman Framework for Enterprise Architecture was created in the 1980s and named after its creator, John Zachman. This framework aims to:

  • have a base understanding within the realm of a company’s IT systems
  • create architectural representations that bridge with business concepts
  • evaluate operational tools and methodologies and their relationship with one another; and
  • study tools that aid the construction of IT applications and compare them to understand which one is the best for the job.

The Open Group Architecture Framework (TOGAF)

TOGAF has been around for 25+ years. With a development process known as Architectural Development Method (ADM), it is composed of the following parts:

  • Modular Structure—the TOGAF standard is composed of modules that one can add incrementally
  • Content Framework—provides a detailed model of architectural work products
  • Extended Guidance—it allows teams to extend the core framework and create an integrated hierarchy of architectures
  • Architectural Styles—the TOGAF standard is designed to be flexible, and it can be used with various architectural styles.

Federal Enterprise Architecture Framework (FEAF)

FEAF is a management best practice for aligning business and technology resources. Originally used by the United States Government, it has become famous among private enterprises.

Gartner’s Enterprise Architecture Framework

Gartner, a global leader in IT research, has put forth a set of best practices for enterprise architecture solutions throughout the years. Its process focuses on evaluating the enterprise’s current state, identifying technologies to invest in, and determining the processes needed to achieve the desired future state.

NIST Enterprise Architecture Model

Originating in the 1980s, the NIST Enterprise Architecture Model aims to connect a company’s business, information, and technology variables and create an enterprise architecture. It is composed of a five-layer model:  

  • Business Architecture—understand the business requirements and drive the information architecture
  • Information Architecture—represents the types of content gathered from requirements
  • Information Systems Architecture—automated and procedure-oriented information systems
  • Data Architecture—describes the access and use of data
  • Data Delivery Systems—technical implementation of the data architecture

Independent of the enterprise framework, the startup chooses to achieve growth. The architecture implementation needs to follow a set of best practices to guarantee the quality of the product. Let’s have a look at some of the best practices related to microservices architecture.

SaaS Architecture Best Practices

Image Source

When building the architecture of SaaS, you should follow a set of SaaS architecture best practices that will guarantee that your solution will grow with solid foundations. Let’s go through some of the best practices that should be followed.

Highly Performant

Performance is vital when building a service that is to be consumed by a multitude of customers. To grow the customer base, it’s essential that the application doesn’t reach the market while still slow. Otherwise, new user adoption will be more difficult.

Scalable

The adopted solution should be highly scalable and allow the product to grow by adding new customers and keeping a good level of service. This point is usually a big challenge for startups, but when they get it right, it’s half of the way to having a good product on the market.

Highly Available

Once the solution is ready, it’s essential to have it constantly available and reduce downtime to zero (or at least aim for that mark). A good infrastructure is vital to having high availability. Having a cloud SaaS architecture and having redundancy related to data and services are the pillars to achieve high availability.

Engaging User Experience

Fundamentally, customers can interact with the service and have a good user experience. It’s one of the main factors that make customers annoyed or even cancel service subscriptions, so pay a lot of attention to this point.

Monitoring

This point is fundamental to tracking how the solution is performing while customers are interacting with it. Create a set of metrics related to technical aspects of the solutions and a set related to business metrics. These metrics can be displayed using dashboards or reports. The point is to have feedback and a way to understand how the solution is performing.

Conclusion

Building a product isn’t just about code or choosing an architecture. As we have seen when going through the sections of this article, it includes:

  • Considering how to provision your solutions to your customers to ensure sustainable growth
  • Choosing an appropriate framework once the company starts to scale to support the growth effectively
  • Following best practices when developing the system

In conclusion, it is a long path filled with important decisions that should be thought out from the beginning so that the risks of failure can be minimized and the chances of successful growth increased.

The post Best Practices for SaaS Development Using Microservices appeared first on Frontegg.

]]>
https://frontegg.com/blog/best-practices-for-saas-development-using-microservices/feed 0
The 8 Pillars of Self Service in SaaS Applications https://frontegg.com/blog/the-8-pillars-of-self-service-in-saas-applications https://frontegg.com/blog/the-8-pillars-of-self-service-in-saas-applications#respond Thu, 22 Jul 2021 14:50:20 +0000 https://frontegg.com/?p=6960 Software-as-a-Service (SaaS) applications are reaching 100% adoption as the world gravitates towards working from home and digitized online services. But this space is metamorphosing with the rise of SaaS self-service, the new standard in software development. This allows users to onboard alone and get started without any manual intervention. Take a look at successful SaaS […]

The post The 8 Pillars of Self Service in SaaS Applications appeared first on Frontegg.

]]>

Software-as-a-Service (SaaS) applications are reaching 100% adoption as the world gravitates towards working from home and digitized online services. But this space is metamorphosing with the rise of SaaS self-service, the new standard in software development. This allows users to onboard alone and get started without any manual intervention. Take a look at successful SaaS offerings like Datadog, Logz.io, and Figma. They understand that users don’t want to be interrupted or contacted anymore. Frankly, don’t we all wish this would happen? Let’s learn more about the self-service trend. 

Besides the aforementioned examples, the shift to self service is evident across all sectors. You have self-service in productivity software like Asana, ClickUp, and Slack. This is clearly happening also in marketing automation with apps like HubSpot and Marketo. As the saying goes – numbers don’t lie. As per a recent Frontegg survey, over 77% of applications already have at least some self-service capabilities. 

The Cornerstones of Self-Served SaaS Applications

#1 – Signup – The modern SaaS user wants versatility when it comes to signing up and getting started with SaaS applications. This is typically done by implementing “Freemium” versions that elevate onboarding and adoption metrics. 

The same thing applies to the logging in process. Preferences may vary from sector to sector or as per geographical locations. Some want a Single Sign-On (SSO), while security conscious users may prefer Multi-Factor Authentication (MFA) or passwordless logins. In many cases, a lack of flexibility at this stage may result in unexpected churn, especially when it comes to SaaS for enterprise. 

From the SaaS development perspective, this stage involves dynamic user and customer lists that need to be managed on an ongoing basis, not to mention the various signup and login analytics requirements that grow as you scale up.

#2 – Onboarding – Gone are the days when application users sent emails to support teams or waited on the phone for minutes. These practices are simply not acceptable anymore. The SaaS app owner has to inject self service into this crucial stage, which is where the customer basically makes the decision to stay or upgrade. Popups and tooltips need to be implemented seamlessly with real-time insights.

The numbers are clear on this one as well. The aforementioned Frontegg survey shows clearly that over 60% of SaaS application users prefer live and online onboarding without getting live calls from support professionals.

#3 – Documentation – The same applies also to documentation. Self-service documentation is one of the key ingredients in the “SaaS scaling sauce” today. The numbers say it all. Almost 15% of startups fail due to not addressing their customers’ needs. In other words, a mature self-service SaaS application needs to have an online knowledge base to reduce ticketing and elevate customer satisfaction.

More and more self service SaaS applications are also adopting interactive chatbots to encourage users to engage with their knowledge base. Times are changing, with users looking to interact directly with the application for instant engagement.

#4 – Support – Lack of support for “core elements” is arguably the biggest contributor to accelerated churn and brand damage. As per Microsoft, 96% of SaaS users say that customer self service is most important to them, especially when it comes to basic actions like controlling profile settings, adding users, managing roles and permissions, accessing audit logs for compliance purposes, etc.

Live chats (ideally with integrated pre-chat forms) are taking over the SaaS universe, with 65% of users preferring it over phone calls and emails. Just like in the onboarding stage, users looking to engage with the application will consider upgrading or staying only if questions are answered fast. The more tickets and emails you have, the less chance you have at achieving this goal.

#5 – Administration and Governance – While scaling up your SaaS offering, you will need to step up your user management capabilities pretty fast. This will obviously put added stress on your development and IT teams, something that may affect the time and effort investing in improving your core technology. The more you embrace self-serving solutions for these needs, the better your performance will become.

Related: Roles and Permissions Handling in SaaS Applications 

In other words, once you have self-service baked into your SaaS application, all users become “independent entities”. This means that they don’t need third-party intervention while adding new colleagues to their account, controlling the security aspects of the usage, managing billing (more on this later), and more. These are the true continuous self-service features that drive growth and satisfaction.

#6 – Analytics – With so many users and subscription plans in play, SaaS developers and executions can lose track very fast. With thousands of users upgrading, downgrading, or just joining, you need to implement the right APIs to get access to usage reports, integration performance information, and other data that will eventually help you bolster engagement and in-app sales metrics. 

#7 – Subscriptions – While we are at it, subscriptions are probably the biggest business revenue driver in the modern Product-Led Growth (PLG) SaaS application. There are many functions that need to be self served for smooth business performance. Some functions include, billing, invoicing, and limitation enforcement, all backed up by comprehensive usage data extraction. There is also A/B testing.

Subscription management is a key part of the SaaS self service puzzle. You must achieve accuracy when it comes to billing and account information, while keeping involuntary churn (expired/changed credit card numbers, technical declines, outdated PII, etc.) at a minimum. You can avoid these issues with automated dunning management. This also lets your in-house teams focus on tasks that really matter.

#8 – Security and Compliance – Last but not the least, there is the security aspect. With data privacy taking center stage (GDPR, CCPA, HIPAA, etc.), you need to make sure that your SaaS application is compliant at all times, with minimal stress on your CISOs and security teams. This also involved the integration of robust SIEM tools, while creating and enforcing a strong cross-department security policy.

One common practice to bolster SaaS application security is eliminating (or minimizing) password usage. Passwordless authentication is a great way to get this done. Check out the Top 10 Passwordless Vendors You Must Consider in 2021.

Related: What is Passwordless Authentication?  

Self Service Enablement: The Future of SaaS

You have a compelling core technology that is solving many pain points. That’s great. But only a comprehensive customer self service platform can help you cash in on it. Your clients and users want to have a seamless web self service experience today. Anything less can result in accelerated churn with a negative impact on your brand performance, especially when it comes to enterprise customers.

These feature and service requirements will come fast as you scale up your operations and look to achieve enterprise-readiness. But do you have the resources and time to invest in SaaS essentials? Who will take care of your core technology? What about the product roadmap? How will you keep your focus on quality and innovation? The answer is simple – self service enablement. Get proactive now. 

Learn how Hunters Uses Self Service to Scale Up Fast(er)
Get the Case Study

The post The 8 Pillars of Self Service in SaaS Applications appeared first on Frontegg.

]]>
https://frontegg.com/blog/the-8-pillars-of-self-service-in-saas-applications/feed 0
A Complete Guide to Implementing SAML Authentication in Enterprise SaaS Applications https://frontegg.com/blog/implementing-saml-authentication-in-enterprise-saas-applications https://frontegg.com/blog/implementing-saml-authentication-in-enterprise-saas-applications#respond Thu, 15 Jul 2021 13:28:13 +0000 https://frontegg.com/?p=6788 What Is SAML Authentication? SAML stands for Security Assertions Markup Language. Let’s say an organization wishes to authenticate its users without creating IAM roles and communicate assertions between the source and the target in a cloud environment. This can be easily achieved with the help of SAML. SAML is a method of secure communication between […]

The post A Complete Guide to Implementing SAML Authentication in Enterprise SaaS Applications appeared first on Frontegg.

]]>

What Is SAML Authentication?

SAML stands for Security Assertions Markup Language. Let’s say an organization wishes to authenticate its users without creating IAM roles and communicate assertions between the source and the target in a cloud environment. This can be easily achieved with the help of SAML.

saml authentication process
Image Source

SAML is a method of secure communication between parties using extensible markup language (XML). The following two endpoints are typically used in SAML:

  1. Identity provider: The source that makes the request is known as the “identity provider” and the user’s identity might be either username/password or username/OTP.
  2. Service provider: The “service provider” is the target to which the started request is directed for verification; it may be Gmail, AWS, or Salesforce. It keeps track of user permission records, and grants access to Software as a Service (SaaS) applications. It also keeps track of how long a user is permitted to stay or how to keep a user’s session on a certain application alive.

SAML is built on the notion of single sign-on (SSO). It means that one can use the same credentials on all of an organization’s portals to which they have access. SAML can also be used for access control list (ACL) permissions, in which it determines whether or not a user is authorized to access a specific resource. There’s also SAML 2.0, which is a version of the SAML standard that enables web-based, cross-domain SSO. It was ratified back in 2005.

Benefits of SAML

  1. For users and systems built independently by an organization, SAML enables both authentication and authorization.
  2. There is no need to use or remember numerous credentials after it is implemented. Only one sort of credential can access all of the organization’s resources or systems. 
  3. SAML follows a standard methodology that is not dependent on any system because it has no interoperability concerns with multiple products/vendors. SAML follows a standard method that is not dependent on any system.
  4. It uses a single point of entry to validate a user’s identity, allowing it to provide secure authentication without keeping user data or requiring directory synchronization. As a result, it removes the possibility of identity theft. 
  5. The SSO principle provides a hassle-free and speedier environment for its users.
  6. Administrative costs are also lowered for service providers. Because different authentication endpoints aren’t required, there’s no need to develop them.
  7. It makes the system more dependable in terms of “risk transference” because it transmits responsibility based on identity.

Let’s discuss the benefits of SAML from different stakeholders’ perspectives:

benefits of SAML

SAML v.s OAuth

OAuth stands for “Open Authorization“. OAuth, like SAML, employs an authorization server to complete the login process, and both are based on the SSO principle. Let’s look at some of the fundamental differences between them.

  1. SAML is concerned with the user, whereas OAuth is concerned with the application.
  2. Users are managed centrally in SAML. When a user logs into his organization’s network, he has access to all the resources because everything is centralized. However, if a user wants to provide third-party websites access to his information from a website like Facebook or Google, OAuth is required.
  3. SAML can do both authentication and authorization, whereas OAuth can only do the latter.
  4. OAuth is based on JavaScript Object Notation (JSON), binary, or even SAML forms, whereas SAML is based on XML format.
  5. In SAML, a token is referred to as a SAML assertion. In OAuth, a token is referred to as an access token.
  6. If users need temporary access to resources, utilize OAuth instead of SAML because it is more lightweight.

How SAML Authentication Works

How SAML Authentication Works
Image by Author
  1. The identity provider obtains the user’s credentials (username and password). SAML validates the user’s identity at this stage.
  2. The identity provider will now verify the credentials and permissions associated with that account. If the user’s credentials are correct, the identity provider will respond with a token and the user’s approved response to access the SaaS application. 
  3. This token is sent to the service provider using a POST request. 
  4. The service provider will now validate the token. If the token is valid, it will generate temporary credentials and direct the user to the desired application terminal.

Note: The actions listed above will only work if there is a “trust connection” between the identity provider and the service provider. The authentication process will fail if that does not exist.

How We Can Create a Trust Relationship between Identity Provider and Service Provider

The SAML basic configuration must be agreed upon by both the identity provider and the service provider. As a result, an identical configuration is required at both endpoints; otherwise, SAML will not work. 

How It Works:

  1. Create a SAML document and submit it to the service provider. However, this document would be in XML format. We must first generate a certificate from the host machine.
  2. Similarly, generate a document on the service provider and then import it on the identity provider. That document has a lot of information like certificate information, email address of the organization, and public key of the service provider.

SAML Use Cases

When an organization implements SAML, it can do so in a variety of ways. For example, all infrastructure can be deployed on-premises, in the cloud, or in a hybrid structure where part of it is on the cloud and part is on-premises. We have a couple of use cases based on it.

Hybrid

In this situation, identity verification takes place on-premises, but authorization takes place in the cloud, and the user has immediate access to the cloud resource before authentication, then:

  1. Users can access cloud resources directly.
  2. For authentication, users will be redirected to an on-premises setup.
  3. The identity provider verifies the user’s identity and provides the SAML assertion for the service provider’s use.
  4. The service provider will validate the assertion, and the user will be sent to the web application.

Cloud-Based

Both the identity provider and the service provider are cloud-based in this scenario, and the apps are either cloud-based or on-premises.

  1. First, users will be redirected to the cloud infrastructure to verify their identity. Identity as a service (IaaS) is a term used to describe how identity providers work (IDAAS). 
  2. Authentication will be handled via the identity provider. The identity provider assigns assertions after authentication.
  3. The service provider verifies the veracity of the claim and provides the user access to the web application.  

How to Implement SAML on the Cloud

It is relatively simple to deploy SAML in the cloud because most cloud service providers now provide an option to do so automatically; you don’t need to know rocket science to do so. Here, we are discussing how you can implement SAML on Google Cloud.

Step 1

Create an account on Google Cloud and enable the identity provider.

Step 2

Now it’s time to set up the provider; there are a few things to do.

  1. Go to Identity Provider -> Click on Add Provider -> Select SAML list from there -> Enter details such as Provider Name, Provider’s Entity ID, Provider’s SSO URL, Certificate (used for token signing).   
  2. Go to Service Provider -> Provide Entity Id (that verifies your application).

Step 3

  1. Add application URL in the authorized domain.

Step 4

2. After adding all this information at different places, click on save.

These are some basic cloud measures that we can use. However, we can take the procedures listed below to secure it, such as:

  1. Signing request: By signing authentication requests, this feature improves the security of the requests.
  2. Link user accounts: There’s a chance the user has already signed into the program, but with a different method than username/password. As a result, we can link the existing account to the SAML provider in such a scenario.
  3. Re-authenticating user: When a user changes his email, password, or any other sensitive information, it is the obligation of the SAML to re-authenticate the user.

SAML Authentication Best Practices

Although we discussed the fundamentals of SAML, there are other fundamentals that make SAML communication more safe.

  1. For secure web communication, always use SSL/TLS. As a result, all communication between users, identity providers, and service providers is encrypted at all times. Since communication is encrypted, an attacker attempting an MITM attack will be unable to access or modify the data. As a result, the requests’ confidentiality and integrity are preserved.
  2. Whenever creating a trust relation between identity providers and service providers, configure identity providers to use HTTP POST, and for redirection of SAML responses, use the whitelisted domains. The service provider does not perform the authentication operation. If the domain is not whitelisted, attackers can manipulate the domain and redirect them into a malicious domain.    
  3. SAML uses XML to perform validation schema on XML documents so that unsanitized user input cannot pass. Always prefer local schema from XML. Do not download it from untrusted websites. 
  4. Maintain a blacklist of the domains that the organization wants to exclude from the SAML authentication process.
  5. As an identity provider, we can manage the user through access control.

The post A Complete Guide to Implementing SAML Authentication in Enterprise SaaS Applications appeared first on Frontegg.

]]>
https://frontegg.com/blog/implementing-saml-authentication-in-enterprise-saas-applications/feed 0
Helping Your SaaS Application Reach Enterprise Readiness https://frontegg.com/blog/helping-your-saas-reach-enterprise-readiness https://frontegg.com/blog/helping-your-saas-reach-enterprise-readiness#respond Tue, 13 Jul 2021 11:46:38 +0000 http://3.226.240.66/?p=1746 If you are reading this article, chances are that you own a SaaS application or are developing one right now. But with digitalization in full drive, are you addressing the enterprise readiness aspect? While scaling up, the ongoing maintenance work demands grow (for example, user management upgrades), putting your devs and IT teams under added […]

The post Helping Your SaaS Application Reach Enterprise Readiness appeared first on Frontegg.

]]>

If you are reading this article, chances are that you own a SaaS application or are developing one right now. But with digitalization in full drive, are you addressing the enterprise readiness aspect? While scaling up, the ongoing maintenance work demands grow (for example, user management upgrades), putting your devs and IT teams under added stress to get things done fast. But this work spike impacts productivity and takes the focus off the core technology. So what’s the solution? Let’s take a closer look. 

If you are building an enterprise ready SaaS application, it’s most likely that you will be looking to provide a unique value offering and to fill the need of a wide variety of customers and users. Your software product is probably being sold as a recurring subscription model or as a web product. Customers that are paying recurring monthly fees or testing out your basic subscriptions. 

Is Your SaaS Application Enterprise Ready?

As a C level or VP you are constantly looking to present an enterprise ready solution to your design partners and early-stage investors. You are looking at marketing and selling to growth stage companies and maybe have even started peeking at the potential of onboarding some enterprise customers. But more often than not, SaaS offerings are far from enterprise ready.This is a huge business roadblock.

Let’s assume that it does happen one day. You see an email in your inbox from an enterprise customer whom you have been pursuing for quite a while now. They are interested in hearing more about your product and its core functionality. They even want to schedule a demo. Oh wait! I forgot to mention one other small detail. They also want to know if you have customer facing enterprise level features.

That excitement you experienced only seconds earlier is slowly replaced by a deep sense of disappointment and hopelessness because you are not enterprise ready.

You now know for certain that you won’t be able to make the leap towards meeting the demands of this enterprise company in the short timeline they have given you because you lack the resources. You reassure yourself that somehow you’ll figure it out, you take the call, you do the demo, and now you are left staring at a list of demands with a timeline for engagement that is close to impossible to achieve.

This story is retold over and over again in today’s SaaS industry. There are key features and standards that all SaaS products require at some point during their development and yet even if B2B SaaS applications have become standardized, there’s still no platform to accommodate the recurring customer-facing features and functionalities which are now a standard in almost any SaaS product.

Related: Best 10 PLG Tools for Your SaaS App

Top 5 SaaS Enterprise Readiness Hacks

1. Perform a general assessment of what the gaps are between your current status and what features you need to become enterprise ready.

There are a few consulting companies out there, who are focused on advising SaaS products regarding what they need to do to reach the necessary enterprise readiness level of development. They offer outlines of the baseline features that enterprise companies want and need, some open source solutions, and guidelines on how to build your SaaS product for enterprise. 

These guidelines of course will take time and resources to execute. Yet, they are great at helping you understand what it is you are lacking in your current SaaS offering.  Once you complete a SaaS enterprise readiness gap assessment (check out sites like enterpriseready.io), you will likely know where you stand. Just understand that you aren’t going to fill all the gaps right immediately. 

Having a sense of where you stand is a great start. This brings me to my next point.

2. Reach for the lowest hanging fruit first. 

If you look closely at exactly what your most relevant enterprise customers need from SaaS applications, you’ll quickly realize that there’s no point building a pool in the winter time, nor is there any real reason to think that every single feature and requirement is an immediate need. Try to get an overall understanding of what the features are that we are talking about before committing time and resources. 

For example, some enterprise clients may want audit log capabilities and reporting features, others may ask for SSO or granular notifications. Some just want to know that they have a proper notifications center in their customer facing dashboard for unification across multiple products and platforms. In short, make smart choices and be prudent about your next steps. 

3. Think about what resources will support and enhance your core business focus

Make sure to stand out from the crowd. Sometimes it’s enough to showcase one or two “Enterprise features” on your initial demo call, just to assure the enterprise representative that you’re on top of their segment and are aware of their needs.

Your potential enterprise-level clients should know you are taking things seriously, making it easier for them to believe that you’ll complete the other functionality gaps quickly after that. Just make sure that you aren’t caught fumbling around trying to send reports or show the ease of use of your core product, when you don’t have the business agnostic features to match. This is a trap you should avoid at all costs.

4. Don’t compromise on high standards of security and scale. 

From day one, an early-stage SaaS product should aim for high-level enterprise-grade features so that they won’t have to rebuild everything at a later stage. Growth stage companies are focused on accelerating their enterprise readiness. and should be instilling a sense of confidence in their ability to offer scale, security and compliance. That’s the best way to create enterprise SaaS products.

Customers of growth-stage companies will demand a high level of product maturity and advanced features. It’s not enough to offer merely SSO at this stage. Rather you need to start offering a Multi-tenancy model, Automated provisioning, Audit logs, subscription-based billing, and elastic infrastructure. Security is critical at this point and is not just something to be discussed at a later time since the time is now.

5. Ensure a high level of data security: 

Firstly, stick to using common industry frameworks (React, Node, etc.). Also, ensure that your business information is protected from corruption and unauthorized access. Keep your data close, encrypted and secure from one tenant to the next. Any features you are using should offer a good key management framework or have the ability to integrate/interface with external Key Management Frameworks. 

Also, integration with the CASB (Cloud Access Security Brokers) system will increase confidence with respect to data security. A very strong Role-Based Access Controls need to be ensured in order to protect the data.

Related: Top 10 Passwordless Vendors You Need to Consider in 2021

Enterprise Readiness with Frontegg

Many of these issues can be solved quickly even if others require time and resources. If you want to find out more and are interested in completing a FREE SaaS diagnostic assessment, please feel free to reach out to our SaaS diagnostic team at hello@frontegg.com. Our SaaS experts are standing by, waiting to hear from you and to accelerate your SaaS forwards to the next level of enterprise readiness.

The post Helping Your SaaS Application Reach Enterprise Readiness appeared first on Frontegg.

]]>
https://frontegg.com/blog/helping-your-saas-reach-enterprise-readiness/feed 0
User Management Tool Showdown: Okta vs Auth0 vs Frontegg https://frontegg.com/blog/user-management-tool-showdown https://frontegg.com/blog/user-management-tool-showdown#respond Thu, 08 Jul 2021 15:26:49 +0000 https://frontegg.com/?p=6719 SaaS user management is basically the process of managing users, permissions, and roles on an ongoing basis. This involves identifying, authenticating, and authorizing all users for only the amount of access they need or have paid for. Are you in the market for a comprehensive user management solution? We are here to help. This detailed […]

The post User Management Tool Showdown: Okta vs Auth0 vs Frontegg appeared first on Frontegg.

]]>

SaaS user management is basically the process of managing users, permissions, and roles on an ongoing basis. This involves identifying, authenticating, and authorizing all users for only the amount of access they need or have paid for. Are you in the market for a comprehensive user management solution? We are here to help. This detailed tool comparison will zero in on the top options available today and hopefully help you pick wisely. Let’s dive into it.

Gone are the days when you could afford to neglect SaaS user account management and just get by with a super-admin role for all. Read more about roles and permissions handling in SaaS applications before you get started. 

Let the Battle Begin: Okta vs Auth0 vs Frontegg

As mentioned earlier in the article, these are not the only options in the market today, but you will probably not find more comprehensive ones. We’ll cover the fourth option, FusionAuth, later in the article as an honorary mention.

Okta 

Okta is a cloud-based identity management service that helps businesses of all sizes secure/manage identities and access to their application. Its most popular offering has been enabling single sign-on (SSO) for all apps used within organizations. This means that you can sign in to your company’s Office 365 apps, Gitlab, Trello, Jira, and other applications with just one password. 

With the Okta CIAM solution, devs can also create frictionless user registrations and logins for their apps. There is also adaptive multi-factor authentication (MFA). Besides passwords, you can even go as far as implementing passwordless authentication. APIs and SDKs are easy to implement and maintain. There is support for over 10 languages and frameworks to allow the easy stack upgrades. 

Other main features of Okta include:

  • Flexible User Migrations: With Okta, you can seamlessly migrate your user stores into Okta with multiple import methods that fit your business needs. You can import users from a CSV, API, database or directory.
  • Support for effective management of third-party accounts from partner organizations: If you have a support admin from another company joining your team, you can provide temporary access to the support admin.
  • Centralized user management: With Okta, you basically get a single consolidated view of every user from different identities under one universal directory. This makes it easy to manage SaaS apps that are scaling up fast.

Pros: Easy to use, Integration with 7000+ apps, Good documentation, Community
Cons: No straightforward multi-tenancy, Expensive for important B2B capabilities, Onboarding and training required (complexity)
Pricing: Dev APIs and SDKs – Free for 1000 Users, $50 for every 2,500 Additional Users. Enterprise-Grade Features Pricing Differs – Check Pricing Catalogue

Auth0

This authentication and authorization platform is popular amongst devs, since they were the company’s initial target audience. It helped them integrate secure access and identity management into their SaaS apps. Subsequently, Auth0 adapted its product to enterprise use cases. Auth0 helps find the right balance between user convenience, privacy, and security, while chasing identity management.

Besides the straightforward username/password authentication method, social and enterprise SSO is also supported with this solution, something that helps improve productivity with employees and users alike. The SSO interface allows direct access to the entire active application suite. The dashboard is straightforward and intuitive, something that translates into shorter onboarding times. 

Auth0 also makes it easy to build identity flows with it’s drag and drop functionality

Related: What is Passwordless Authentication?

Also with Auth0, you will be getting:

  • Comprehensive documentation and a hyperactive community: The platform provides a big team of developers available to help with any difficulty. You’ll be surprised with the amount of attention people get in the Auth0 forums.
  • Security: You can build an extra security layer into your application with attack protection from bots, adaptive multiple factor authentication (MFA), step-up authentication solutions and breached password detection solutions.
  • Passwordless authentication support: You already know that the modern SaaS user is gravitating away from passwords. The Auth0 solution authenticates securely and efficiently via emails, SMSs, and magic links.

Pros: High on security, Serverless Option, Very Strong Community
Cons: Missing deep multi-tenancy granularity, Limited 3rd party compatibility, Complex B2B solution integration, No full login box customization, No REST API for Logins
Pricing: B2B Essentials package starts at $130 per month (includes MFA). B2B Pro package starts at $800 per month (covers external databases). Check pricing.

Frontegg

Frontegg is a next-gen platform that helps developers and SaaS companies build products faster. It provides out-of-the-box functional pluggable components for common necessary features so that they can focus on building only what makes their product unique. User management is one of them, along with user authentication and other add-ons that will be available soon. Stay tuned!

Frontegg provides a plug-and-play admin portal for user management that is customer-facing and can centralize all user management capabilities in one place – team management, audit logs, webhooks, API tokens, and subscriptions – a truly end-to-end solution for SaaS user management. Frontegg is integrated seamlessly (and fast) and does not affect the core backend or frontend of your product. 

The main features of the Frontegg solution include:

  • Multi-tenant by design: Enterprise-size businesses and small apps that are scaling up fast – both can use Frontegg. The multi-tenant design means all of the data is segregated as per the specific tenant in-use.
  • Self-service management: The SaaS space is gravitating fast towards the self-service methodology. Frontegg has a self-service Admin portal embedded in the app, with all authentication and login features you need.
  • Versatile user management solution – Frontegg addresses frontend (customer facing UI) and backend things are covered as well (pun intended). You get documentation and an API-first approach. It’s all very easy to integrate.

Pros: PLG-friendly, Self-service, Plug-and-play, Customizable UI, Great for B2B Apps
Cons: Relatively new company, Limited social logins
Pricing: 30-day free trial with all features unlocked. Growth plan packages start at $499 per month. See pricing page for more details.

Okta vs Auth0 vs Frontegg

Okta vs Auth0 vs Frontegg

Related: Password Hacking: How Passwords are Breached

Honorary Mention: FusionAuth

We can’t wrap it up without mentioning FusionAuth. Although not an enterprise-level solution, it is a capable identity and access management tool. Built with developers and tech teams in mind, it can easily be integrated with any language or framework and when done correctly – can be deployed in minutes. With FusionAuth, you can have complete flexibility to handle multiple use cases.

SaaS user management with FusionAuth is easy as it allows maximum visibility with its centralized dashboard, via which you can configure groups and access detailed reporting. There is also extensive documentation and an active community, although customer service can be slow at times. It also offers COPPA and family support – a comprehensive family management system with built-in emailing capabilities.

Pros: Lots of customizability, Many useful features, Attractive pricing
Cons: Not suitable for enterprise setups, Iffy Customer Service
Pricing: No free trial is offered here. The basic cloud-based plan starts at $75 per month. See pricing page for more details.

Look for Flexibility, Scalability, and Versatility 

It’s important to mention again that there are other user management tools available out there, so feel free to do your research and check out options that are not mentioned in this comparison resource. Regardless of the user management tool you decide to go with, make sure it is secure, compliant, and versatile, while supporting self-service and offering multi-tenant capabilities.

Identity provisioning and user management are key features for most SaaS apps. But, should you spend months building it when you can easily use any of the tools described above to achieve better results within a day or two? The time you save can be used to focus on building the features that actually make your product unique. This is where Frontegg starts gaining an edge over its competitors.

Case study: Learn how Cycode uses Frontegg to focus on innovation

The post User Management Tool Showdown: Okta vs Auth0 vs Frontegg appeared first on Frontegg.

]]>
https://frontegg.com/blog/user-management-tool-showdown/feed 0
How to Persist JWT Tokens for Your SaaS Application https://frontegg.com/blog/how-to-persist-jwt-tokens-for-your-saas-application https://frontegg.com/blog/how-to-persist-jwt-tokens-for-your-saas-application#respond Tue, 06 Jul 2021 14:24:29 +0000 http://3.226.240.66/?p=1798 The first (and probably one of the most important) parts of every multi-tenant SaaS application is identity management. This is because the main idea of multi-tenancy is that a user belongs to one (or more) tenants. The separation of the user-tenant concept is one of the most important aspects of multi tenant applications, where several […]

The post How to Persist JWT Tokens for Your SaaS Application appeared first on Frontegg.

]]>

The first (and probably one of the most important) parts of every multi-tenant SaaS application is identity management. This is because the main idea of multi-tenancy is that a user belongs to one (or more) tenants. The separation of the user-tenant concept is one of the most important aspects of multi tenant applications, where several users (with different roles and permissions) can control the same application (tenant). Let’s dive into this crucial topic.

Multi Tenant Identity Management

While multi-tenancy is great for SaaS applications and end-users, it creates several tiers of complexity for identity management. So as we approach the authentication “challenge”, we’re usually quickly reduced to a checklist of important items (both on the product side and the technical side) that need to be handled. This list is not exhaustive in any way, but these questions always come up sooner or later:

  • What kind of authentication methods do we support? 
  • Do we allow social logins? Do we allow SSO and SAML?
  • Do we allow the user to login without activating the account via email?
  • What is our password policy? Do we allow each tenant to set a different one?
  • Do we support MFA? Which methods do we allow? Email? SMS? Authenticator app? Do we allow the tenant to force MFA for it’s admins?
  • Do we support server logout?
  • What is the defined session timeout?
  • Will multi tenant authentication work smoothly?
  • How do we implement team management and invites?
  • Do we allow a user to be associated with more than one tenant?

WOW! That’s a lot to think about and to handle.

This series of posts will tackle (using code samples) the main multi tenant identity management SaaS capabilities, from the very basic to the most advanced.

In this first post, we will focus on the very basis of the entire multi-tenant SaaS authentication — JWT authentication. We’ll discuss what JWTs are, their content and token persistence — what you need to know to get a feel of how they work.

The Rise of JWT Multi Tenant Authentication

JWT (JSON Web Tokens) is the new and de facto authentication method (loved by developers) for several, rather important, reasons. It is an open standard – RFC 7519 – highly trusted as it is digitally signed. JWTS can be signed with secret, public, or private key pairs as per your specific needs and requirements.

In a nutshell, JWT is a token generated by the server which includes several claims and a payload that represents the user and the characteristics of the token (when it was issued, when it expires, etc.). The structure of JSON Web Tokens is fixed and made up of Headers, Dynamic Payloads, and Signatures (xxxxx.yyyyy.zzzzz). 

That token is sent to the client upon login and needs to be sent back to each of the servers (or microservices) upon each request, which requires valid authentication. But wait a moment. If the token is visible on the client side (and the client can decode it), what about the security aspect? What is stopping the client from generating tokens and impersonating other users?

The most important attribute of JWT tokens is their signature.

Each JWT token is signed on the back end by a private key that can be verified by clients (and other microservices) by the public key. This basic asymmetric signature method allows us to easily verify that the authenticated user is actually authenticated and not impersonated without the need for maintaining a central tokens database / session management.

And this is one of the reasons we like JWT so much. The rise of microservices created the need to decentralize authentication and verification mechanisms — and JWT based authentication matches this requirement like a glove.

The Contents of JWT tokens for Multi Tenant SaaS Applications

When a user logs into the application, we would want to add to the JWT the notion of the tenant in order to make sure that after the verification of the JWT token, we are in the correct context of the tenant and we aren’t exposing our application to cross-tenant security issues.

So the flow is: 

Persisting Tokens

Another issue is the handling of the JWT tokens on our client application.  

Multi-tenant SaaS applications are built today using web technologies (and most of them are Single Page Applications as well). So we know that we got the JSON Web Token from the authentication endpoint after the login is done. We know that we need to pass it on each request. And we probably want it to last after a page refresh. Why not save it to the local storage?

Saving your JWT tokens on local storage exposes your application to XSS, which has been a OWASP Top 10 regular for many years. In this case, the attacker (using a malicious code) can hijack the stored token from the localstorage, use it for calling the back end on behalf of the user and actually breach the system.

So, how should we protect ourselves?

  • How about limiting the expiration of JWT tokens? Setting the expiry to 5 minutes? Well, it solves a part of the problem but still leaves you exposed.
  • How about saving the token in memory? While this does solve the security problem, it breaks usability as we cannot handle scenarios such as page refresh / new tab.
  • Maybe saving the JWT token as an HTTP-only cookie? That totally works but exposes us to CSRF attacks without any additional CSRF protection.

Related: OWASP Top Ten Web Application Security Risks

Persisting Through Refresh Tokens and HTTP-Only Cookies

The use of refresh tokens allows us to continuously refresh the sessions and to get new JWT tokens. Using refresh tokens allows us to shorten the lifetime of the actual JWT tokens while the refreshed tokens can actually “live longer”.

Using this approach we can store the JSON Web Tokens in-memory while saving the refresh tokens using http-only cookies. The refresh tokens are not vulnerable to CSRF attacks on form submits because the attacker cannot get the value of the JWT which was returned from the endpoint.

What does the flow look like in this case?

So how will the full flow look upon page load? Because the HTTP-only cookie is persisted via the browser, the flow looks similar by using the same refresh tokens alternative.

Summary

In this post, we have discussed how to handle JWT token-based authentication in your multi-tenant SaaS application and how to leverage the use of refresh tokens in order to safely persist your users’ sessions. The next post will show you how to start building a capable back end for securely storing user details and maintaining the user’s activation flows for really robust SaaS applications.

The post How to Persist JWT Tokens for Your SaaS Application appeared first on Frontegg.

]]>
https://frontegg.com/blog/how-to-persist-jwt-tokens-for-your-saas-application/feed 0