B2B SaaS Security For The Enterprise - Authentication

Intro - Building For The Enterprise

When selling your product to the enterprise, you will face a lot of scrutiny from security teams. 

My goal here is to a) help you understand what is ahead on this journey and b) help reduce any friction you may encounter along the way.

You will face scrutiny from all angles, such as the dreaded security questionnaire as well as technical challenges.

In this article I want to highlight two technical challenges you will likely face. I plan on publishing more as part of a larger collection on this topic.

SSO Integration

As a provider, you will be asked to provide SSO integration into your clients IdP (Identity Provider). This can be a SAML or OIDC connection back to their IdP (Okta, Onelogin, Google, for example).

SAML is the most popular options, however companies are starting to adopt OIDC as well. I would recommend building compatibility for both types of integrations.

In SAML terms, your application would be considered a Service Provider.

By default your application would need to support IdP initiated authentication. This means that the enterprise user would login to their SSO provider, find a tile with your app on it, click it, and be magically logged in.

An optional item would be to create a SP Initiated login flow. The main reason to do this imho is to reduce user friction. The flow in this case would start at your app’s login page where they would enter their email for example and a magical redirect and auth flow happens to their provider and viola, they’re logged in!

Anyway, this was not meant to be a primer on SSO, but instead a recommendation to build that functionality into your app sooner than later.

I’ve seen companies deny the POC and purchase of apps simply because they didn’t support SSO. 

AWS-AWS Authentication

If your application is designed to pull data from a customer’s AWS account, then pay attention here.

Old Way Of AWS - AWS Authentication

You are likely familiar with this and probably doing this already.. Asking your customers for IAM keys into their accounts to access their metadata.

This is not the way.

Why?

Problems With IAM Keys

🔑 IAM Keys are long term keys that do not expire

Whenever you provide access to your

🔑 Communicating of those IAM keys need to be done securely. 

Oftentimes, keys are being distributed via insecure methods. I’ve seen them in:

• Github Gists

• Github Repos

• Public Slack channels

• Email

These mediums are considered insecure by nature.

Thank you for reading Last Week As A vCISO. Share this guide with your network.

🔑 Insecure Storage of IAM Keys

Ok, say you send it via SendSafely for example. Now what? How do you know they’re not being stored in a note file on someone’s desktop or in a Google doc? You don’t!

Once a key leaves your environment, you have no control over how it is handled

Sure, you can have all the policies, certifications, and contracts you want, but you do not have any guarantee it’s being handled safely.

🔑 IAM Keys Can Be Used By Anyone

There is no implicit trust mechanism attached to an IAM Key. Anyone who has the Access and Secret key can do whatever they want with the privileges attached to those keys, from anywhere. 

This goes back to the above, how do you know they’re being stored securely and not accessible to a whole bunch of engineers, interns, and maybe 3rd parties?

Ok, I went on a bit of a rant, but I hope you get the picture!

💪🏽Modern Approach Towards AWS-AWS Authentication

Use Cross Account Role

The best way to access a customer’s AWS account is using a cross-account role. This sets up a Trust Relationship between AWS accounts where access is purely on the AWS account level.

This is the way.

Now of course, this means that anyone or service in the source AWS account can access the destination AWS account, but that is why you need to use a designated AWS account for this kind of information. It can be your Prod AWS account, or for better segmentation a special AWS account designated for inbound data ingestion and triage, with limited user access.

Summary

As you can see, the common theme is here temporary authorized access. Long lived access (passwords, static secrets, etc), should be phased out as much as possible. Relying on temporary, finely scoped, and revocable is the way to proper authentication.

Identity is the new perimeter.

Thank you for reading Last Week As A vCISO. This post is public so feel free to share it.