DEV Community: Pangea

Add Audit Log Streaming to Auth0 authentication in < 2 mins

Pranav Shikarpur — Tue, 25 Jun 2024 01:00:54 +0000

In a world where hackers are trying to brute force user accounts (23andMe breach 2023), it is vital for developers to maintain a long-lasting and tamper-proof audit log of all authentication events to keep their apps secure.

While many companies use Auth0 as an authentication provider, its log data retention periods ONLY range from 1-30 days depending on the Auth0 subscription level. Although this span may seem useful for application debugging, it’s not optimal for meeting compliance requirements due to such short retention periods.

Thus, adding log streaming with Pangea allows you to keep your Auth0 authentication setup while using Pangea to retain logs for up to 10 years! The best part is that everything can be configured directly in the Auth0 dashboard without any changes to your code base.

What are the Advantages of a Tamperproof Audit Log?

If you’re just interested in implementing audit log streaming for Auth0, you can skip ahead to the next section. No offense taken 😉

Identify Risk of Exposure

A robust tamperproof audit log can help quickly assess the risk of exposure after a data breach since you have logs of all user events and critical user actions that occurred in our app.

Tamperproof logs

Since message hashes of Pangea Audit Logs have been designed to be stored in a cryptographically secure hash-tree called “Merkle Trees”, the logs are tamperproof and cryptographically verifiable. Thus Pangea Audit Logs can neither be changed nor destroyed once created.

Asynchronous Logging

Since Pangea Audit Logs can be implemented asynchronously with our authentication system and APIs, it doesn’t affect the performance of our web apps.

TLDR; How do I build it in?

In this tutorial, I will demonstrate how easy it is to add Pangea’s tamperproof audit log API to your Auth0 authentication setup in just a few clicks. No changes to your codebase are needed 😅

Step 1: Create an account on pangea.cloud

Head over to pangea.cloud and create an account for free. Then in the developer console, enable the “Secure Audit Log” service and select the Auth-vX.X.X Log Streaming for the schema template.

Step 2: Create an event stream in Auth0 Dashboard

In your Auth0 dashboard, go to Monitoring >> Streams and click Create Stream. Under the event stream options, select Custom Webhook

Step 3: Copy your Pangea credentials to setup the webhook

In the Custom Webhook setup window, you’ll be asked to input the following:

Payload URL - Enter the URL for your Pangea project log-streaming endpoint. You can find it here.
Authorization Token - Enter the Authorization header value to access your Secure Audit Log configuration. This would be Bearer <insert_pangea_token>
Content Type - Leave it as application/json.
Content Format - Select JSON Object.

Then you can hit Save! Now, if you head over to the Health tab under the newly created webhook, you should see a success message saying your webhook is Active.

Here’s a quick video on configuring your webhook with Pangea credentials:

Finally, heading over to my react app pre-configured with my Auth0 credentials, let’s log in and log out. To check that our audit logs are being streamed let us head over to the Pangea Console under Audit Log >> View Logs. In here, we should see new logs populated from our app streamed straight from Auth0.

Let's test it out!

Add "Login with Passkeys" to your Django app

Vanessa V — Tue, 04 Jun 2024 22:15:40 +0000

Passkeys, passkeys, passkeys! Everyone's talking about them. With Amazon rolling out passkeys last year and Google encouraging users to make them the default authentication method, it raises the question: How do I add them to my app?

How do passkeys work?

If you’re just interested in implementing them, you can skip this section. No offense taken 😉

FIDO2 multidevice credentials more often referred to as “passkeys” is a standard introduced by the FIDO alliance. It’s an extremely powerful way of using public-key cryptography to verify the identity of a user without passwords, multi-factor, etc. The public / private key pair is usually generated and securely stored on a hardware or software authenticator device.

To learn more about how passkeys and authenticators work in detail, check out the Secure By Design Hub article on passkeys.

How do I build it in?

In this tutorial, we’re going to leverage Pangea AuthN’s hosted pages to be able to quickly configure passkeys without building all the cryptographic mayhem from scratch 😅. To prove that it’s easy to add passkeys into any application in just a few minutes, I’m going to start with a fresh new Django app and implement passkeys in just a few steps.

Step 1: Create a new Django app and install needed dependencies

python -m pip install django
django-admin startproject mysite
cd mysite
python manage.py startapp authme
pip install python-dotenv pangea-django
python manage.py migrate

Let's go to mysite/mysite/settings.py to allow our app to use these packages.

We need to be able to:

load a .env file
access the pangea-django middleware
load our HTML pages from a designated templates folder

from dotenv import load_dotenv
import os
from pathlib import Path

load_dotenv()

# Skip down to the middlware declaration. 
# Comment or remove the default django middleware. 
# Add Pangea's Auth Middleware

MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "django.contrib.sessions.middleware.SessionMiddleware",
    "django.middleware.common.CommonMiddleware",
    "django.middleware.csrf.CsrfViewMiddleware",
    #"django.contrib.auth.middleware.AuthenticationMiddleware",
    "pangea_django.PangeaAuthMiddleware",
    "django.contrib.messages.middleware.MessageMiddleware",
    "django.middleware.clickjacking.XFrameOptionsMiddleware",
]

# Replace the default configuration with the templates below
# templates folder is where we will keep our html

TEMPLATES = [
    {
        "BACKEND": "django.template.backends.django.DjangoTemplates",
        "DIRS": [os.path.join(BASE_DIR, "templates")],
        "APP_DIRS": True,
        "OPTIONS": {
            "context_processors": [
                "django.template.context_processors.debug",
                "django.template.context_processors.request",
                "django.contrib.auth.context_processors.auth",
                "django.contrib.messages.context_processors.messages",
            ],
        },
    },
]

Step 2: Create an account on pangea.cloud

Head over to pangea.cloud and create an account for free. Then in the developer console, enable the “AuthN” service and grab the following tokens.

These tokens will be pasted in your .env config file as shown below. Create and add these tokens into mysite/.env file like this:

PANGEA_AUTHN_TOKEN=<PANGEA_AUTHN_TOKEN>
PANGEA_DOMAIN=<PANGEA_DOMAIN>
PANGEA_HOSTED_LOGIN=<PANGEA_HOSTED_LOGIN>

Step 3: Add the Pangea Auth components to the new Django app

Now we edit our mysite/authme/views.py file with the pangea_django package that maintains authentication context and state across the application.

So our authme/views.py file should look like this:

from django.shortcuts import render, redirect
from django.contrib.auth.decorators import login_required
from pangea_django import PangeaAuthentication, generate_state_param
import os

# Create your views here.

def landing(request):
    if request.user.is_authenticated:
        return redirect("/home")

    hosted_login = os.getenv("PANGEA_HOSTED_LOGIN")
    redirect_url = hosted_login + "?state=" + generate_state_param(request)

    return redirect(redirect_url)

def login_success(request):
    user = PangeaAuthentication().authenticate(request=request)
    if user:
        return redirect("/home")
    return redirect("/")

@login_required(login_url="/")
def logout(request):
    user = PangeaAuthentication().logout(request)
    return redirect("/logout")

@login_required(login_url="/")
def home(request):
    context = {}
    context["user"] = request.user
    return render(request, "home.html", context)

Next we need to map these views to paths. We do this in mysite/mysite/urls.py

from django.urls import path
import authme

urlpatterns = [
    path('', authme.views.landing),
    path('home', authme.views.home),
    path('login_success', authme.views.login_success),
    path('logout', authme.views.logout),
]

The app need to be able to access mysite/authme/views.py from mysite/mysite/urls.py. Add this line to mysite/authme/__init__.py

from . import views

Lastly we need a page for this authentication to render to. The way we make pages in Django is by creating a templates folder with html pages. Since authme.view.home is routing to <base url>/home, we need to call our page mysite/templates/home.html

<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<style>
body,h1,h2,h3,h4,h5,h6 {font-family: "Lato", sans-serif;}
body, html {
  height: 100%;
  color: #b47b00;
  line-height: 1.8;
  background-color: antiquewhite;
}
table {
  margin: 0px auto;
  background-color: white;
  padding: 25px;
}
tr {
  font-family: Verdana, Tahoma, sans-serif;
  font-size: 20px;
  color: #rgb(158, 108, 0);
}
td {
  padding: 2px;
}
</style>
</head>
<body>
  <!-- Navbar (sit on top) -->
  <div>
    <a href="logout">LOGOUT</a>
  </div>
  <!-- Navbar (sit on top) -->
  <h1 style="text-align: center;">You are logged in!</h1>
    <table>
        <tr>
            <td>ID:</td>
            <td>{{ user.id }}</td>
        </tr>
        <tr>
            <td>Email:</td>
            <td>{{ user.email }}</td>
        </tr>
        <tr>
            <td>First Name:</td>
            <td>{{ user.first_name }}</td>
        </tr>
        <tr>
          <td>Last Name:</td>
          <td>{{ user.last_name }}</td>
        </tr>
        <tr>
          <td>Last Login:</td>
          <td>{{ user.last_login }}</td>
        </tr>
    </table>
</body>
</html>

Step 4: Add Redirect and Enable Passkeys in Pangea console

We need to add an authorized redirect, so that Pangea’s AuthN hosted pages can successfully redirect us back to the http://127.0.0.1:8000/home when a user is done authenticating.

So first, let’s go under General > Redirect (Callback) Settings and add http://127.0.0.1:8000/home as a redirect and save it.

Here comes the last step, let’s enable Passkeys! Head over to Single Sign On > Passkeys and enable it. Optionally you can choose to enable fallback authentication options based on your desired user experience.

Here’s a quick video on how you can enable it in settings:

Let's try it out! You can find the code in Github and watch the demo below.

If you are looking to add AuthN to other languages or frameworks, follow these tutorials:

Add "Login with Passkeys" to your Next.js app in <2 mins (Page Router Mode)

Pranav Shikarpur — Tue, 28 May 2024 17:04:36 +0000

How do passkeys work?

If you’re just interested in implementing them, you can skip this section. No offense taken 😉

To learn more about how passkeys and authenticators work in detail, check out the Secure By Design Hub article on passkeys.

How do I build it in?

In this tutorial, we’re going to leverage Pangea AuthN’s hosted pages to be able to quickly configure passkeys without building all the cryptographic mayhem from scratch 😅. To prove that it’s easy to add passkeys into any application in just a few minutes, I’m going to start with a fresh new Next.js app and implement passkeys in just a few steps.

Step 1: Create a new NextJS App and install Pangea AuthN react wrapper

npx create-next-app --ts --eslint --tailwind --src-dir passkeys-demo
cd passkeys-demo
npm i @pangeacyber/react-auth

Note: Select "No" when the create-next-app command asks if you want to use the App Router mode. In this tutorial, we will be using the Next.js page router mode.

Step 2: Create an account on pangea.cloud

Head over to pangea.cloud and create an account for free. Then in the developer console, enable the “AuthN” service and grab the following tokens. These tokens will be pasted in your .env config file as shown below.

NEXT_APP_LOGIN_URL="<PROJECT_HOSTED_LOGIN_URL>"
NEXT_APP_CLIENT_TOKEN="<PROJECT_CLIENT_TOKEN>"
NEXT_APP_PANGEA_DOMAIN="<PANGEA_DOMAIN>"

Step 3: Add the Pangea React Auth components to the new Next app (Page Router Mode)

Now we edit our _app.js file with the <AuthProvider> component that maintains authentication context and state across the application.

So our _app.js file should look like this:

import "@/styles/globals.css";
import type { AppProps } from "next/app";
// Pangea imports
import { AuthProvider } from "@pangeacyber/react-auth";

export default function App({ Component, pageProps }: AppProps) {
  // Setup props with Pangea AuthN config
  const hostedLoginURL = process?.env?.NEXT_PUBLIC_AUTHN_HOSTED_LOGIN_URL || "";
  const authConfig = {
    clientToken: process?.env?.NEXT_PUBLIC_AUTHN_CLIENT_TOKEN || "",
    domain: process?.env?.NEXT_PUBLIC_PANGEA_DOMAIN || "",
  };

  return (
    <AuthProvider loginUrl={hostedLoginURL} config={authConfig}>
      <Component {...pageProps} />
    </AuthProvider>
  );
}

Now that we have the AuthProvider keeping context across the application, we can now implement the login functionality by simply calling the useAuth hook in our index.js file. Let’s also add a conditional redirect in a useEffect hook to automatically redirect a user if they’re logged in to a page called /login-success that we will create later.

Thus your index.js file should look like this:

// Pangea AuthN imports
import { useAuth } from "@pangeacyber/react-auth";
import { useEffect } from "react";
import { useRouter } from "next/router";

export default function Home() {
  const { authenticated, user, login, loading } = useAuth();
  const router = useRouter();

  useEffect(() => {
    if (authenticated && !loading) {
      // Redirect to /login-success if user is authenticated
      router.push("/login-success");
    }
  }, [user, authenticated, loading])

  return (
    <div className="flex flex-col items-center justify-center h-screen bg-gradient-to-br from-[#8b5cf6] to-[#a855f7]">
      <h1 className="text-4xl font-bold text-white mb-6">Login with Passkeys 🔑</h1>
      <button
        className="inline-flex items-center justify-center rounded-md bg-white px-4 py-2 text-sm font-medium text-[#8b5cf6] shadow-sm transition-colors hover:bg-gray-100 focus:outline-none focus:ring-2 focus:ring-[#8b5cf6] focus:ring-offset-2 mb-6"
        onClick={login}
      >
        Login
      </button>
      <a
            className="text-xl font-light text-blue-300 underline"
            href="https://pangea.cloud/services/authn/?utm_source=blog&utm_medium=passkeys-nextjs-snippet"
            target="_blank"
            rel="noopener noreferrer"
          >
            Try Pangea AuthN for free today!
      </a>
    </div>
  );
}

Now that we have our login page, let’s define an authenticated page called login-success.tsx by using the useAuth hook to get user information and display it.

Thus your login-success.tsx file should look like this:

// Pangea AuthN imports
import { useAuth } from "@pangeacyber/react-auth";
import { useEffect } from "react";
import { useRouter } from "next/router";

export default function Home() {
  const { authenticated, user, logout, loading, getToken } = useAuth();
  const router = useRouter();

  useEffect(() => {
    if (!authenticated && !loading) {
      // Redirect to / if user is NOT authenticated
      router.push("/");
    }
  }, [user, authenticated, loading])

  return (
    <div className="flex flex-col h-screen w-full items-center justify-center bg-gradient-to-br from-[#7e22ce] to-[#a855f7]">
      <div className="rounded-lg bg-white p-8 shadow-lg w-full max-w-md">
        <div className="flex items-center justify-between mb-6">
          <div className="bg-gray-100 px-3 py-1 rounded-full text-sm text-gray-500">hi {user?.email}</div>
          <button
        className="inline-flex items-center justify-center rounded-md bg-white px-4 py-2 text-sm font-medium text-[#8b5cf6] shadow-sm transition-colors hover:bg-gray-100 focus:outline-none focus:ring-2 focus:ring-[#8b5cf6] focus:ring-offset-2 mb-6" onClick={logout}>
            Sign Out
            </button>
        </div>

        <div className="flex items-center justify-start g">
          {/* Fun lil GIF */}
          <div className="flex flex-col"><iframe src="https://giphy.com/embed/IwAZ6dvvvaTtdI8SD5" width="480" height="400" frameBorder="0" className="h-3/4 w-3/4" allowFullScreen></iframe><p className="text-xs"><a href="https://giphy.com/gifs/theoffice-the-office-tv-michaels-birthday-IwAZ6dvvvaTtdI8SD5">via GIPHY</a></p></div>

          {/* Access user's information through user variable */}
          <p className="flex-none text-[#8b5cf6]">User Name: {user?.profile.first_name} {user?.profile.last_name}</p> 
        </div>
      </div>
      <div className="space-y-4 mt-6">
          <div className="flex items-center space-x-4">
          <a
            className="text-xl font-light text-blue-300 underline"
            href="https://pangea.cloud/services/authn/?utm_source=blog&utm_medium=passkeys-nextjs-snippet"
            target="_blank"
            rel="noopener noreferrer"
          >
            Try Pangea AuthN for free today!
          </a>
          </div>
      </div>
    </div>
  );
}

Step 4: Enable Passkeys Authentication in Pangea console

Since we have a /login-success page to redirect to on successful authentication, we need to add an authorized redirect so that Pangea’s AuthN hosted pages can securely redirect a user back to the http://localhost:3000/login-success when done authenticating.

So first, let’s go under General > Redirect (Callback) Settings and add http://localhost:3000/* as a redirect and save it. This will allow redirects to all routes on our host http://localhost:3000.

Here comes the last step, let’s enable Passkeys! Head over to Single Sign On > Passkeys and enable it. Optionally you can choose to enable fallback authentication options based on your desired user experience.

Here’s a quick video on how you can enable it in settings:

Let’s test it out! You can find the code in Github and watch the demo below.

If you are looking to add Pangea AuthN to other languages or frameworks, follow these tutorials:

Add "Login with Passkeys" to your React.js app in < 2 mins

Pranav Shikarpur — Wed, 03 Apr 2024 15:06:10 +0000

How do passkeys work?

If you’re just interested in implementing them, you can skip this section. No offense taken 😉

To learn more about how passkeys and authenticators work in detail, check out the Secure By Design Hub article on passkeys.

How do I build it in?

In this tutorial, we’re going to leverage Pangea AuthN’s hosted pages to be able to quickly configure passkeys without building all the cryptographic mayhem from scratch 😅. To prove that it’s easy to add passkeys into any application in just a few minutes, I’m going to start with a fresh new React.js app and implement passkeys in just a few steps.

Step 1: Create a new React App and install Pangea AuthN react wrapper

npx create-react-app passkeys-demo && \
cd passkeys-demo && \
npm i @pangeacyber/react-auth

Step 2: Create an account on pangea.cloud

Add these tokens into a .env file like this:

REACT_APP_LOGIN_URL="<PROJECT_HOSTED_LOGIN_URL>"
REACT_APP_CLIENT_TOKEN="<PROJECT_CLIENT_TOKEN>"
REACT_APP_PANGEA_DOMAIN="<PANGEA_DOMAIN>"

Step 3: Add the Pangea React Auth components to the new React app

Now we edit our index.js file with the <AuthProvider> component that maintains authentication context and state across the application.

So our index.js file should look like this:

import React from 'react';
import ReactDOM from 'react-dom/client';
import './index.css';
import App from './App';

// Import Pangea AuthProvider component
import {AuthProvider} from '@pangeacyber/react-auth';

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(
  <React.StrictMode>
    {/* We wrap the App component with our AuthProvider */}
    <AuthProvider
      config={{
        domain: process.env.REACT_APP_PANGEA_DOMAIN,
        clientToken: process.env.REACT_APP_CLIENT_TOKEN,
        useJwt: false
      }}
      cookieOptions={{
        useCookie: true,
        cookieName: "pangea-authn"
      }}
      loginUrl={process.env.REACT_APP_LOGIN_URL}
      useStrictStateCheck={false}
    >
      <App />
    </AuthProvider>
  </React.StrictMode>
);

Now that we have the AuthProvider keeping context across the application, we can now implement the login and logout functionality by simply calling the useAuth hook in our App.js file.

Thus your App.js file should look like this:

import './App.css';

// Pangea AuthN imports
import { useAuth } from "@pangeacyber/react-auth";

function App() {
  const { authenticated, user, login, logout } = useAuth();

  return (
      <div className="App">
        <header className="App-header">
          <h1 >Login with Passkeys 🔑</h1>
          <p>
     {/* Check if user is authenticated */}
            { authenticated ?
              <p>
                Welcome, {user.email}!
                <br />
                <button style={{ 
                  background: 'linear-gradient(to right, #ff416c, #ff4b2b)',
                  border: 'none',
                  color: 'white',
                  padding: '10px 20px',
                  borderRadius: '5px',
                  cursor: 'pointer',
                  fontSize: '16px',
                  fontWeight: 'bold',
                  boxShadow: '0px 2px 5px rgba(0, 0, 0, 0.2)',
                }} 
                onClick={logout}>Logout</button>
              </p>
              :
            <button style={{ 
              background: 'linear-gradient(to right, #416cff, #4b2bff)',
              border: 'none',
              color: 'white',
              padding: '10px 20px',
              borderRadius: '5px',
              cursor: 'pointer',
              fontSize: '16px',
              fontWeight: 'bold',
              boxShadow: '0px 2px 5px rgba(0, 0, 0, 0.2)',
            }}
            onClick={login}>Login</button>
          }
          </p>
          <a
            className="App-link"
            href="https://pangea.cloud/services/authn/?utm_source=blog&utm_medium=passkeys-snippet"
            target="_blank"
            rel="noopener noreferrer"
          >
            Try Pangea AuthN for free today!
          </a>
        </header>
      </div>
  );
}

export default App;

Step 4: Enable Passkeys Authentication in Pangea console

Since we’re using a React SPA (single page application), we need to add an authorized redirect, so that Pangea’s AuthN hosted pages can successfully redirect us back to the http://localhost:3000/ when a user is done authenticating.

So first, let’s go under General > Redirect (Callback) Settings and add http://localhost:3000/ as a redirect and save it.

Here’s a quick video on how you can enable it in settings:

Let's test it out!

Integrate an Audit Trail for NextAuth.js in a few lines of code

Pranav Shikarpur — Wed, 13 Mar 2024 13:56:30 +0000

In the world where hackers are trying to brute force user accounts (23andMe breach 2023) and session tokens are being stolen (OKTA breach 2023) to impersonate authenticated users and run critical user actions, it is highly important for developers to maintain a tamper-proof audit log of all authentication events to keep their apps secure.

An audit log is a log service that’s used to keep track of all critical and sensitive user actions that take place across your applications. Events being logged could include sensitive file access, user logins, deleting or updating database records, etc.

What are the Advantages of an Tamperproof Audit Log?

Identify Risk of Exposure
A robust tamperproof audit log can help quickly assess the risk of exposure after a data breach since you have logs of all user events and critical user actions that occurred in our app.
Can’t be Tampered with
Since message hashes of Pangea Audit Logs have been designed to be stored in a cryptographically secure hash-tree called “Merkle Trees”, the logs are tamperproof and cryptographically verifiable. Thus Pangea Audit Logs can neither be changed nor destroyed once created.
Asynchronous Logging
Since Pangea Audit Logs can be implemented asynchronously with our authentication system and APIs, it doesn’t affect the performance of our web apps.

Adding the Audit Trail to Our NextAuth.js App

In this tutorial, I will demonstrate how easy it is to add a tamper-proof audit log to an authentication setup. For the purposes of this tutorial, I’m going to use NextAuth.js - a popular JavaScript authentication library - to demonstrate how we can add secure audit logging to our JavaScript apps in just a few lines of code.

To follow along, head over to next-auth.js.org and follow the “Getting Started” tutorial. Once we’ve setup our Next.js app with NextAuth, we’re going to update the [...next-auth].ts file to include an events code block that will send data to the Pangea Audit Log API asynchronously on every signIn and signOut event.



import NextAuth from "next-auth"
import { User } from "next-auth"

// Imports to add
import { JWT } from "next-auth/jwt";
import auditLogToPangea from "@/utils/auditLog";

export const authOptions = {
 // Configure one or more authentication providers
 providers: [
   // List all your providers here
// ...
 ],

 // events code block to add
 events: {
   async signIn({ user, isNewUser }: { user: User, isNewUser?: boolean | undefined }) {
       const auditLogData = {
           email: user.email as string,
           name: user.name as string,
           message: isNewUser ? "User signed up" : "User logged in",
           event: isNewUser ? "signup" : "login",
       }

    // Call pangea secure audit log on sign in
       await auditLogToPangea(auditLogData);
   },
    async signOut({token}: {token: JWT}) {
        const auditLogData = {
            email: token.email as string,
            name: token.name as string,
            message: "User logged out",
            event: "logout",
            }

        // Call pangea secure audit log on sign out
        await auditLogToPangea(auditLogData);
       }
   }
// end events code block
}

export default NextAuth(authOptions)

Now that we’ve added code to make an audit log happen on every signIn and signOut event, let’s create the auditLogToPangea function in the src/utils folder that uses the pangea-node-sdk to send log data to the Pangea secure audit log API.

Create the file auditLog.ts



import { PangeaConfig, AuditService, PangeaErrors } from "pangea-node-sdk";

const auditLogToPangea = async (logData: any) => {
   const token = process.env.PANGEA_TOKEN as string;
   const config = new PangeaConfig({ domain: process.env.PANGEA_DOMAIN });
   const audit = new AuditService(token, config);

   const data = {
       "message": logData.message,
       "action": logData.event,
       "email": logData.email,
       "name": logData.name,
       "target": logData.target ? logData.target : "",
   }

   try {
       console.log("Logging: %s", data);
       const logResponse = await audit.log(data as any, { verbose: true });
       console.log("Response: %s", logResponse.result);

       return true;
     } catch (err) {
       if (err instanceof PangeaErrors.APIError) {
         console.log(err.summary, err.pangeaResponse);
         return false;
       } else {
         throw err;
       }
   }
}
export default auditLogToPangea;

You’re all set 🎉, now every time any user logs into our Next.js app using next-auth authentication setup, the user information along with the event is automatically audit logged and if we go to View Logs section in the Pangea User Console, we should see something like the following:

Further Steps:

Now that we’ve seen how easy it is to add an audit log to our authentication setup, we can go ahead and add audit logging to all the APIs used to perform critical user actions such as fetching PII, updating sensitive user fields, billing transactions, etc. We could either add this directly for each API in the app or run it as middleware to be able to log all user information going in and out of the applications APIs.

Light Sabers Unleashed: The Lazy Developer's Guide to Outsmarting Botnets

Pranav Shikarpur — Tue, 29 Aug 2023 14:24:47 +0000

Cover Image Credit: cc 2.0 www.flickr.com/photos/dwmoran/21548629573/

In a galaxy far, far away starships sail through the vast expanse of the universe and struggle against dark forces. In that galaxy, the noble bot C-3PO brings order and harmony, while in ours not all bots act with such benevolence. Here, we struggle against different types of dark forces, often perpetuated by malicious bots themselves. With the power of Pangea’s APIs and just a few lines of code, you can safeguard your app from the dark side just like a Jedi!

Pangea recently partnered with Team Cymru (a company with a state-of-the-art botnet detection dataset) to provide developers access to IP reputation data through Pangea’s APIs. Through the Pangea IP Intel API, developers can wield Jedi-like powers to regulate access for critical user actions on an app, such as registrations, logins, and payments, effectively thwarting malicious bots from executing these operations.

Why not use a WAF or other DDOS protection?

Well, while DDOS attacks are one type of damage that bots can cause, botnets can't only be stopped by WAFs due to the nature of the different potential attack vectors. Attacks such as Astroturfing allows botnets to post harmful content, spam various APIs, and degrade important functions in your app. These attacks can be hard to prevent without advanced knowledge gained through botnet IP datasets such as the one offered by Pangea in partnership with Team Cymru.

So, let’s see how it works:

Step 1: Write a util file that makes the API call to Pangea’s IP reputation endpoint.

import { PangeaConfig, IPIntelService, PangeaErrors } from "pangea-node-sdk";

// API credential stuff
const domain = process.env.PANGEA_DOMAIN;
const token = process.env.PANGEA_INTEL_TOKEN;
const config = new PangeaConfig({ domain: domain });
const ipIntel = new IPIntelService(String(token), config);

const botDetector = async (ipAddress: string) => {

    // Selecting Cymru provider to detect malicious bots and botnets
    const options = { provider: "cymru", verbose: true, raw: true };

    const response = await ipIntel.reputation(ipAddress, options);

    if (response.result.data.verdict == "malicious" || response.result.data.verdict == "suspicious") {
        return {isBotDetected: true, resultData: response.result.data}
    } else {
        // No bot detected
        return {isBotDetected: false, resultData: response.result.data}
    }
}

All this util file does is make a call to Pangea’s API with a given IP address and return whether it found the IP to be a malicious or suspicious bot.

Now this can be used like middleware in each of the app's critical API routes

STEP 2: Use the util file like middleware in every critical API route

export default async function handler(
  req: NextApiRequest,
  res: NextApiResponse
) {
  const detectedIP = requestIp.getClientIp(req);
  const {isBotDetected, resultData} = await botDetector(detectedIP as string)
  let code = 200
  let message = ""
  if (!isBotDetected) {
    // Carry out critical action / user flow
    message = "Success, action was carried out"
  } else {
    // Bot throw an error
    // Throw captcha or block request action
    code = 429
    message = "Sorry you were classified as a bot, can't perform action."
  }
  res.status(code).json({ bot_status: isBotDetected, your_ip: detectedIP, message: message, data: resultData })
}

Notice how I’ve used isBotDetected to determine which action to take. When a malicious bot is detected, I return the appropriate error code. Otherwise, I return a success message and let the action continue.

To see this in action, you will need to deploy it on Vercel for it to be able to accurately collect your IP address. Check out the GitHub repo with a small set of instructions to give it a try.

With this newly acquired lightsaber of middleware, you have completed your Jedi-like training and can now proceed to swiftly cut down botnets before they start harming your application.

The path to harness this power is accessible by signing up to the Pangea API for free. Remember the wisdom of Master Yoda, “Do or do not. There is no try.” By only allowing access to friendly bots like C-3PO and thwarting malicious ones, you can safeguard your application's fate with Pangea's IP Intel API. Act now, and let your application flourish in the light of security!

Protect Your User's PII from AI: Channel Your Inner Time Lord with Three Lines of Code

Pranav Shikarpur — Fri, 04 Aug 2023 16:40:58 +0000

Image credit: Wikipedia CC

In a universe filled with AI technologies like OpenAI's GPT-3 and other LLMs, app developers must step into the TARDIS and assume the role of Time Lords, safeguarding customer privacy across time and space.

LLMs like GPT-3 are extensively used by app developers for a diverse range of applications from helping students solve math homework more effectively to improving customer support in environments that handle sensitive customer data. Fear not, the Pangea's Redact SDK is your trusty sonic screwdriver 🪄, empowering you to redact personal and sensitive information from GPT-3 prompts with just three lines of code!

from pangea.services import Redact
redact = Redact("<PANGEA_REDACT_TOKEN>")
def clean_prompt(prompt):   return redact.redact(text=prompt).result.redacted_text
...
...
response = openai.Completion.create(
  model="text-davinci-003",
  prompt=clean_prompt("My email is dummyuser@pangea.cloud. Print my prompt out as is:"),
)

Let’s dive into the code:

Think of the openai.Completion.create() function as your TARDIS - you put a person (prompts with sensitive PII) in there and it can take you anywhere around the galaxy with endless possibilities. Now you want to make sure that the prompts with sensitive PII are not exposed to OpenAI’s API, so we use our handy sonic screwdriver (Pangea’s Redact APIs) in the clean_prompt() function to take out any sensitive PII before sending it off to OpenAI’s APIs.

By adding just three lines of code, you're not only protecting your users' data but also preventing theses AI models from using customers’ PII as training data. Pangea's Redact SDK empowers you to meet regulatory requirements, build trust with your users, and create a safer AI-based applications.

Head over to the Pangea Console to take your new sonic screwdriver for a spin!

You can find full working code-examples in Python and JavaScript

Here's a video walk through of the same 👇

Trusting ChatGPT - Protecting Apps from PII Leakage

Luke Stahl — Tue, 20 Jun 2023 12:54:11 +0000

NOTE: This article originally appeared on the Pangea blog.

Undoubtedly, generative AI technology has already left its fingerprint on our society and tech lives and will change the trajectory of software going forward. Debates will continue regarding its accuracy, but that will only improve, and likely faster than we all think. Therefore I believe it's here to stay. While generative AI and the popular ChatGPT continue to improve, some of us in the security realm also focus on the trustworthiness and security of using ChatGPT. CISOs and many security-minded developers are also exploring this topic. Users, particularly users of enterprise apps, will want to use this (ChatGPT), but how do we secure it? What are the risks? What does securing it even mean? We can be proactive about this and apply some of the principles we already know in security to develop a framework and systematic approach to securing the use of ChatGPT.

A hot topic and starting point for working on this problem is addressing the potential for PII leakage to ChatGPT or OpenAI. It's too easy for any application user to submit PII as an input to any app, and there's added risk to submitting PII to something like ChatGPT. People make mistakes, ranging from entering a driver's license number to their own IP address or, in the worst case, their social security number (SSN). The problem with this in the context of ChatGPT is that users of ChatGPT need to be made aware of the usage policy or how ChatGPT will handle your data. Apply that problem statement to an enterprise that may also be handling their customer's data, and you have just multiplied the significance of the problem and brought in legal concerns around usage policy violations and GDPR violations. The truth of the matter is that we just "don't know what we don't know" when it comes to the life of that data after the user submits it as an input to ChatGPT or OpenAI - we don't know yet where it (data, particularly PII data) goes or which policies that may violate.

The threat becomes even more apparent when interacting with applications that use frameworks such as LLAMA index which facilitate interactions between public LLMs and private data stores to perform a sort of pseudo training for chat apps. If you create an app that takes conversational data to further expand an index, you’re even more open to the threat of malicious injection. The effect is compounded when allowing these models to provide instructions to internal applications such as Github copilot which can directly interact with the OS.

The problem is twofold in that both training time & runtime data must be monitored.

So what can we do? Our recommended approach for addressing the PII concern is to wrap all input/output activity with ChatGPT in Pangea's Redact API. This will ensure that all inputs submitted to ChatGPT will be devoid of sensitive PII. This is configured via rulesets in the Pangea Redact service. Pangea Redact can filter out the following types of information:

PII such as email address, nationality, religious group, location, and name
US identification numbers such as US driver's license number, US ITIN, US passport, and SSN
Medical identification numbers such as medical license number, UK national health service number, and Australian Medicare number
Several types of other international identification numbers
Secrets such as slack tokens, RSA private keys, SSH private keys, PGP private key blocks, AWS access keys, and several different key types
Custom rulesets defined by the developer

To view all the different types of rules, you can review the configuration of the redact service and the documentation.

To help developers with this, we have a Next.js sample app on GitHub that shows exactly how ChatGPT and Pangea's Redact service can be integrated. The high-level concept is easy to understand:

The user submits an input to ChatGPT via the sample app
The raw input is routed through Pangea's Redact service via API
The Pangea Redact service returns a clean version of the input devoid of the types of sensitive information enabled in the service
The sample app submits the clean version of the input text to ChatGPT

At this point, you can trust that the inputs are clean and the user is not leaking sensitive data. But there's more!

The response from ChatGPT is returned to the sample app and parsed to discover embedded links and domains
Domains within the links are submitted to Pangea's Domain Intel service, which identifies malicious domains through a reputation database
Any domains classified as malicious are redacted from the response so that the end user can never click on any malicious domains
To conclude, the response is returned to the user within the sample app

Other services this sample app takes advantage of from Pangea includes Authentication and Secure Audit Log, which are staples to any secure application and must be considered by every developer for good security hygiene in your app.

This is not resolving every security topic associated with ChatGPT and generative AI, but it is a start. And it contributes to the discussion inside the developer and security communities around possible approaches to securing how we interact with this generative AI.

In closing, let's all continue experimenting with ChatGPT and stay tuned for more samples from Pangea on securing the interaction with generative AI tech. Check out this sample app and let us know your thoughts in our Pangea-builders Slack community. To get started you can signup for Pangea here.

Integrating with Firebase and Pangea's security services

Luke Stahl — Tue, 14 Feb 2023 17:35:40 +0000

NOTE: This article originally appeared on the Pangea.

Firebase, similar to the Pangea platform, helps you develop high-quality apps, grow your user base, and focus on providing your users with your unique value proposition. Each feature works independently, and they work even better together. If you are unfamiliar with Firebase and would like to learn more, visit the Firebase site.

In this tutorial, learn how to install and utilize a combination of Pangea provided Firebase Extensions. Firebase Extensions are an easy way to add Pangea services to your Firebase app without the need to write or debug code on your own. Extensions are pre-packaged solutions designed to save development time and quickly deploy Pangea functionality into your applications hosted on Firebase. You provide the configuration parameters, such as authentication tokens, for each extension at install time. All Pangea-provided extensions are open-sourced and built on Firebase and Google Cloud products you already know. Deployment and configuration of each extension are performed in the Firebase console or the Firebase CLI, and once deployed, they require no maintenance.

Each section of this tutorial will focus on a specific Pangea service and demonstrate how to install and utilize the associated Firebase Extension. After completing the first section, Configure a Starter Project, you can follow the tutorial sequentially to implement the complete use case or skip to each section relevant to you. As the Pangea platform's capabilities increase with the addition of new services, this tutorial will also evolve to highlight the new functionality. You can refer to this multi-part series at any time to learn about new Pangea services and how they may help secure an application hosted on Firebase.

Configure a Starter Application

Overview

In this section, you will familiarize yourself with Firebase and the services it offers, such as the NoSQL document database, Cloud Firestore, that lets you easily store, sync, and query data. You will also configure Cloud Storage which is designed to help you quickly and easily store and serve user-generated content, such as photos and videos. In the subsequent sections, you will utilize Pangea-provided Firebase Extensions to secure your app. For a complete list of the Firebase services available to app builders, visit the Firebase Products page.

Firebase services are designed to reduce development time by streamlining commonly performed tasks when developing applications; similarly, Pangea can be thought of as a stack-agnostic security framework. Regardless of what technologies you use to build your apps, Pangea is designed to alleviate your team from the burden of compliance.

Note
If you already have a Firebase project you'd like to secure with Pangea, you can skip this section and install the extensions covered in the subsequent sections to your existing project.

Prerequisites

A free Firebase account
Node.js (version 14.16.1 or higher) and npm installed on your machine.

Create the sample project

Step 1: From the Firebase Console, select Create a project:

Step 2: Select a project name and follow the setup wizard:

Take a moment to explore the console and services available. It contains four service categories, Build, Release & Monitor, Analytics, and Engage.

Configure a Firestore Database

Next, to create a Cloud Firestore database to store and sync data between your client-side and server-side apps, perform the following steps:

Step 1: From the Project Overview left-hand menu, expand the Build section, and select Firestore Database.

Step 2: Click the Create database button.

Follow the configuration wizard to select an initial security mode and region to deploy the database.

Note
Pangea recommends selecting the Start in production mode, even for a test project.

Step 3: You should now have a fully configured database that you can add collections and documents to. You will learn how to install extensions to listen and react to document changes in later sections of this tutorial.

Configure Cloud Storage

Next, to create a Cloud Storage container to store files such as images and videos, perform the following steps:

Step 1: From the Project Overview left-hand menu, expand the Build section, select Storage, and click the Get started button.

Step 2: Follow the configuration wizard to select an initial security mode and region to deploy the Storage service.

Note
Pangea recommends selecting the Start in production mode, even for a test project.

Step 3: You should now have a fully configured Storage container that you can upload files to. You will learn how to install extensions to listen and react to upload events in the next section of this tutorial.

Configure Authentication

To enabled authentication and allow users to create accounts to access your application services, perform the following steps:

Step 1: From the Project Overview left-hand menu, expand the Build section, select Authentication, and click the Get started button.

Step 2: From the Sign-in providers section, under the Native providers column, select Email/Password.

Step 3: Enable the Email/Password provider and click Save button.

Configure Cloud Functions, billing profile, and your local environment.

To enable Cloud Functions to host and run serverless code, you'll need to upgrade your Firebase account to a Blaze tier Pay as you go plan. To do so, perform the following steps:

Step 1: From the Project Overview left-hand menu, expand the Build section, select Functions, and click the Upgrade Project button.

Step 2: To upgrade, click the Continue button and follow the instructions. You will be redirected to the Set up your billing profile section of Google Cloud Platform (GCP) and asked to complete a billing profile.

Note
You will only be charged if to you exceed the usage allotted by the free tier. Visit the Firebase Pricing page for details.

Step 3: After setting up your GCP billing profile, you will be redirected back to the Firebase Console. From the left-hand menu, expand the Build section, select Functions, and click the Get started button.

Step 4: Follow the instructions in the Set up Functions wizard. First, to install the Firebase tools run the following command:

npm install -g firebase-tools

To link your firebase account to the command-line tools installed, run:

firebase login

Follow the instructions presented by the login command, then when presented with the Sign in screen in a browser window, use your Google Account to log in and grant the Firebase CLI access to the permissions it needs.

Note
If the browser window is not automatically presented, copy and paste the URL provided by the firebase login command into a new browser window or tab.

Then, to initialize your Firebase project for local development, create a folder for your project, set the current directory to the folder created, and run the following command:

firebase init

You will be guided through the configuration process with a series of questions.

Note
You will be prompted to select which Firebase services you'd like to configure. These will vary depending on your desired use case but for the purpose of this tutorial, make sure to at least select Firestore, Functions, and Storage.

Here is an example output:

local-machine:~/Development/YourFirstFirebaseProject Firebase init

     ######## #### ########  ######## ########     ###     ######  ########
     ##        ##  ##     ## ##       ##     ##  ##   ##  ##       ##
     ######    ##  ########  ######   ########  #########  ######  ######
     ##        ##  ##    ##  ##       ##     ## ##     ##       ## ##
     ##       #### ##     ## ######## ########  ##     ##  ######  ########

You're about to initialize a Firebase project in this directory:

  /Users/Development/YourFirstFirebaseProject

? Which Firebase features do you want to set up for this directory? Press Space to select features, then Enter to c
onfirm your choices. Firestore: Configure security rules and indexes files for Firestore, Functions: Configure a Cl
oud Functions directory and its files, Storage: Configure a security rules file for Cloud Storage, Emulators: Set u
p local emulators for Firebase products

=== Project Setup

First, let's associate this project directory with a Firebase project.
You can create multiple project aliases by running firebase use --add,
but for now we'll just set up a default project.

? Please select an option: Use an existing project
? Select a default Firebase project for this directory: yourfirstfirebaseproject (YourFirstFirebaseProject)
i  Using project yourfirstfirebaseproject (YourFirstFirebaseProject)

=== Firestore Setup

Firestore Security Rules allow you to define how and when to allow
requests. You can keep these rules in your project directory
and publish them with firebase deploy.

? What file should be used for Firestore Rules? firestore.rules

Firestore indexes allow you to perform complex queries while
maintaining performance that scales with the size of the result
set. You can keep index definitions in your project directory
and publish them with firebase deploy.

? What file should be used for Firestore indexes? firestore.indexes.json

=== Functions Setup
Let's create a new codebase for your functions.
A directory corresponding to the codebase will be created in your project
with sample code pre-configured.

See https://firebase.google.com/docs/functions/organize-functions for
more information on organizing your functions using codebases.

Functions can be deployed with firebase deploy.

? What language would you like to use to write Cloud Functions? TypeScript
? Do you want to use ESLint to catch probable bugs and enforce style? Yes
✔  Wrote functions/package.json
✔  Wrote functions/.eslintrc.js
✔  Wrote functions/tsconfig.json
✔  Wrote functions/tsconfig.dev.json
✔  Wrote functions/src/index.ts
✔  Wrote functions/.gitignore
? Do you want to install dependencies with npm now? Yes
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: undefined,
npm WARN EBADENGINE   required: { node: '16' },
npm WARN EBADENGINE   current: { node: 'v19.2.0', npm: '8.19.3' }
npm WARN EBADENGINE }

added 410 packages, and audited 411 packages in 52s

89 packages are looking for funding
  run `npm fund` for details

2 vulnerabilities (1 moderate, 1 high)

To address all issues (including breaking changes), run:
  npm audit fix --force

Run `npm audit` for details.

=== Storage Setup

Firebase Storage Security Rules allow you to define how and when to allow
uploads and downloads. You can keep these rules in your project directory
and publish them with firebase deploy.

? What file should be used for Storage Rules? storage.rules
✔  Wrote storage.rules

=== Emulators Setup
? Which Firebase emulators do you want to set up? Press Space to select emulators, then Enter to confirm your choic
es. Authentication Emulator, Functions Emulator, Firestore Emulator, Storage Emulator, Eventarc Emulator
? Which port do you want to use for the auth emulator? 9099
? Which port do you want to use for the functions emulator? 5001
? Which port do you want to use for the firestore emulator? 8080
? Which port do you want to use for the storage emulator? 9199
? Which port do you want to use for the eventarc emulator? 9299
? Would you like to enable the Emulator UI? Yes
? Which port do you want to use for the Emulator UI (leave empty to use any available port)?
? Would you like to download the emulators now? Yes
i  ui: downloading ui-v1.11.2.zip...

i  Writing configuration info to firebase.json...
i  Writing project information to .firebaserc...
i  Writing gitignore file to .gitignore...

✔  Firebase initialization complete!

Navigate back to the browser with the Firebase console and click the Finish button of the Set up Functions dialog. The second command, firebase deploy shown in that dialog, is not required since you do not yet have functions to deploy. However, you now have the Cloud Functions service configured and the Waiting for your first deploy message displayed, as shown below.

The Pangea Extensions you will install in the following few sections of this tutorial are actually pre-packaged Cloud Functions provided by Pangea that you can deploy and authorize to run in your Firebase environment. All the Pangea Extensions are open source and available for you to reference, modify, and improve. You can visit our Github Repository to view or download the code. To learn how to quickly leverage the power of Pangea's security services without needing to write or debug code proceed to the next section.

Install the Known Malware Detection Extension

Overview

Firebase Cloud Storage is designed to store and serve user-generated content with ease as you prototype and scale your application. But what happens when a user uploads a malicious file? The Pangea Known Malware Detection Extension can be configured to automatically check files uploaded by users against a database of 25 million known malicious files, and if deemed dangerous, it can be naturalized by packaging it into a password protected gzip container.

In this section, you will learn how to install, configure, and test the Extension and leverage the Pangea File Intel Service without writing a single line of code.

Prerequisites

A free Firebase account with the [Pay as you go (https://firebase.google.com/pricing) billing plan enabled.
A free Pangea account.
Completed part 1. Configure a Starter Application of this multi-part tutorial OR a Firebase project with the Cloud Functions and Cloud Storage services enabled.
A Pangea Domain and Access Token with access rights to the File Intel service. To learn how to create an account and configure each service, visit the Getting Started guide.

Install and configure the Extension

Step 1: Click the Known Malware Detection install link, and select the Firebase project you'd like to deploy the Extension to:

Step 2: Accept the Early Access acknowledgement by clicking the Next button:

Step 3: Review the billing and usage details, and tap the Next button. If you have not done so already, you'll be presented with the option to upgrade your Firebase account to a pay-as-you-go plan, you can do so by clicking the Upgrade project to continue button and following the instructions:

Note
If you upgrade your billing plan, you will be redirected to the Set up your billing profile section of Google Cloud Platform (GCP). After setting up your billing profile, you may need to restart the Extension install by clicking the install and repeating Step 1 and Step 2.

Step 4: Review the APIs and the resources that will be created by this Extension. If any required Firebase services are not yet enabled, tap the Enable button next to each required service and then click the Next button.

Step 5: In the Review access granted to this extension section, grant the extension permission to Storage and Secrets Manager by clicking the Next button.

Note
The Storage Admin permission will be used to store gzip formatted files that contain and neutralize malicious files uploaded to your bucket, and the Secret Manager Secret Accessor permission is required to store your Pangea Auth Token, and optional password for any gzip files created.

Step 5: In the final step, Configure extension, of the install process, you'll be asked to provide a few parameters, some of which are optional. The first two are what region you want to deploy the Extension and where your Pangea services are deployed, respectively. The Extension should be deployed as close to your Firebase Cloud Storage, so ideally, the same region you used when you configured it. The Pangea service base Domain and Auth Token can be copied from the Pangea Console > File Intel Overview page. The Pangea Auth Token and optional password to protect the gzip container should be stored in Google Secret Manager. To do so, just click the Create secret button next to each input field after entering their respective value.

The rest of the parameters are either optional or have default values to dictate which buckets you want to monitor, which paths to include or ignore, and whether to delete or keep a malicious file when it is detected.

Note
You can use the default values for now and reconfigure your Extension later.

You can also configure how much memory to allocate to your function; neutralizing large files may require more memory.

Check the Enable events box and select the completed event. This will allow your Firebase application to listen to and react when malicious files are uploaded.

Note
In this tutorial's next section, Add Secure Audit Logging, you will configure the Pangea Secure Audit Log Extension to log events emitted from this Known Malware Detection Extension.

To complete the installation, click the Install extension button.

It may take Firebase 3-5 minutes to deploy your Extension. When it completes, you should see it listed under the Extensions section of your Firebase Console.

Test the Extension

Instead of testing the Known Malware Detection Extensions with a real malicious file or virus, you can use a file developed by the European Institute for Computer Antivirus Research (EICAR) known as the EICAR Anti-Virus test file. It was developed to test the response of computer anti-virus (AV) programs. Instead of using real malware, which could cause real damage, this test file allows you to test anti-virus software without having to use a real computer virus. To do so, do the following:

Step 1: To create the EICAR antivirus test file, create a file with this string:

5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

Note
You can also download the test file directly from: eicar.com

Step 2: Using the Firebase Project Overview left-hand menu, expand the Build section, and select Storage.

Step 3: Click the Upload file button, and select the eicar-test-file.com file you downloaded in the previous step. After a few seconds, you will notice that the file was moved into a .zip file under the path you configured; we used /malicious as the default. If you also chose the default extension configuration, the complete path will be /malicious/eicar-test-file_com.zip. You can download this file, inspect its contents, or send it to an incident response team for analysis.

Note
You may need to refresh the browser to load the updated paths.

Note
You can also try to upload a non-malicious file and note that the Extension does not process it.

Add Secure Audit Log to security-critical app events

Overview

In this section, learn how to install, configure and invoke the Pangea Secure Audit Log Extension to leverage the Secure Audit Log . Once installed, the Extension will automatically log security-critical events emitted by Firebase and other Pangea Extensions. You will also learn how to log your custom app events by recording them in a Firebase Firestore Document. Using the Pangea Console Log Viewer you can cryptographically verify that records have not been modified, inserted, or deleted.

When your application utilizes Pangea's tamperproof logging service, log hashes are automatically published to an immutable public ledger or blockchain. Doing so provides irrefutable evidence of what events occurred in an application without exposing the logs' contents publicly. With the Secure Audit Log Extension, you can deliver the power of the blockchain to your users without writing a single line of code.

Prerequisites

A free Firebase account with the Pay as you go billing plan enabled.
A free Pangea account.
Completed part 1. Configure a Starter Application of this multi-part tutorial OR a Firebase project with the Cloud Functions and Cloud Firestore services enabled.
A Pangea Domain and Access Token with access rights to the File Intel service. To learn how to create an account and configure each service, visit the Getting Started guide.

Install and configure the Extension

Step 1: Click the Secure Audit Logging Extension install link, and select the Firebase project you'd like to deploy the Extension to:

Step 2: Accept the Early Access acknowledgement by clicking the Next button:

Step 3: Review the billing and usage details, and tap the Next button. If you have not done so already, you'll be presented with the option to upgrade your Firebase account to a pay-as-you-go plan, and you can do so by clicking the Upgrade project to continue button and following the instructions:

Note
If upgrading your billing plan, you will be redirected to the Set up your billing profile section of Google Cloud Platform (GCP). After setting up your billing profile, you may need to restart the Extension install by clicking the install and repeating Step 1 and Step 2.

Step 4: Review the APIs and the resources that this Extension will create. If any required Firebase services are not yet enabled, tap the Enable button next to each required service and then click the Next button.

Note
_The Extension declares several functions to create Secure Audit Log entries:

fslog - listens for changes made to a Firestore collection. You can invoke this Extension to log custom events by writing to a document in a specified collection.

onmaliciousfiledetected - will be automatically invoked by the Known Malware Detection Extension installed in the previous section of this tutorial if you enabled the completed event.

onusercreated - will be automatically invoked when a user is created.

onuserdeleted - will be automatically invoked when a user is created._

_onlogevent - listens for custom log events you can emit from your application code.
_

Step 5: In the Review access granted to this extension section, grant the extension permission to Firestore and Secrets Manager by clicking the Next button.

Note
The Cloud datastore User permission will be used to read and write the responses of the Pangea Secure Audit Log service to a Firestore document. The Secret Manager Secret Accessor permission is required to store your Pangea Auth Token.

Step 6: In the final step, Configure extension, of the install process, you'll be asked to provide a few parameters, some of which are optional. The first two and what region you want to deploy the Extension and where your Pangea services are deployed, respectively. The Extension should be deployed as close to your Firebase Cloud Firestore, so ideally, the same region you used when you configured it. The Pangea service base Domain and Auth Token can be copied from Secure Audit Log Overview page of the Pangea Console. The Pangea Auth Token should be stored in Google Secret Manager. To do so, click the Create secret button next to its input field after entering the token value.

The Collection path and Input field name are the Firestore paths you want to write custom events to, and the Response output field name is the path to which the response of each request will be written to by the Extension.

Note
You can use the default values for now and reconfigure your Extension later.

To complete the installation, click the Install extension button.

It may take Firebase 3-5 minutes to deploy your Extension. When it completes, you should see it listed under the Extensions section of your Firebase Console.

That's it! You now have Secure Audit Logging enabled in your Firebase app. Events emitted from other Pangea Extensions will automatically be recorded.

Test automatic logging of events from other Pangea Extensions

To test events automatically logged by the Known Malware Detection Extension, upload another malicious file to Cloud Storage. To do so, refer to the Test the Extension portion of the previous section, 2. Detect malicious Files uploaded to Cloud Storage of this tutorial and perform Step 1, Step 2, and Step 3.

Note
If you have not done so already, make sure to delete the test file from your previous test.

Then, to view the event, navigate to the Pangea Console Log Viewer of the Pangea Console. You should see the event similar to:

Test automatic logging of Firebase Authentication events

This Secure Audit Logging Extension listens for and automatically logs when a new Firebase user is created or deleted. To test and view these events, perform the following steps:

Step 1: From Firebase Console, expand the Build category, select Authentication from the left-hand menu, and click the Add user button.

Step 2: Enter a Email and Password for your test user and click the Add user button in the Add an Email/Password user dialog box.

Note
You do not need to use a valid email address. You will delete this user account in the next step.

Step 3: Expand the user options using the three-dot options menu button on the right-hand side of the user row you created in the previous step. Click the Delete account option, and when the Delete account dialog box is presented, confirm the delete by clicking the Delete button.

Step 4: Then, to view the User created and User deleted events, navigate back to the Pangea Console Log Viewer of the Pangea Console. You should see the event similar to:

Test logging custom events by writing to Firestore

When you installed the Secure Audit Logging Extension, you configured it to listen to changes to a specific Document in your application's Firestore database. To record your custom application events, such as user login attempts, registrations, or object access attempts, you can invoke the Pangea Secure Audit Log service by simply writing to the Document. In this section, you will test this functionality using the Firebase Console user interface. To do so, perform the following steps:

Step 1: From Firebase Console, expand the Build category and select Firestore Database from the left-hand menu.

Step 2: Select the Start collection option from the Panel View, and because you used the default collection name when installing the Secure Audit Logging Extension, enter 'audit' as the Collection ID and click the Next button.

Note
The collection names are case-sensitive. Use all lowercase letters in the Collection ID field.

Step 3: To add the Document to the Collection, click the Auto-ID button to generate an ID for the Document; then again, because you used the default configuration parameters when you installed the Extension, enter 'log' as the Field value and set the Type to map.

A document with an auto-generated Document ID and single Field of type map should look similar to this:

Step 4: You can now map each of the Pangea Secure Audit Log API parameters to a Field of the 'log' map. Add the following Field : Value pairs, each of Type string:

message : Hello, World!
action  : test
status  : complete
source  : firestore
target  : audit-log-ext
actor   : firebase-console

Then, to create the Document and trigger Secure Audit Log Service, click the Save button.

In a few moments, you should see a response field containing the Pangea service response added to the Document as a pier to the log field you created.

Then, to view the event, navigate back to the Pangea Console Log Viewer of the Pangea Console. You can expand the log entry by clicking on it to reveal the custom metadata fields. You should see an entry similar to the one below:

The Secure Audit Logging Extension will be invoked by any write operation to the Document it is configured to observe. The Cloud Firestore Panel view is a great way to test the Extension by quickly creating and editing Firestore documents, but you may want to record auditable events from your application code. With the Secure Audit Logging Extension installed, you can do so from anywhere in your application that can write to Firestore.

Here is a quick example of how to create the same Document programmatically:

import {getFirestore} from "firebase-admin/firestore";

getFirestore().collection("audit").add({
  log: {
    message: "Hello, World!",
    action: "test",
    status: "complete",
    source: "firestore",
    target: "audit-log-ext",
    actor: "firebase-console",
  },
});

You can also send custom events to the extension using EventArc. Here is an example:

import {getEventarc} from "firebase-admin/eventarc";

getEventarc().channel().publish({
  type: "firebase.extensions.pangea-audit-log.v1.log",
  data: {
    message: "Hello, World!",
    action: "test",
    status: "complete",
    source: "target",
    target: "audit-log-ext",
    actor: "firebase-console",
  },
});

Integrating Pangea Audit and Embargo APIs with RedwoodJS

Luke Stahl — Mon, 24 Oct 2022 12:35:21 +0000

NOTE: This article originally appeared on the Pangea.

Quickview

Learn how to integrate Pangea's Secure Audit Log and Embargo services into RedwoodJS' native login flow. In this tutorial, you'll ensure compliance with frameworks like HIPAA, SOX, and others by logging critical authentication activities - logins, password changes, and account creation. Further, you'll learn how to use the Embargo service to block account creation and access to a user attempting to log in from an embargoed country.

Requirements

This walkthrough uses the RedwoodJS sample app, built in the RedwoodJS tutorial, as a starting point for integrating Pangea. It assumes that you have been through steps 1 through 4 of the excellent RedwoodJS tutorial. If you prefer to skip the RedwoodJS tutorial, the RedwoodJS example app can be found here.

This tutorial is intended to be a step-by-step walkthrough, adding Pangea integration to the sample app. If you'd prefer to review a completed version of this integration, use this branch of the above repo.

Additionally, this tutorial assumes a basic understanding of how to enable, configure, and use Pangea services. To learn more about that, check out our getting started guide.

Note: This example will be in TypeScript (because I'm a rational human being). If you would prefer pure Javascript, some translation will be required.

Prerequisites

A Pangea Account - sign up here
An enabled Pangea Audit Service
An enabled Pangea Embargo Service with the ITAR list enabled
RedwoodJS (latest version)
A RedwoodJS example App completed through step 4, section "Authentication," using dbAuth

Part 1 - Creating the Pangea Module

Now that you have a RedwoodJS blogging app, complete with Authentication, up and running, you must feel pretty awesome! Before we can start logging into Pangea Secure Audit Log, we need to create a Pangea module that can be imported throughout the rest of the RedwoodJS code.

Step 1: Install the Pangea SDK:

The first thing we need to do is install the Pangea Node.js SDK. You'll want to open your Terminal app and ensure you're in your Redwood Sample app root directory. Then run,

yarn workspace api add node-pangea

This will install the Pangea Javascript SDK in the API workspace of your Redwood project.

Step 2: Create Pangea environment variables

At the root of your RedwoodJS App, there will be a .env file. Here you'll need to append the following variables to the end of the file:

PANGEA_AUDIT_TOKEN=<audit_token>
PANGEA_AUDIT_CONFIG_ID=<audit_config_id>
PANGEA_EMBARGO_TOKEN=<embargo_token>
PANGEA_EMBARGO_CONFIG_ID=<embargo_config_id>
PANGEA_DOMAIN=<pangea_domain>

Note: You'll need to replace the values in angle brackets with real values from your Pangea project.

You can find these variables in the Pangea Console on the overview section of their respective service. You can find the Pangea Domain (the same for both services), and Config ID in the top-right of the <service> overview dashboard. You can copy the token from the token listing at the bottom of the <service> overview dashboard.

The variables ending in TOKEN are the API Keys granting access to the respective Pangea APIs. The variables ending in CONFIG_ID point to a specific instance of the Pangea service - the instance that you've enabled as part of the prerequisites for this tutorial. Finally, the PANGEA_DOMAIN will tell the SDK where to go to hit your Pangea service APIs (domain will change depending on CSP, Geo, and location selected).

Step 3: Create the Pangea Module

To create a Pangea module, you need to create a pangea.ts file in the /\<project_root\>/api/src/lib directory. We'll need to do a few things in this module to prepare it for inclusion in our other projects. First, we'll want to import AuditService, EmbargoService, and PangeaConfig from node-pangea.

Add the following to the first line in your new /<project_root>/api/src/lib/pangea.ts file.

import { AuditService, EmbargoService, PangeaConfig } from "node-pangea";

Next, you'll want to load the configuration values added in Step 2 from your .env file. You can add the following to your pangea.ts file.

const DOMAIN = process.env.PANGEA_DOMAIN;
const auditToken = process.env.PANGEA_AUDIT_TOKEN;
const auditConfigId = process.env.PANGEA_AUDIT_CONFIG_ID;
const embargoToken = process.env.PANGEA_EMBARGO_TOKEN;
const embargoConfigId = process.env.PANGEA_EMBARGO_CONFIG_ID;

With the configuration values loaded, you'll now be able to create PangeaConfig instances for both the Embargo and Audit Services.

const auditConfig = new PangeaConfig({
  configId: auditConfigId,
  domain: DOMAIN,
});

const embargoConfig = new PangeaConfig({
  configId: embargoConfigId,
  domain: DOMAIN,
});

With the PangeaConfig instances created, you need to create instances of the AuditService and EmbargoService, which will be what you use to call the Pangea APIs. To do this, you add:

const audit = new AuditService(auditToken, auditConfig);
const embargo = new EmbargoService(embargoToken, embargoConfig);

Lastly, you'll need to create a named export for when this pangea module is imported into other parts of your code. Do this by adding the following:

export { audit, embargo };

At this point, your Pangea.ts code should look like as such:

/<project_root>/api/src/lib/pangea.ts

import { AuditService, EmbargoService, PangeaConfig } from "node-pangea";

const DOMAIN = process.env.PANGEA_DOMAIN;
const auditToken = process.env.PANGEA_AUDIT_TOKEN;
const auditConfigId = process.env.PANGEA_AUDIT_CONFIG_ID;
const embargoToken = process.env.PANGEA_EMBARGO_TOKEN;
const embargoConfigId = process.env.PANGEA_EMBARGO_CONFIG_ID;

const auditConfig = new PangeaConfig({
  configId: auditConfigId,
  domain: DOMAIN,
});

const embargoConfig = new PangeaConfig({
  configId: embargoConfigId,
  domain: DOMAIN,
});

const audit = new AuditService(auditToken, auditConfig);
const embargo = new EmbargoService(embargoToken, embargoConfig);

export { audit, embargo };

Congratulations! You've created a Pangea module which will be the foundation for the rest of this tutorial. Not only that, you can use this module in any TypeScript project that you might be building. Even cooler - as Pangea creates new services, you can extend this file to include other services you might need in your project. Give yourself a giant pat on the back. Now comes the fun part!

Part 2 - Adding Secure Audit Log to the example app authN flow

You put in the work! You've got a brand-spankin' new pangea.ts module; let's put it to work. In this Part, you'll add audit logging to the login, password change, and account creation processes. As mentioned, logging security operations like logins, password changes, and account creation can be critical for compliance frameworks like HIPAA, SOX, and SOC2. However, even if those frameworks are not applicable, logging these events can still be crucial in reconstructing and security breach or incident that may need further investigation.

Step 1: Import the pangea module

First things first, find the /\<project_root\>/api/src/functions/auth.ts file. To add logging to the login process, you'll need to import your handy-dandy new pangea module. I recommend importing audit and embargo, as you'll be using embargo in Part 3. Add the following import to /\<project_root\>/api/src/functions/auth.ts.

import { audit, embargo } from "src/lib/pangea";

Note that api is not necessary in the import path. That's because RedwoodJS has already divided your project into workspaces, with api being one of them.

Step 2: Adding a simple audit message to the login flow

I know the first place I thought of adding audit logging was to user login, and I'm going to guess that's what you thought too. Let's start with a simple message that says \<user\> successfully logged in. To do this, you'll need to find the handler in loginOptions in the /\<project_root\>/api/src/functions/auth.ts file. The handler() is called after someone provides a username and password before logging them into the App. This will be important in Part 3 when you add embargo checking to the App.

To add the log message, you try adding the following to your code:

handler: (user) => {
    audit.log({
        message: `${user.email} successfully logged in.`,
    })
    return user
},

Start your RedwoodJS App using the following command in your terminal from your project_root

yarn rw dev

Assuming you're still using the SQLite version of the App (which, if you followed the prerequisites, you should be), you'll want to create an account and then try logging in. If everything worked as it should, you should have a new log message in your Pangea Secure Audit Log. To check this, go to Pangea Admin Console->Secure Audit Log->View Logs. You should see your message there. If not, check the terminal you used to start your App and look for errors.

Step 3: Adding more audit fields

If you read our blog post Audit Log Field Guide - Time Travel and Humblebrags, you'll know that logging more than just a message can be important for the usability of your logs. What you'll want to do now is break up your message into several components:

Actor - The user logging in
Action - "login"
Status - "success" for successful logins, "failed" for failed logins.
Source - the client IP address for the request
Message - That's already done.

Breaking the logged audit message up individually ensures that the log record is very search-friendly while also ensuring a human-readable message in the "message" field.

Before you can do anything to update your audit.log call, you'll want to add some code to be able to retrieve the client-ip address. It should be noted that this code is generic. If you implement your sample app in a proxied environment, you may need additional steps to identify the client-ip.

To retrieve the client IP add the following function to you /\<project_root\>/api/src/functions/auth.tsfile, just below the line starting with export const handler = async (event, context) => {

export const handler = async (event, context) => {
  const ipAddress = ({ event }) => {
    return (
      event?.headers?.['client-ip'] ||
      event?.requestContext?.identity?.sourceIp ||
      'localhost'
    )
  }

This code will attempt to retrieve the client IP from the header or request context. If it can't find it, it will return localhost.

Now that you can get the client IP let's update the audit.log call. To do this, add the following to the call you wrote in Step 1.

const clientIp = ipAddress(event);
audit.log({
  actor: user.email,
  action: "Login",
  status: "Success",
  source: `${clientIp}`,
  message: `${user.email} successfully logged in.`,
});

If your project is still running, you should be able to log out and log back in. If not, restart your project by running the following command in your terminal from project_root

yarn rw dev

Now login once, more and check the audit log viewer in Pangea Admin Console->Secure Audit Log->View Logs. You should see a newly logged message with the additional fields you just added. Awesome work!

Step 4: Adding Secure Audit Log to password reset and account creation.

It's great that you're recording logins, but you really should be recording password resets and account creations too. Recording account creations will allow you to recreate accurate audit timelines from when an account was created to when an incident occurred. Password resets are also important - they can be a leading indicator of an account breach.

The good news is since you've already done all the hard work adding Secure Audit Log to these other areas will be a piece of cake.

To add audit logging to password resets find the handler in resetPasswordOptions in /\<project_root\>/api/src/functions/auth.ts. Then add the following code:

handler: (user) => {
  const clientIp = ipAddress(event)
  audit.log({
    actor: user.email,
    action: 'Password Reset',
    status: 'Success',
    source: `${clientIp}`,
    message: `${user.email} performed a password reset.`,
  })
  return user
},

To add audit logging to account creations find the handler in signupOptions in /\<project_root\>/api/src/functions/auth.ts. Then add the following code:

handler: ({ username, hashedPassword, salt, userAttributes }) => {
    const clientIp = ipAddress(event)
    audit.log({
      action: 'Create Account',
      status: 'Success',
      source: `${clientIp}`,
      message: `An account (${username}) was created from ${ipResults.clientIp}`,
    })
    return db.user.create({
      data: {
        email: username,
        hashedPassword: hashedPassword,
        salt: salt,
        // name: userAttributes.name
      },
    })
},

See, super easy. Now try the account creation and password reset processes to validate that the log messages are recorded as expected. Remember to start your redwood app if you have stopped it using the following command from your terminal in project_root.

yarn rw dev

Review your audit logs in Pangea Admin Console->Secure Audit Log->View Logs.

Congratulations, your App is more secure AND more compliant!

Part 3 - Blocking embargoed countries

The RedwoodJS is just a very simple blogging app. It's unlikely you'd apply any embargo restrictions to it, but let's assume there are. Specifically, let's assume that the ITAR Embargo list (International Traffic in Arms Regulations) applies to it. Great news! Pangea just so happens to have that list as an out-of-the-box Embargo list. What a happy coincidence.

In all seriousness, the embargo service can be an invaluable asset for companies that do need to adhere to embargoes and sanctions. It allows you to submit an IP address (in this case, a client IP), and check to see if it exists on an embargo list (in this case, the ITAR list). The API will return whether the IP exists on any of the enabled lists, at which point you can decide how to respond. In the case of this example, you'll respond with a message letting the customer know that access is denied. You'll also write an audit log record, recording the attempted login or account creation.

Step 1: Adding the embargo check to login

The easiest thing to do would be simply to find the audit.log code, add the embargo check, and then change the logged message and app behavior, depending on what was returned. A little foreshadowing... that won't work due to a couple of problems, but let's start here anyway.

Find the handler in loginOptions where you added the audit.log code to the login flow. First you'll add code to call the Embargo service.

handler: (user) => {
    const clientIp = ipAddress(event)
    const embargoResp = await embargo.ipCheck(clientIp)
    if (embargoResp.result.count > 0){
        audit.log({
            action: 'Create Account',
            status: 'Failed',
            source: `${ipResults.clientIp}`,
            message: `${clientIp} is attempting to log in from an embargoed country - ${embargoResp.country} (${embargoResp.countryCode})`,
        })
        throw new Error(
            `Access Denied. You are attempting log in from an embargoed country - ${embargoResp.country} (${embargoResp.countryCode})`
        )
    } else  {
        audit.log({
            actor: user.email,
            action: 'Login',
            status: 'Success',
            source: `${clientIp}`,
            message: `${user.email} successfully logged in.`,
        })
        return user
    }
},

If you're writing this code in a modern editor or IDE, you'll probably notice that the code is complaining that you're using await in a function not marked as async. This happens because you have to await the results from the async call to embargo.ipCheck before you can use them. To resolve this add async after handler: like so:

handler: async (user) => {

You may notice that this code throws an error when a user tries to log in from an embargoed country. The RedwoodJS sample app will resolve this error in a nice toast message to the end user. Congratulations on adding an embargo check to the login flow, but, unfortunately, there be dragons still.

Step 2: Sending only valid IPs to the Embargo Service

If you went ahead with the example, you might notice that you don't get the expected result. Assuming you're running this example from your local machine, you're getting "localhost" back from the ipAddress function that you created, which is not a legitimate IP address, causing the embargo.ipCheck to fail.

To fix this problem, you'll want to validate that the IP address is an IP address. An easy way to do this is to add the package ip-address to your example app. You can do this by running the following from your project_root

yarn workspace api add ip-address

Once added, import it into your /\<project_root\>/api/src/functions/auth.tsfile.

import { Address4 } from "ip-address";

Note: I'm assuming IPv4 here, and only checking for IPv4 format.

In order to do this embargo check properly, you'll want to validate that the IP address is indeed an IP address, check the ip, and then review the results. Rather than do all of that inline, it would be easier and cleaner to do this in a new function, especially because this will be necessary to reuse during account creation.

Add the following code just below the ipAddress function you added earlier:

export const handler = async (event, context) => {
  const ipAddress = ({ event }) => {
    return (
      event?.headers?.['client-ip'] ||
      event?.requestContext?.identity?.sourceIp ||
      'localhost'
    )
  }

  const checkIpAddress = async (): Promise<{
    found: number
    clientIp: string
    country: string
    countryCode: string
  }> => {
    let found = 0
    let country = undefined
    let countryCode = undefined

    //is a valid IP?
    const clientIp = ipAddress(event)
    if (Address4.isValid(clientIp)) {
      //perform embargo check
      const embargoResp = await embargo.ipCheck(ipAddress(event))
      found = embargoResp.result.count
      if (embargoResp.result.count > 0) {
        country = embargoResp.result.sanctions[0].embargoed_country_name
        countryCode = embargoResp.result.sanctions[0].embargoed_country_iso_code
      }
    }

    return {
      found: found,
      clientIp: clientIp,
      country: country,
      countryCode: countryCode,
    }
  }

In the above code, you'll use Address4 from the ip-address package to validate that the client IP is indeed a client IP. Then you'll perform the embargo check. You'll return 0 in the found field of the response if the ip was not found in any embargo list and some number greater than 0 if it was. This code assumes that the number of lists in which the IP address was found is not important.

You'll now want to update your handler in login options to use the new checkIpAddress function you just created.

handler: async (user) => {
  const ipResults = await checkIpAddress()
  if (ipResults.found > 0) {
    audit.log({
      actor: user.email,
      action: 'Login',
      status: 'Success',
      source: `${ipResults.clientIp}`,
      message: `${user.email} is attempting to login from an embargoed country - ${ipResults.country} (${ipResults.countryCode})`,
    })
    throw new Error(
      `Access Denied. You are attempting to login from an embargoed country - ${ipResults.country} (${ipResults.countryCode})`
    )
  } else {
    audit.log({
      actor: user.email,
      action: 'Login',
      status: 'Success',
      source: `${ipResults.clientIp}`,
      message: `${user.email} successfully logged in.`,
    })
    return user
  }
},

Finally, if you try this code, you should see that it works as expected... at least, you hope. The trouble is, if you're running this on your local machine, the only IP address ever returned is 'localhost.' That doesn't give you much opportunity to test the embargo check, does it?

To simulate a request from an embargoed nation, update your ipAddress function to return 210.52.109.1 (a North Korean IP address) instead of localhost when no client IP can be determined.

export const handler = async (event, context) => {
  const ipAddress = ({ event }) => {
    return (
      event?.headers?.['client-ip'] ||
      event?.requestContext?.identity?.sourceIp ||
      '210.52.109.1'
    )
  }

If your App is still running, try your code one more time, you should see that you are unable to login to your example App.

yarn rw dev

Review your audit logs in Pangea Admin Console->Secure Audit Log->View Logs.

Step 3: Adding the embargo check to account creation

You have one more task. That's to add the Embargo check to the account creation process. I'll challenge you not to look at the code directly beneath this and try to do it yourself. Then compare it against the following code that I've added to the handler of signupOptions:

handler: async ({ username, hashedPassword, salt, userAttributes }) => {
  const ipResults = await checkIpAddress()
  if (ipResults.found > 0) {
    audit.log({
      action: 'Create Account',
      status: 'Failed',
      source: `${ipResults.clientIp}`,
      message: `${ipResults.clientIp} is attempting to create an account (${username}) from an embargoed country - ${ipResults.country} (${ipResults.countryCode})`,
    })
    throw new Error(
      `Access Denied. You are attempting to create an account from an embargoed country - ${ipResults.country} (${ipResults.countryCode})`
    )
  } else {
    audit.log({
      actor: username,
      action: 'Create Account',
      status: 'Success',
      source: `${ipResults.clientIp}`,
      message: `${ipResults.clientIp} created an account (${username})`,
    })
  }
  return db.user.create({
    data: {
      email: username,
      hashedPassword: hashedPassword,
      salt: salt,
      // name: userAttributes.name
    },
  })
},

Try out the code one last time, and validate that it worked. You should see that you are unable to create an account.

Finish Line

Congratulations! You made it. You've successfully added Audit and Embargo checks to the RedwoodJS sample app. Along the way, you created a Pangea TypeScript module that you can use in ANY TypeScript app. You learned about why you should audit AuthN activity. You learned how to block logins and account creations by embargoed countries. Most importantly, though, you had a great time doing it.... I hope.

If you liked this tutorial, please share it with your friends. If you see room for improvement or even more Pangea integrations, let us know so we can collaborate.