Your First 10 Minutes with EnforceAuth

Goal: in ten minutes, go from a fresh login to a live policy bundle and your first decision log showing up in the console. No production wiring, no cloud accounts you don't already have, no Rego expertise required.

What you'll have at minute 10:

• An Organization and a System in your entity tree
• A Git-backed policy source building real OPA bundles
• One successful deployment
• A local OPA pulling that bundle and answering an authorization query
• That decision visible on the Decisions page

The fast path uses EACommerce — EnforceAuth's reference repo with ready-made Rego and a PEP. If you already run OPA with your own Rego repo, you can substitute it at Step 3; everything else is identical.

Before the clock starts — have these open:

• A browser signed in to console.enforceauth.com (or console.enforceauth.dev)
• A terminal with Docker (to run OPA locally) and git
• Optional but faster later: eactl installed — brew install enforceauth/tap/eactl

---

Minute 0–1 — Sign in and find your bearings

1. Open console.enforceauth.com and sign in (email or Continue with Google; enter your MFA code if prompted).
2. You land on the Dashboard. The left navigation is: Dashboard · Policies · Decisions · Deployments · Analytics (Coming Soon) · System Settings. The five you'll use today:
   • Dashboard — policy + decision health at a glance
   • Policies — statistics and policy management
   • Decisions — decision logs streaming in from your PDPs
   • Deployments — trigger and track pipeline runs
   • System Settings → Entity Management — the entity tree (orgs and systems)

If you see a Quick Start or onboarding banner, you can follow it — it walks the same path as below. This guide is the no-detours version.

Verify: you can see the Dashboard and the left nav. ✅

---

Minute 1–3 — Create an Organization and a System

EnforceAuth models your estate as an entity tree. Policies deploy to a System; an Organization groups systems and holds shared defaults.

1. Go to System Settings → Entity Management (/system-settings/entities).
2. Click Create Entity.
3. Create an Organization — name it something like Acme (this is your tenant-scoped root).
4. Create the System: Create Entity again → Type: System, and set Parent Entity to your org. Name it payments-demo.

The System is where policy source, bundle destination, and environments attach. Put shared config on the org and child systems inherit it (dashed "Inherited from" cards show when a value is inherited).

Verify: payments-demo appears under Acme in the tree with type System. ✅

---

Minute 3–5 — Point the System at policy + storage

Open your payments-demo system → Configuration. You'll set two things.

Policy source (where Rego comes from)

1. In Policy source, choose Git / GitHub.
2. Repo: the EACommerce repo (fork it first if you want write access) — github.com/EnforceAuth/ea-commerce.
3. Branch: main. Policy path: the folder that holds the Rego package (EACommerce ships this; use its documented policy path).
4. If EnforceAuth needs read access, install/authorize the GitHub App (System Settings → Integrations → Connect GitHub) and store the credential as a Secret on the entity when prompted.

On deploy, EnforceAuth clones the repo, runs opa test, and builds a bundle.

Bundle destination (where PDPs fetch bundles)

1. In Bundle destination, pick the storage you already have — S3, GCS, or Azure Blob — and give it a path EnforceAuth can write to.
2. No cloud bucket handy? Use a Git output destination so the built bundle is written back to a repo/branch you control, then serve it locally in the next step.

Verify: the system's Configuration shows a Policy source and a Bundle destination (either directly set or inherited). ✅

---

Minute 5–7 — Deploy

1. Go to Deployments and click Deploy.
2. Trigger a deployment for payments-demo in the dev environment.
3. Watch the run. The pipeline phases are: test (opa test) → build (bundle) → publish (to your destination). A green run means a real bundle.tar.gz now lives at your destination.

Prefer the CLI? eactl pipeline runs the same test → build → deploy against your entity. eactl diagnose preflight checks your setup first if anything looks off.

Verify: the Deployments page shows one succeeded run, and your destination now contains a bundle artifact. ✅

---

Minute 7–9 — Run OPA and point it at your bundle

Now stand up a local PDP that pulls the bundle you just published.

1. Create an API key so the PDP can send decision logs back: open the entity → API Keys → create one → copy it (you won't see it again).
2. Configure OPA with a services block pointing at your bundle destination and a decision_logs block pointing at EnforceAuth, authenticated with that API key. Minimal shape:

# opa-config.yaml
services:
  bundles:
    url: <your-bundle-destination-URL>
bundles:
  payments:
    service: bundles
    resource: bundle.tar.gz
decision_logs:
  console: false
  service: ea
  reporting:
    min_delay_seconds: 5
    max_delay_seconds: 10
services_ea: &ea
  ea:
    url: https://api.enforceauth.com
    headers:
      authorization: "Bearer <YOUR_API_KEY>"

Copy the exact services/decision_logs block EnforceAuth shows on the API Keys and Decision logs pages — it's pre-filled with your real URLs. The snippet above is the shape, not the literal values.

3. Run OPA:

docker run --rm -p 8181:8181 \
  -v "$PWD/opa-config.yaml:/opa-config.yaml" \
  openpolicyagent/opa run --server --config-file /opa-config.yaml

Verify: OPA logs show it activated the bundle (no bundle errors on startup). ✅

---

Minute 9–10 — Ask a question, then watch it appear

1. Send OPA an authorization query against the EACommerce policy (use the package + rule the repo documents — commonly something like data.<package>.allow):

curl -s localhost:8181/v1/data/<package>/allow \
  -H 'content-type: application/json' \
  -d '{"input":{"user":"alice","action":"read","resource":"order:123"}}'

You'll get {"result": true} or {"result": false} — that's a real authorization decision.

2. In the console, open Decisions. Within a few seconds (the reporting delay above), your query appears as a decision log — showing the input, the result, and which system produced it. (Decision Replay lets you re-run it later.)

Verify: at least one decision log for payments-demo is visible on the Decisions page. ✅ 🎉

---

You did it — what just happened

In ten minutes you exercised the full Define → Enforce → Audit loop:

• Define — Rego in Git became a tested, versioned bundle.
• Enforce — a deployment published that bundle; your PDP pulled it and answered a query.
• Audit — the decision streamed back into EnforceAuth as an immutable log.

Next 30 minutes

• Make it multi-environment: add staging and prod and promote a bundle dev → staging → prod. See Deployments and Multi-environment best practices.
• Automate it: wire the GitHub Action (deploy-action) so a merge to main deploys for you. See GitHub Actions and CI/CD.
• Wire your real app: replace the curl with your service's PEP calling OPA. See Application integration.
• Understand your engine choice: if you have masking, delta-bundle, or partitioning needs, read OPA vs EOPA.
• Go to production properly: follow the Onboarding Guide to model your real entity tree, secrets, users, and promotion chain.

If something didn't work

Symptom	Check
Deploy fails at test	Your policy_path is wrong, or opa test fails in the repo. Run opa test locally against the same path.
Deploy fails at publish	Bundle-destination credentials. Run eactl diagnose secrets and eactl diagnose permissions.
OPA won't load the bundle	Bundle URL/credentials in services. Confirm the artifact exists at the destination.
No decision logs appear	API key wrong/expired, or decision_logs.service misconfigured. Re-copy the block from the Decision logs page; wait past the max_delay_seconds.
Stuck	eactl diagnose preflight runs all of the above at once.