Effortless Onboarding and Modern Safety Features for SaaS on AWS with Katanemo

By Salman Paracha, Founder/CEO – Katanemo
By Syed Hussain, Solution Architect – AWS SaaS Factory
By Jessica Koh – Contributing Writer

Today, developers building modern software as a service (SaaS) applications are faced with an increasingly complex trade-off between usability and security. On the one hand, they want users to simply and seamlessly access their applications. On the other, they must prevent access to data and functionality that should not be seen by other users.

Access patterns and safety controls, particularly in multi-tenant SaaS apps, are far more complex than traditional consumer applications. Can your SaaS application go from supporting a single user in a team to effortlessly serving thousands of enterprise users via single sign-on? Can it offer automation via application programming interfaces (API) keys? Can it support modern fine-grained access controls needed for privacy, security and collaboration before businesses can trust you with their data and workloads?

In this post, we’ll explore how to leverage Katanemo, a powerful identity, and fine-grained permissions system purposefully designed for modern SaaS applications. With Katanemo, you can quickly add user and federated authentication to your application, and build powerful privacy and collaboration features via Katanemo’s rich role-based access control (RBAC) and attribute-based access control (ABAC) capabilities.

Katanemo offers a holistic approach to identity, privacy, and safe collaboration that empowers developers to focus on what matters most: moving fast in building features and capabilities unique to their business.

In working with AWS SaaS Factory, Katanemo applied the SaaS Lens for the AWS Well-Architected Framework as it offers guidance on best practices for multi-tenant workloads like tenant isolation, onboarding, and monitoring. As a result of this exercise, the SaaS Factory team was able to assess Katanemo’s architecture, validate an optimal build, and recommend areas for further optimization.

“Despite our decades of experience in building at-scale cloud services, we gained even more confidence via the SaaS Lens review that we are building a solution that follows AWS’s best practices. We look forward to further hardening our SaaS service, as we eliminate the infrastructure tax developers pay today to build modern SaaS applications.” – Salman Paracha, Founder and CEO of Katanemo

Figure 1 – How Katanemo works.

Katanemo is an AWS Partner and new development platform for building API-first software applications. They are helping product leaders effortlessly serve new usage scenarios, engineering leaders eliminate risky and undifferentiated infrastructure tax to build SaaS applications, and empowering CEOs to upsell via critical enterprise-ready features. Katanemo’s first service offering is a powerful, identity and fine-grained permissions system for SaaS developers.

Product Overview

The Security Pillar of the SaaS Lens for the AWS Well-Architected Framework emphasizes the need to elevate tenant context as a first-class construct, connecting it directly to the overall authentication and authorization model of a SaaS application.

The paradigm shift to favor service-oriented architectures has increased the number of APIs that must use a form of authorization and access control. The need to maintain tenant-based access in a multi-tenant SaaS application can become very complex, where siloed or highly inefficient techniques are often used to preserve the trust you want to offer your customers. Katanemo solves this problem by elevating tenant context as a first-class construct, and makes it easier for developers to build modern SaaS applications.

To demonstrate Katanemo, we’ve built an API-first sample application deeply inspired by the Serverless SaaS Reference Solution that’s built by the AWS SaaS Factory program. The sample application walks through a real-world electronic health record (EHR) SaaS service that manages patient and diagnostic records on behalf of hospitals and care provider facilities via APIs.

The project uses Katanemo’s full feature set, and highlights how Katanemo simplifies the Serverless SaaS Reference Architecture by removing the need for developers to build, deploy, and manage several custom applications, infrastructure and user interface (UI) components.

Figure 2 – Before Katanemo: Traditional SaaS reference architecture.

Below, Figure 3 shows what the SaaS reference architecture looks like after Katanemo. The sample EHR SaaS application no longer needs the following shared services: a) tenant management; b) user management; and c) registration and several web applications. This is because these are now offered as part of the managed experience provided by Katanemo.

That means less infrastructure pieces, less UI work, and less security and custom application code that we need to build, secure, and operate ourselves.

Figure 3 – After Katanemo: Modern SaaS reference architecture.

Getting Started: Sign-Up and Tenant Administration via Katanemo

Let’s demonstrate Katanemo’s capabilities via the sample EHR SaaS application.

First, we must sign up for a Katanemo developer account and create a Katanemo Service. A Katanemo Service essentially describes a SaaS application (via APIs) for which developers get hosted user and enterprise authentication workflows, and a set of identity and access management (IAM) capabilities that tenants can use to scale the administration of identities and achieve the principle of least-privilege in a fully self-service way.

“The principle of least privilege is an important security construct for SaaS providers fighting today’s asymmetric battle against prolific, relentless and sophisticated attackers. Developers must protect from cyberattacks and the financial, data and reputational losses that follow when ransomware, malware and other malicious threats impact their APIs.” – Salman Paracha, Founder and CEO of Katanemo

To create a Katanemo Service, we’ll use its command-line interface (CLI). First, we install the CLI, clone the sample EHR SaaS application to our local machine, and navigate to the /samples/ehr-service directory.

Now, we are ready to create a Service via the ‘init-service’ command using an access token for our Katanemo account. Note that you can find all the commands shown below in the README section of the sample EHR SaaS application. Figure 4 shows how to create a Katanemo Service via its command line utility.

Figure 4 – Katanemo CLI commands to create service.

Next, let’s look at what’s going on here. The ‘init-service’ command takes several inputs, including an OpenAPI 3.0 spec of the sample EHR SaaS application. The OpenAPI spec neatly captures resource schemas, API paths, and HTTP methods of the sample EHR SaaS application, and is a critical building block in Katanemo’s authorization engine. We’ll discuss authorization and policies in detail later in this post.

Once we run the ‘init-service’ command, it returns a few things, including a sign-up/login URL for our EHR SaaS service where we can seamlessly onboard tenants, and a URL to the SaaS administration console where we can manage tenants, update or create new Services, and analyze access logs that help us meet exacting compliance requirements.

Figure 5 shows the Overview page of the SaaS administration console.

Figure 5 – SaaS developer customer/tenant administration portal.

Deploy Sample EHR SaaS Application on AWS

Now that we can effortlessly sign up tenants and manage them via the Katanemo SaaS administration console, we need a way for our tenants to seamlessly define authorization strategies for identities that will use our service. This is a good segue to talk about the specifics of the sample EHR SaaS application, its APIs, and how to deploy it in our AWS account.

Our EHR SaaS Service has two microservices: 1) patient and 2) diagnostics, which manage records on behalf of our tenants: hospital and care provider facilities. Tenants must be able to create and manage patient records and diagnostics reports, and share diagnostic reports with patients and other care provider facilities.

The strict nature of privacy in healthcare means our tenants have strict requirements on the safety of patient and diagnostic records. Specifically, doctors should be the only ones who can update patient records, while hospital admins can create new patients, read doctor notes and update diagnostic reports.

Figure 6 is an example of a high-level architecture of the sample EHR SaaS application.

Figure 6 – Serverless EHR SaaS application architecture.

This combinatorial complexity of access patterns is not unique to just healthcare scenarios. These types of access patterns are now commonplace in FinTech, artificial intelligence (AI), infrastructure, and other modern SaaS applications. Katanemo makes the complex simple by offering a blazing fast permissions system that utilizes standards like OpenAPI and RESTful semantics as the foundation for its rich permissions language.

With Katanemo, we empower tenants to construct authorization policies to match specific business and operational needs in a self-service way without having to build, secure, and maintain a feature-rich authorization service.

To get started, we navigate to the /samples/ehr-service directory of the sample application on our local machine, and run deploy.sh to deploy the EHR SaaS service in our AWS account. The deploy.sh command takes our Katanemo account credentials and neatly integrates Katanemo’s authorization components via an AWs Lambda authorizer for our Amazon API Gateway endpoint.

Now, the EHR SaaS service is ready to perform fine-grained access control via Katanemo.

Self-Service Identity and Authorization Administration

With Katanemo, tenants can scale the administration of identities and manage fine-grained access controls in a fully self-service way. Similar to the SaaS provider administration console, our tenants (AcmeHealth.io) use Katanemo’s Customer Identity & Access Management (CIAM) console to add users and assign them attributes and job-specific permissions to use the EHR SaaS service. To get started, our tenants first navigate to https://console.katanemo.com/sign-up?service_id=<ehr_id>

Next, we’ll demonstrate that an admin from AcmeHealth.io signed up for our EHR service and is using the CIAM console to invite the user salman+doctor+acmehealth to use our EHR SaaS service. The user gets assigned a “doctor access” role, along with a tag key/value pair of “function” = ”doctors”.

The combination of the role assigned (RBAC) and tag key/value pair (ABAC) determines what a user can do in the EHR SaaS service. Figure 7 shows how a SaaS customer can set attributes and invite users to use a SaaS application.

Figure 7 – Invite user and set attributes via Katanemo CIAM.

The “doctor access” role was created previously via the CIAM console, but the screenshot above didn’t capture its details.

policy:
version:1.0
- allow: 
    - GET:/patient/{patientId}
    - PUT:/patient/{patientId}
  where: $principalTags:function = 'doctors'
- allow
    – POST:/diagnostic
    - GET:/diagnostic/{diagnosticId}
   where: $principalTags:function = 'doctors’

The “doctor access” role has a policy which allows a user to update and get patient records only if they are tagged with the “function” = “doctors” key/value pair, while the same user can create and/or read diagnostics records.

Meanwhile, $principalTags and $resourceTags are reserved words in Katanemo’s OpenAPI-based permissions language, which enable tenants to express powerful fine-grained access controls via simple and familiar semantics: HTTP methods and API paths. You can learn more about Katanemo’s OpenAPI (and GraphQL) based permissions language via these documents.

Authorizing API Calls via ARC

Now, let’s show three access scenarios via simple cURL commands to the endpoint of our EHR SaaS service. Note that the endpoint of our EHR SaaS service was created when we ran deploy.sh earlier. Figure 8 shows the cURL commands we will run below and the expected output.

An admin of AcmeHealth.io creates a patient successfully (shown as $subscriber_token below), and salman+doctor+acmehealth@katanemo.com tries to create a patient but fails because it doesn’t have the necessary permissions (shown as $doctor_token below).

Next, salman+doctor+acmehealth@katanemo.com tries to get patient details and the call succeeds.

Figure 8 – cURL calls to EHR SaaS application protected via Katanemo.

Success!

So where is the authorization happening in our EHR SaaS service? If we look closely at the sample application, we see that a Lambda authorizer is configured with an Amazon API Gateway endpoint for our EHR SaaS service. This Lambda authorizer calls Katanemo Authorization Runtime Client (ARC), a lightweight runtime client that handles all the heavy lifting of authentication and authorization on behalf of our SaaS service.

Figure 9 below shows the Lambda authorizer code which calls Katanemo ARC for authorization.

Katanemo ARC does intelligent caching and ensures the authorizations latency budget stays within <1ms for p90 calls. ARC avoids roundtrip network calls to Katanemo’s cloud endpoints and is notified via a proprietary machine learning (ML) model on when to update its cache to ensure permissions and policies follow a strict causal order.

Lastly, the Lambda authorizer returns an IAM policy as output based on the authorization results from ARC.

Figure 9 – AWS Lambda authorizer code calls Katanemo ARC for authorization.

Conclusion

In this post, we examined how Katanemo’s powerful identity and fine-grained permissions system enables developers to effortlessly onboard customers, and build modern safety features for their SaaS applications on AWS.

To accompany this post, you can read additional guides by Katanemo on how tenants can quickly set up single sign-on, and how developers can build ABAC authorization via tags and meet compliance requirements via access logs APIs.

About the SaaS Lens for the Well-Architected Framework

The SaaS Lens for the AWS Well-Architected Framework enables customers to build and validate their SaaS architectures against best practices and better understand the business impact of their SaaS design decisions. It address general design principles as well as specific best practices and guidance in five conceptual areas that we define as the pillars of the AWS Well-Architected Framework.

About AWS SaaS Factory

AWS SaaS Factory helps organizations at any stage of the SaaS journey. Whether looking to build new products, migrate existing applications, or optimize SaaS solutions on AWS, we can help. Visit the AWS SaaS Factory Insights Hub to discover more technical and business content and best practices.

SaaS builders are encouraged to reach out to their account representative to inquire about engagement models and to work with the AWS SaaS Factory team.