Frontegg https://frontegg.com Platform for SaaS Applications Sat, 26 Sep 2020 09:53:42 +0000 en-US hourly 1 https://frontegg.com/wp-content/uploads/2020/06/favicon.png Frontegg https://frontegg.com 32 32 The SaaS Re-Creation Life Cycle https://frontegg.com/blog/the-saas-re-creation-life-cycle https://frontegg.com/blog/the-saas-re-creation-life-cycle#respond Thu, 24 Sep 2020 14:49:16 +0000 http://frontegg.com/?p=3261 The SaaS market is constantly growing and as anyone who is a developer of a SaaS product today knows, you will find yourselves facing thousands of SaaS companies, new and old, who are all trying to create solutions to every possible business need and otherwise. Even in markets where there is a much higher barrier […]

The post The SaaS Re-Creation Life Cycle appeared first on Frontegg.

]]>

The SaaS market is constantly growing and as anyone who is a developer of a SaaS product today knows, you will find yourselves facing thousands of SaaS companies, new and old, who are all trying to create solutions to every possible business need and otherwise. Even in markets where there is a much higher barrier to entry such as Artificial Intelligence and Machine Learning, we are seeing huge levels of competition all around.

The SaaS Re-Creation Life Cycle

For those of you developing a SaaS or digital project, you are probably used to the concept of working towards an MVP, one that can showcase the beginning stages of your future, soon to be completed, value offering. At any stage of development, high touch interaction is what your customers deserve and expect, and you most certainly want to provide nothing less. 

These early stages can find you scrambling to create an MVP that is at the very least a way for you to validate your right to exist and will be your stepping stone towards the future of your business. You have a pretty good idea of what you want your core business to be and you believe that it’s just a matter of time before your hypothesis becomes a validated product market fit. 

But how do you know what your customers really need/want before you even have any customers? And what if you do have customers, but your initial customer base isn’t reflective of the market overall or if your initial product market fit shifts or expands? Then what? Do you start from scratch, reuse, rebuild or recycle? In other words, do you pivot or try to salvage what you already have? These are all legitimate questions that every SaaS development company faces as it scales and grows. 

SaaS companies have two main focal points that essentially work together and will ultimately lead to their success (or failure). These two interconnected parts are your Development team and your Sales & Marketing. I personally like to view these two departments as two trains, running on parallel tracks, connected by a chain in the middle. The R&D and Sales & Marketing trains need to pick up steam synchronously and to keep pace with one another throughout the length of their SaaS development journey. Should one train get too far ahead of, or fall behind the other, the connection will break, and they will ultimately lose their way or be left behind. 

Over the years, I have seen many startups lose their inter-department connection and have watched what happens when this lack of synchronicity between connected parts of a product’s development occurs. On the one end, I have seen development teams forge ahead with their platform, full steam ahead, launching features, developing and coding and having product launches, only to find out that they forgot to check in with their customers along the way, and have left them 10km back standing on the platform. I have also watched companies sell their hearts and souls, pushing a product and solution that seems just too good to be true, only to prove to their investors and customers that indeed it is. The product never caught up to the promise, which ultimately led to drained resources and a muddied reputation.

The interconnectivity of these two trains are reflective of a successful SaaS development journey and will oftentimes prove to be the key to recurring successful feature development, leading to new customers and a product’s scale and growth. 

Develop. Test. Reassess.

So let’s delve into the three parts of what I refer to as the “SaaS Re-Creation Lifecycle” and see how we can approach each one successfully from an R&D and Sales perspective, throughout each step of the recurring SaaS development cycle.

Development

Sales: By knowing who your customers are at every stage of the journey, you will guarantee traction and enthusiasm from your growing customer base. At pre-traction and traction stages of your development, your customers will most likely be tech enthusiasts, investors and visionaries. They GET you and they want to be a part of your vision. Your focus will be on an MVP that can offer your customers the beginning of what your bigger offering will look like. 

R&D: Interest and purchasing are key elements to this part of your customer lifecycle. As you scale you stay focused on converting pragmatists into paying customers. These customers will be your window into the development you focus on at every stage of your SaaS’ journey. Through the implementation of user advocacy, becoming industry leaders and forging strategic partnerships, you will be able to stay focused on your core product development and customer needs and that will become evident in your product market fit. 

Testing

Sales: Customer Service starts with Service. Find out what your customers are saying and predict your churn rate before it happens. Keep your customers informed. Start by sending out great onboarding emails and continue by constantly reminding people of your great offering. Sure, they may already know you’re great. But reminders are worth a million times more when it comes from the creators. 

And don’t forget to use data…

People aren’t always aware of their own needs or behavior so keep track of data to understand and connect with your customers. Subdivide your customers based on needs, then segment and identify. Are you paying attention to your ‘visitor to lead’ conversions via newsletter subscribers, LinkedIn Page followers or post likes? What about your leads that convert to opportunities: Where are your demo requests coming from? And finally, how successful are you at turning a lead into a customer? 

Remember to create the right online content for engaging and sharing knowledge. Share your experience and expertise to gain respect and trust for your product. 

R&D: Is your customer’s needs and feedback being Implemented? And what about your onboarding process? Many customers can be lost at this point if the onboarding becomes tedious or lacks flow. Those early customers love you and have patience, but as you scale, your new customers are looking for value and they want it yesterday. 

The development team is the front line of development and are the enablers of solutions and decisions being made based on function, scalability, client needs and data. They need to be quick on the draw and be the ones to implement the ongoing hypotheses that are being presented. So if there are glitches in your onboarding or the product lacks that personal touch, now is the time to find out more. What defines a conversion point for you at each stage of your SaaS development? 

All of this is part of your company’s data and you will slowly learn to read it and understand what it means. The data has been collected and the customers are talking…if you are ready to listen. 

Reassess and Rebuild

Sales: Understand what success means to your customer, not just to you. Expansion and renewal means targeting the market and expanding your offering. If your customer cares about the bottom line, then that’s your calling. Don’t ignore that ask. Did you collect feedback? Great. Then let’s use that to divide and conquer. Don’t give up and remember to listen. Now go out there and customize their experiences. Be human and personalize. 

R&D: Don’t let critical information fall between the cracks. Customer support will need data that was collected during implementation and that data is critical for every stage of onboarding. Your customer success is also feeding you data which you should be using to refine and validate your methods. 

At the end of every development cycle you will be the ones who were responsible for refining the customer experience and you are all well aware of who from your team was most in contact, and should be in contact going forward, with the customer and when. You probably know by now how to make the most of this data, breaking it down to even more granular data at each stage of the life cycle.

And finally….

In order to meet market standards and succeed in today’s ever-changing market, you will need to be ready for your customers. Being aware of what your customers want and need and being able to offer them a smooth customer journey is a key factor in your company’s future success. By personalizing and customizing the customer journey right from the get-go, you are differentiating yourself from the competition. Especially during the Covid pandemic where customers need to be onboarded quickly and efficiently, you will need to be ready to help them achieve their goals. 

Always remember never to go too far in your development journey before you are certain that you are adhering to the basics of your development roadmap and that your customers are along for the journey. Use easy to implement solutions to scale up quickly and easily. And if you need to scale back, then do so. Three steps forward and two steps back will still get you where you’re going. 

Here at Frontegg we believe in helping you focus on your core business instead of spending unnecessary time on developing the generic aspects of SaaS Development. By allowing you to focus on your core business, you can easily and quickly move forwards with your development and get the feedback you need and want and validate your hypotheses all while focusing on enhancing your SaaS offering.

The post The SaaS Re-Creation Life Cycle appeared first on Frontegg.

]]>
https://frontegg.com/blog/the-saas-re-creation-life-cycle/feed 0
Product Management Tips for Early-Stage SaaS Products https://frontegg.com/blog/product-management-tips-for-early-stage-saas-products https://frontegg.com/blog/product-management-tips-for-early-stage-saas-products#respond Thu, 17 Sep 2020 12:37:57 +0000 http://frontegg.com/?p=3196 Handle access and security features first The foundation of every successful product is a decent security infrastructure, and the first thing to plan when building your application is the authentication and authorization method. Make sure to invest some serious thinking on how this part should be handled. Aim for flexibility within your multi-tenant architecture. For […]

The post Product Management Tips for Early-Stage SaaS Products appeared first on Frontegg.

]]>

Handle access and security features first

The foundation of every successful product is a decent security infrastructure, and the first thing to plan when building your application is the authentication and authorization method. Make sure to invest some serious thinking on how this part should be handled. Aim for flexibility within your multi-tenant architecture. For example, be prepared to handle specific customer requests for SSO, multi-factor authentication, password-complexity control and more.

PRO TIP: Read this piece by Aviad Mizrachi on important aspects of SaaS app Authentication

Don’t reinvent the wheel on UX – Use a solid standard

During the last decade some standardization has been established around how SaaS products should look, feel and behave. Don’t try to reinvent the wheel. Just as mobile users expect a certain experience, your SaaS users wouldn’t want to be surprised. Achieve your differentiation on your core features, not on the general UX. Start with a comfortable login page, move to a nice top-bar and a side-menu, and then develop the main screens. A lot of examples exist out there, pick the best one and move on.

PRO TIP: A good example for a typical functional SaaS app experience can be found on our live demo.

Build for quick actions – Responsiveness first

In the olden days, the web was perceived as an HTML page containing standard HTML elements limited in look (well, they were quite ugly) and feel (slow and non-intuitive). But we’ve come a long way, and today you can achieve a “native” desktop experience in web applications. Apps like Asana, Slack and AirTable introduced a new standard of SaaS usability through their amazing level of responsivity. Customers thrive on the ability to create quick moves and actions while using only their keyboard, without the need to move their hands to touch their mouse. Aim to provide this kind of experience in your product. This is exactly what makes customers fall in love with your brand.

Keep end-user engaged and connected

Keep in mind that users will not always use your applications. But they do want to feel a part of your product even when they aren’t connected to your web app.

Keeping customers engaged with your brand is very important. It reduces churn, increases upsells, and improves your customers’ overall experience. This makes it more likely they will recommend your product to their friends and colleagues. Using features like notifications, reports and new version announcements can highly improve the level of your users’ engagement and connectivity with your app.

PRO TIP: Very soon you’ll find that customers want to subscribe to your in-app events on the different 3rd party apps they use, whether it’s Slack, MS Teams, their JIRA and others. Make sure you can support these requests early on (check out Frontegg Connectivity for more info).

[cta]

Validate UX flows with customers

Don’t assume you know what your users expect, especially when building a new product. With the current technology, it’s very easy to validate user experience without actually writing a single line of code. Use (or have your Product or UX designer use) interactive prototyping tools like Adobe XD, Figma, Sketch and others to provide high level mocks of the experiences you plan to provide within your product. When you feel that a critical mass of users approved these experiences, feel free to hand off your designs to development.

PRO TIP: Have your designers invest in a real life mockup and repeating elements within your app, so you can later play with it on your own to demonstrate future capabilities and screens within your app.

Plan for self-service

Most of the products out there will start out with a gated sign-up for one of two reasons. Either they initially want to keep control over who gets exposure to the product, or they aren’t ready for a self-service experience so they engage in user hand-holding in the first stages. Both are totally fine, but keep in mind that providing a full self-service experience should be the goal for the vast majority of SaaS products out there. Make sure to keep this in mind when building the first versions of your app. Integrate tools like WalkMe, Appcues, Pendo.io and others to make the onboarding experience great. Also, invest into the documentation and “getting started” guides, so that customers will always have a resource to turn to when they have some question about your app.

PRO TIP: At the early stages of your product, and especially if you’re not “self-service” enabled, provide a great support experience by opening shared Slack channels with your early adopters. 

Tease for future features

You will always start with an MVP and then gradually build your feature set (read here about the different stages of SaaS products). That being said, your customers always want to see signs of growth within the products they’re using. Make sure your platform can provide hints of new capabilities coming their way soon.

Start by creating placeholder screens for new views and make sure to mark those as “coming soon”. When the beta version of your new features are ready you can gradually unveil them to your users by using “feature flags”. tools like LaunchDarkly, Split.io and others will help you with these.

PRO TIP: Don’t keep your coming-soon features for too long, as this can irritate your users.

PRO TIP II: Measure your users’ anticipation for the upcoming features by in-app analytics tools like MixPanel or Google Analytics.

The post Product Management Tips for Early-Stage SaaS Products appeared first on Frontegg.

]]>
https://frontegg.com/blog/product-management-tips-for-early-stage-saas-products/feed 0
Distributed SaaS Monolith 101 https://frontegg.com/blog/distributed-saas-monolith-101 https://frontegg.com/blog/distributed-saas-monolith-101#respond Thu, 10 Sep 2020 10:35:01 +0000 http://frontegg.com/?p=2980 Intro The first time I implemented a REST service was in order to upgrade an old proprietary communication protocol between our servers. At that time we called our services “servers”, as if they were an enclosed computational unit, and only that unit could have done the thing it was designed to do. Mostly single-threaded, active-standby […]

The post Distributed SaaS Monolith 101 appeared first on Frontegg.

]]>

Intro

The first time I implemented a REST service was in order to upgrade an old proprietary communication protocol between our servers. At that time we called our services “servers”, as if they were an enclosed computational unit, and only that unit could have done the thing it was designed to do. Mostly single-threaded, active-standby mode (non-scalable that is), and of course, monolithic (and I’m not taking sides here in the “Monolith-first” vs “Microservice-first“ discussion).

Man… Those were the good ol’ days, when I didn’t care about most of what I care about today (when it comes to coding) and where logs were saved to disk and you had to ssh and grep scavenge your way through many auto rotating log files.

Nowadays, when starting a new product, you’ll be focusing your engineering wizardry on your core business offering. Step by step, you are required to make your “project” into a “product”, something that others can use, A SERVICE. Only now, you are a few customers in, and you need to show results.
You start by adding a single REST microservice. Then another, and another one after that. Until your wizardry has become a kid’s birthday magician and you are left with the most unmaintainable, impossible to scale, intricate and coupled distributed-monolith possible.

And all that Jazz …or SaaS

You probably think I’m exaggerating — Well actually, I am. To a point.

To be honest, when you’re thinking about building your core product, the need to add all the fluff that goes around it can be a really big pain.

“I’m building the next big thing here and want to focus on that. Why on earth am I wasting resources on security, reporting and authentication stuff? This sucks!”

And that’s exactly the point!

It does suck. Because most of you are not building a SaaS platform. Your product is amazing but SaaS is simply not your main business!

And this is often the case. Many of the products offered as a service are truly amazing and life changing, but SaaS is an ecosystem of its own and should be treated as such, with a proper product plan, requirements and dev resources.

I dare to say that when SaaS is built haphazardly “around” your core product, it becomes like an ugly and murky glass to cover your beautiful portrait. And let’s be honest here, if your picture is a Mona Lisa, you’d want people to see it. But remember that a bad “SaaS experience” can overshadow even the most brilliant of ideas. 

The (technical) SaaS business

So let’s say you have an idea.

Your best idea yet!

And now you’ve reached a point where your POC is ready to be offered as a service to the world.

What happens next?

First, you start by adding a service to manage users and authentication. That service will proxy an online service providing a secure access solution. In order to engage with new users, you will need to send out emails to welcome them when they register. At that point, you recognize that you will be sending out emails more often than you thought, so you decide to develop a service that is responsible for it, proxying an external email delivery service. To complete the feature, you add an HTTP request to the proxy service, in order to send an email to your users once their registration is complete.

A theoretical simple flow would be:

  1. Search if user exists in DB
  2. Insert a new user profile data (personal info) to the DB in pending state
  3. Send a request to the secure access service in order to submit all authentication data.
  4. Local email proxy service (or even secure access service) sends an activation email.
  5. Client activates his user.
  6. Change user from pending state to active state in DB

Easy peasy…

The (technical) SaaS business

A few months and 10/100/1000s of users later — Customer support tickets starts piling up saying that they can’t register. You start digging through your logs and find out that your production env gets throttled with 429 HTTP status code (Too Many requests) by the external secure access service. 

You find yourself at a crossroads. On the one hand you can implement your own authentication service to handle the load which will take a long time to develop — just think about secure user handling, roles and permissions, profile management, JWT, JWK, multi-factor authentication, OpenID support, password reset, user activation — or you can spend (much) more money on a better subscription plan with the secure access service you are already using… Damn…

Let’s try something else:

One of the product guys wants to allow you to form groups within the product. You add another service to support such a feature —  the Team Management service. Now you can invite users to join your group and collaborate on a shared project.

To make the team aware of a new member joining, the product guy wants a notification to pop-up for all existing members. Yet again, you recognize that a new service is required since notifications will be used more than once. So you build a notifications service, one that can handle a high volume of requests.

After a few months, the product guy comes up with a new requirement: Notify the user whenever someone edits a shared project.

You use the notifications service for another spin off, and send the required notification on every edit.

Commit. Deploy. Done. 

A couple of hours later —

“We’re getting too many notifications!”

“This feature is unusable!”

The product had changed but the service was not built to handle it. The notifications service was built to only handle one-time-notifications: “A new user just joined the team!”, “User logged in”… Now when you have many events of the same type, you need to filter similar notifications.

OK OK! Let’s try again. One last time (To spice things up):

For compliance and security reasons, an audit logs service was developed to keep track of all the activities of the users.

The “Facepalm Architecture”
The “Facepalm Architecture”

To comply with different privacy and data protection laws, you are required to support user data deletion. Using only the services we described, let’s try to breakdown a possible flow:

  1. Send a delete request to the users service
  2. Set a user in “delete-pending” status
  3. Send an audit
  4. Block the user in the authentication service (doesn’t matter if you pay for it or developed a new one)
  5. Send an audit
  6. Remove the users from the teams they are in
  7. Send an audit (?)
  8. Send a notification to the team that the user left
  9. Send an email to the user that you’re sad to see him go
  10. Delete the user

And just when you think you’re done with development, you remember that you somehow need to test and deploy it.

Building SaaS properly is an area of expertise and it’s complex. That’s why I call this the “SaaS Facepalm Architecture” because that’s ultimately what you will do when trying to build it. Without a proper design, it will slow you down. Scaling your business is dependent on scaling your SaaS product and the two will eventually affect one another.

“So what is behind the technical business of SaaS and why is everything so highly interconnected?”

When building a good SaaS product, you need to allow your users to interact and engage in a secure way with your platform while at the same time ensuring that you get paid for the services you are offering. These requirements are all connected and overlap with one another. In order for you to avoid building the “Facepalm Architecture” you will need to create proper boundaries between these services.

Despite the fact that REST services are a great way to quickly begin your SaaS journey, they tend to introduce an “HTTP grid” that blurs the boundaries between one service and another by synchronously weaving features and tangling your code with numerous HTTP calls.
While it may seem like the solution is rather obvious, try to keep in mind how you even started your SaaS product, what your initial goals were when you started out building your business offering and how you added in those “SaaS things” along the way, probably not at the same level of finesse.

The post Distributed SaaS Monolith 101 appeared first on Frontegg.

]]>
https://frontegg.com/blog/distributed-saas-monolith-101/feed 0
RBAC vs. ABAC… Or maybe EBAC? https://frontegg.com/blog/rbac-vs-abac https://frontegg.com/blog/rbac-vs-abac#respond Thu, 03 Sep 2020 16:38:53 +0000 http://frontegg.com/?p=2586 Roles and permissions is a mandatory part of every application, especially when approaching larger customers with complex authorization needs.  The ability to control which user can do what, is an essential part of any B2B application, especially when approaching those enterprise deals that require granular control.   The AuthZ part is usually the second layer we […]

The post RBAC vs. ABAC… Or maybe EBAC? appeared first on Frontegg.

]]>

Roles and permissions is a mandatory part of every application, especially when approaching larger customers with complex authorization needs.  The ability to control which user can do what, is an essential part of any B2B application, especially when approaching those enterprise deals that require granular control.  

The AuthZ part is usually the second layer we choose to handle in our SaaS application. The first concern will usually be the Authentication of the users and being able to log them in securely. Once they are logged in, we will want to provide our users with mechanisms to restrict their access to specific resources based on the identity and the properties of the logged-in user.

But how can we protect the routes? What level of Authorization do we want to provide our users? Should we base our authorization on roles, organization units or locations?

All of the above are legit questions and concerns that each SaaS application owner faces at some stage of the application lifecycle. 

This post is a review of the differences between the traditional RBAC and the more modern ABAC in order for us to be able to choose the correct tool and method when providing AuthZ out of the box.

RBAC (Role Based Access Control)

RBAC is one of the most common and yet traditional approaches we tend to find on SaaS applications.

This concept is pretty straight forward. Based on your Role(s) in the organization, you need to  gain access to specific resources and specific permissions within these resources.

What does that look like to your users? As you can imagine, each user is assigned to one (or more) roles and each role is assigned permissions (sometimes referred to as actions). This results in a matrix as you can see below:

RBAC (Role Based Access Control)

So the combination of having a user that belongs to several roles and the combination of permissions which can also belong to several roles, leads to a flexible model that is oftentimes hard to manage. 

The approach above is one of the more standard approaches for RBAC based authorization but you’ll often find that along the way, when approaching more sophisticated customers, you are presented with additional service requests. These often include:

Granular RBAC — Delivering an application with 2-3 basic roles and permissions will do in most cases. However, when approaching more complex companies you will face demands for setting up additional “custom” roles based on the customer we are approaching. 

For example, we can deliver our application with “Admin”, “Maintainer” and “Operator” roles while the customer can create 2 additional roles of “read-only” and “support” and setting up additional permissions for it. 

In these cases, our APIs will need to be protected based on permissions and not roles as the roles in the system are dynamic.

Roles hierarchy — Another common use case with roles is being able to provide a hierarchy for roles. In that case if we decide that the “Team Leader” role is above the “Developer” role and “Team Leader” is blocked from certain permissions, we usually won’t allow this permission to be accessed by a lower level within the hierarchy.

So RBAC can be simple on one hand and extremely complex on the other hand. And it makes sense. But is it enough? How do we support grouping of users based on other properties they present such as Location / security level / time of day? 

Let’s try to challenge the RBAC model:

Let’s assume that in our organization we want the users to be able to deploy versions only if they are part of the C-Level approved list? How do we prevent users from deploying a version in the middle of the night? How do we ensure that they can  approve a PR only when they are connected via VPN?

ABAC (Attribute Based Access Control)

Unlike RBAC, Attribute Based Access Control (ABAC) takes into consideration other user attributes (where roles can be one such attribute,but not the only one).

These attributes can include:

  • The “Who” (user attributes)  — such as name, email, role, organization, country 
  • The “Where” (environment attributes) — such as the origin of the request, the user-agent on the browser etc.
  • The “What” (resource attributes) — Such as the owner of the resource that we are trying to access, the time it was created and so on. 

All of the attributes are being processed by an “Authorization engine” which evaluates and allows / denies the operation being discussed. The architecture will look like this (in most cases):

ABAC (Attribute Based Access Control)

Let’s challenge the ABAC model by providing a use-case which we couldn’t solve with RBAC: “Provide John (user attributes) with access to the company’s repository (resource attributes) only when connected via VPN (environment attributes).

Limiting a user’s access to specific resources from a specific location while striving for greater flexibility and the ability to control resources on a granular level is not a use case we were able to achieve within the basic RBAC.

So that sounds nice, but can we replace RBAC use cases with ABAC?

Let’s challenge that as well: “Provide access to users with “Admin Role” (user attributes) to the company’s repository (resource attributes).

So now we can handle Role Based filters with ABAC! 

Great! Should we switch?

Generally speaking, in most of these cases, your application will live long using RBAC alone so you probably should make use of it before setting up ABAC access control. 

As we saw before, RBAC can be accomplished with the use of ABAC (with filters on the user attributes), however ABAC requires more processing power and is much more complex to handle, implement and maintain.

As in most cases with SW development and product development, you should plan ahead. If your product is a super technological one and aims at nailing big enterprise deals with heavy granular security concerns, ABAC is the way to go. If the product is more suited to  SMBs or companies without heavy security concerns then RBAC will be simple to integrate.

EBAC as the hybrid approach?

Due to the complexity of the ABAC model, and the “over simplification” of the RBAC model there is a need to build hierarchies between RBAC and ABAC models. This approach is called EBAC (Entity Based Access Control)

EBAC is a simple subset of ABAC and doesn’t bring to the table any new concepts rather than a simplified model of ABAC.

Under the EBAC model, we will first use the RBAC engine in order to quickly determine the user’s first access layer and then we will operate the ABAC model in order to evaluate the requested entity.

While the implementation of both models seems like too much to handle, the hybridification of both RBAC and ABAC will improve dramatically the performance of the engine.In addition, for most use cases the environment variables and filters for ABAC will better suit  the “Firewall” use cases whereas the resource variable for ABAC will better suit SaaS applications with clustering of resources based on groups (for example, 10 repositories connected to the same tenant with different permissions based on the user attributes) 

Summary

The world of handling permission models in SaaS applications is a complex one and requires a deep understanding of the use cases and the different approaches that can help resolve this challenge.

As we have seen with the simple RBAC can work for the first version, however with enterprise deals we will need to pay attention to granular roles and permissions and hierarchies (for the advanced complex RBAC) and sometimes to advanced environment related attributes (with the use of ABAC)

At Frontegg we took all of these into consideration when building our SaaS as a Service platform. Have some questions on what is the correct model for you and how you should implement it? Feel free to reach out. We are here to help.

The post RBAC vs. ABAC… Or maybe EBAC? appeared first on Frontegg.

]]>
https://frontegg.com/blog/rbac-vs-abac/feed 0
Roles and Permissions Handling in SaaS Applications https://frontegg.com/blog/roles-and-permissions-handling-in-saas-applications https://frontegg.com/blog/roles-and-permissions-handling-in-saas-applications#respond Thu, 27 Aug 2020 08:30:07 +0000 http://frontegg.com/?p=2351 One of the first things you’ll need to decide when designing the initial version of your B2B SaaS application is how to regulate the product’s user management and permission handling aspects. At first, you probably won’t dive too deeply into permissions but rather try to solve everything by a super-admin role which allows every user […]

The post Roles and Permissions Handling in SaaS Applications appeared first on Frontegg.

]]>

One of the first things you’ll need to decide when designing the initial version of your B2B SaaS application is how to regulate the product’s user management and permission handling aspects. At first, you probably won’t dive too deeply into permissions but rather try to solve everything by a super-admin role which allows every user to do everything possible within the scope of their tenant (look for my blog on multi-tenancy for more info on this topic). But as things move further along (and get more complicated), requests for more advanced scoping of users’ permissions will arise. Different customers will require different degrees of granularity and different permission logics. 

Working without the precise business requirements for this topic might lead to decisions which will be far from optimal for your product’s ability to meet your customers’ needs. And since this is a critical topic with prominent security, privacy, and compliance aspects, this might cause some serious business trouble down the road.

How you manage Roles in SaaS applications

Phase 1 — All or Nothing

Since we don’t know what our users want, we will most likely go for the all-or-nothing approach and provide two roles: Admin and Read-only, when the former can do everything possible in the scope of their tenant/account and the latter can only see everything but not perform any state-changing actions.

Phase 2 — Business Specific Intermediates

When the need for more granularity will arise you will probably add some more specific roles according to the requests of your initial customers. These might include roles like Reporter, Commenter, Editor, etc. These roles will allow some additional permissions on top of the Read-only role, or exclude some highly-privileged permissions from the Admin role.

Phase 3 — When Reality Strikes

As you start to gain more advanced customers you’ll quickly discover that each one tends to manage their organizational scopes differently, based on varying segregation methods:

Structure-based segregation — These organizations will operate their roles in your SaaS application according to their organizational structure. Let’s imagine an organization with the following structure:

This company would want to provide each Product sub-organization with scopes of accessing different entities within their SaaS account, and even perform different sets of actions on these entities. For example, the Reporting feature may not be relevant to Product 1 sub-organization members, while the Editor feature may not be relevant to Product 3.

Function-based segregation — These organizations will manage scopes based on the specific roles within the organization. For example, looking at the previous organization chart, all Engineers will get a certain role and all Designers will get a different role: their permissions will be based on these predefined scopes.

Geography-based segregation — In this case the permissions and mostly visibility scopes will be managed according to the geography of the users within the organizations. The European department will get a certain set of permissions and the US department will get a different set of permissions.

Aim forLeast Privileged Access

By going for a generalized solution, you will most likely aim for the Pareto principle and meet the conditions of 80% of our potential customers. This might work to some extent when targeting SMBs. But if your potential customers are Mid-market or Enterprise, they will need tailor-made permission management at some point. The academics would claim that you should aim for perfection and go by the Least Privileged Access concept. This important security and control concept means that we shouldn’t allow a user to do anything more in the system than is required by them in order to perform their jobs. We all understand that almost no SaaS solution will meet this rule these days, unless really investing in the logic and development of their Roles and Permissions.

Of course, providing a perfect solution which will apply this rule to each and one of your customers and their end-users, will be a difficult task to achieve, so let’s see what are the type of compromises in this space and possible solutions for each and one of them.

Over Permissions

Providing a user with too many permissions for your app may sound like something that is just unnecessary. But from a security aspect it’s just flat wrong, as it increases the attack surface in an event of an account compromise. Also, it may open an opportunity to perform unnecessary actions by mistake, just because they are allowed by the system.

Solution: Provide Roles and Permissions granularity as part of your solution to allow customers to create and tailor their roles to any user.

Under Permissions

Users require a certain amount of capabilities from your system. But what if they need to perform an additional action? The initial question that this situation brings up is how will the account admin even be aware that an additional permission was requested. If that’s solved, what often happens is that the system is built in a way that in order to allow the additional action you will extensively increase the user’s scope and put them in the “Over Permission” state.

Solution: Provide Roles and Permission granularity with an advanced feature for Permission and access requests. As an example, think of the “Grant Access” request on a Google Drive document — If Google can do it, so can you!

Inactive Users

A private case of Over-Permission would be keeping users in the system while they are not actually using it. This could increase the attack surface on the specific account and confuse other users into thinking that a certain user is active and can perform tasks on the account.

Solution: Notify your customers when a certain user is inactive for some amount of time, or automatically inactivate the user until they decide to login and use the system. In the latter case they will need to reactivate their account once again (including email/identity verification).

Providing Enterprise-grade granularity and usage control

Granular access control with advanced management of roles and permissions isn’t something you would want to provide on your SaaS MVP. It is, however, definitely something your customers will require down the road. 

Within the usage-control universe some features are quite elementary, like allowing basic role assignment for users. Your more advanced customers will require the granularity and ability to control the sets of roles in their account. Finally, you can achieve a high level of control with advanced features that will enable your customers to optimize role assignment on their accounts. Now, this is true product differentiation and enterprise-readiness!

The post Roles and Permissions Handling in SaaS Applications appeared first on Frontegg.

]]>
https://frontegg.com/blog/roles-and-permissions-handling-in-saas-applications/feed 0
Multi-tenancy Trends in SaaS Applications https://frontegg.com/blog/multi-tenancy-trends-in-saas-applications https://frontegg.com/blog/multi-tenancy-trends-in-saas-applications#respond Wed, 12 Aug 2020 15:18:40 +0000 http://frontegg.com/?p=2130 The concept of multi-tenancy became a “thing” quite a while ago, when the need for more scalable and operational cloud-based B2B services started to gain popularity. Today there can be no disagreement that multi-tenancy is the essence of SaaS. But how is the SaaS community thinking about multi-tenancy today? Which aspects of it should be […]

The post Multi-tenancy Trends in SaaS Applications appeared first on Frontegg.

]]>

The concept of multi-tenancy became a “thing” quite a while ago, when the need for more scalable and operational cloud-based B2B services started to gain popularity. Today there can be no disagreement that multi-tenancy is the essence of SaaS. But how is the SaaS community thinking about multi-tenancy today? Which aspects of it should be considered as key, and what are the core assumptions under which multi-tenancy is operating? If you need to get up to speed on multi-tenancy, here’s a break-down of the latest trends and leading concepts governing it today. 

What is a “Tenant” anyway?

Different products use different naming conventions to refer to the concept that we call tenancy. Some call it an “Account”, “Customer”, “Workspace”, “Team” and more. They all refer to the same concept of a granular encapsulation level of a team, permissions, views, settings, and policies. But most of all, in my opinion, “tenancy” is about the business need. A typical B2B SaaS application provides business value to a specific business, so a tenant in our case would be defined as the specific business unit your SaaS serves.

What is “Multi-tenancy” in a nutshell?

Multi-tenancy in terms of B2B SaaS is the ability for a SaaS application to serve several customers (or accounts), from the same codebase, database, and production deployment. So, instead of having several separate production instances of your application (including Frontend, Backend and Data Layers) you can have one logical instance which serves many accounts, based on a set of permissions and associations.
NOTE: The environment still can (and should) be distributed and include multiple microservices and databases, which most likely be separated by business-domain and not by customer relevance.

What is Multi-tenancy

Different Aspects of Multi-Tenancy

Fifteen years ago, the multi-tenancy discourse was super technical since this was the main challenge organizations had to solve back then. Everyone had to deal with transitioning from years of on-prem software installations that didn’t require a real-time production database, to finding a scalable, secure, and operational-light way to establish a real-time service that accommodates hundreds and thousands of customers at once — from the same codebase and server.

During the last decade the technical solution standards have been formed and well defined. So nowadays, when everybody has a pretty good idea of how to solve multi-tenancy in their backend infrastructure, the discussion has moved to the operational level. Now, questions of how to handle proper development cycles, bug fixes, CI/CD, monitoring and scaling of multi-tenant SaaS environments are taking center stage. 

But even the operational angle is starting to get covered by standardized solutions. These are led by thought leaders in each of the above mentioned operational topics: Agile Development flows are promoted and adopted by companies like Atlassian for example, and Scaling and Monitoring are promoted by the open-source community with tools like Kubernetes, Prometheus, Istio and many more.

So it seems that the next level to cover is product. How to properly address the multi-tenancy on the user experience level? Should it even be called multi-tenancy in this context, or by some other name that will be more relevant to the business end-user? What are the main requirements and best practices in handling multi-tenancy in terms of your SaaS product? Is a real standard starting to form?

Key assumptions in your Multi-Tenant SaaS product

Granularity

While on the software engineering end a standard is already forming regarding best practices,  the situation in terms of Regulations, Security and Privacy is nowhere near as mature. In fact, in our experience, every customer will ask for a different permutation of roles, security policies and settings within your SaaS application. Don’t assume that you can define some set of assumptions on your backend and everyone would align accordingly. On the contrary, they will request their own roles, their own tenancy hierarchy management, their own authentication policies, their own data privacy rules, data filters, dashboard overviews, geo-location access policy, business settings and so on.

This means that you should provide a high level of granularity that will allow maximum flexibility within your app, so when a customer presents a new requirement (and they will…) you won’t need to run a quarterly estimated epic to meet this requirement or lose the deal

Although you don’t need the highest level of flexibility at the MVP stage, keep in mind that a mature SaaS product has to enable a rich level of tenant-based granularity for the different sets of customers.

Inversion of Control

You would think that supporting a rich and granular set of definitions per tenant is enough — but customers expect more than that. They also want to control these definitions on their own. Self-service and the ability to solve product-based requirements without the need to contact the SaaS vendor’s support is becoming a standard requirement when using SaaS applications. As a customer, you expect to have the full level of control over the product so if a concept exists within the app, it’s properties and settings can be fully controlled according to your requirements. 

This concept is becoming increasingly popular in several SaaS product essentials: 

  • SSO, where customers expect to be able to configure their own Identity Provider. 
  • Authentication, where customers expect to control their password complexity policy  and MFA.
  • Roles & Permission management, where customers want the ability to create their own set of roles. 
  • Events management, where customers want to be able to onboard their own channels and configure which events they want to receive on which channel.
  • Dashboards & Reports, where customers want to create their own overviews and reports and be able to schedule them in their convenient times.

And the list goes on: there are many more settings and configurations which should be managed by your customer without involving your support.

Scale for All

The Pareto rule may apply here. In many B2B SaaS cases, especially when a product becomes enterprise-facing in one of its tiers —  20% of your customers will produce 80% of activity within your app. This brings two main challenges to the table:

Allowing elastic scalability for every big customer

In many cases, a customer will start from a POC and then expand their usage of your product. So even if you end up maintaining two product environments, one for heavy-scale and one for small-scale customers, the migration experience should be seamless: the customer shouldn’t feel that they are being moved from one backend setup to another.

Avoiding starvation for small customers

The small customers matter and they will usually advance the “thought-leadership” and “bottom-up penetration” approaches. In any case, it’s clear that their user experience shouldn’t be compromised for the sake of accommodating the needs of the big sharks. Keep in mind that your system must be elastic to the extent that it can support small customers, big customers, and the seamless migration of small to big and vice versa.

Environment Flexibility

Allowing your customers to control where they want their tenant to reside — physically, is one of the main requirements for most SaaS products these days. The two main concepts that apply here are (1) Customer’s cloud and (2) Geo-flexibility.

Customer’s Cloud

As a SaaS vendor, you would have thought that with the adoption of cloud infrastructure all you need to do is deploy your system on your cloud cluster, develop a multi-tenant system there, boom, you’re ready to fulfill the needs of all your potential customers. Well, that’s not quite the case yet. The adoption of cloud doesn’t mean that on-prem is dead. In fact, in many cases, it just means that the new on-prem is now your customer’s cloud environment.

In other words, many of your customers will require an installation of your product in their cloud environment. The multi-tenancy infrastructure that you’ve developed should accommodate the requirement to have some of the tenants installed on their cloud.

Geo-flexibility

Due to GDPR and other geo-related restrictions on data access and storage, you need to be quite flexible in the physical geo-location in which your customers’ data resides. Some customers will even need user-based granularity so they could choose which end-users’ data resides on which geo-location.

Summing up

Multi-tenancy is no longer an engineering-only problem: it’s become one of the pillars of B2B SaaS applications and needs to be taken seriously. To handle multi-tenancy you need to start by conceptualizing the granularity level your customers will require. You then need to provide your customers with the highest level of self-service control over their account’s different configurations. 

At Frontegg we believe that Multi-tenancy is a core value for B2B SaaS, one that defines the solution’s maturity level and can make it or break it for different levels of customers. That’s why we build very flexible and granular tenancy management capabilities and full multi-tenancy support is embedded in each and one of our composable SaaS essentials, which we would love to tell you more about 🙂

The post Multi-tenancy Trends in SaaS Applications appeared first on Frontegg.

]]>
https://frontegg.com/blog/multi-tenancy-trends-in-saas-applications/feed 0