Nexuvius / Aran

அரண்

Aran

The gateway that checks every request.

Aran sits in front of your internal apps. Nothing reaches them until it knows who is asking, that they are allowed, and that their device is in good shape. It is one small Go program you run yourself.

Talk to us about Aran How it works
Try it: change the requestSimulated
Signed in
Group
Asks for
Disk encrypted
Screen lock
  1. IdentitySigned in through Aadhi
  2. Policyengineering may open /deploy
  3. DeviceEncrypted, screen lock on
  4. Your appForwarded over mutual TLS
Allowedaudit: allow user=maya@example.com groups=[engineering] path=/deploy

Example policy: engineering may open everything and needs an encrypted disk and a screen lock. Guests may open /wiki/public only.

Features

What Aran does

  • Sign-in you already haveAran signs people in through Aadhi or any standard OpenID Connect provider, using the authorization code flow with PKCE.
  • Deny by defaultA request goes through only if one of the person's groups is allowed that path. Change the policy file and Aran picks it up without a restart.
  • Device postureA group can require a signed statement about the device: its operating system, disk encryption and screen lock. The right person on the wrong device is still turned away.
  • Instant revocationWith Shared Signals, Aran hears from the identity provider when a session is revoked or an account is disabled, and ends that person's access.
  • Mutual TLS to your appsAran can verify each app's certificate and present its own, so the last hop behind the gateway is authenticated too.
  • Its own short sessionsAran issues a short-lived signed session of its own and keeps the refresh token encrypted. Signing keys can be rotated.
  • Every decision loggedEach allow and deny is written to an audit log with the reason, to a rotating file or forwarded over HTTP.
  • Careful at the edgesRate limits on sign-in, clear error pages for people and JSON for API clients, and a config check that refuses to start on a mistake.
  • Small to runA single static binary in a minimal container image, running as a non-root user. Secrets can come from environment variables.

How it works

What happens to a request

  1. Who is asking?No valid session means a trip to the identity provider to sign in. Aran then issues its own short session.
  2. Are they allowed here?Aran matches the person's groups against the policy for that path. If nothing allows it, the answer is no.
  3. Is the device in good shape?If the group requires it, Aran verifies a signed, recent statement of the device's state. A plain header that anyone could set is never trusted.
  4. Forward itAran routes the request to the right app, over mutual TLS if you have set it up.
  5. Write it downThe decision and its reason go to the audit log, whichever way it went.

Where Aran stands today

Working build
Version 1.8, with more than 100 automated tests, including real mutual TLS handshakes and signed posture checks.
Works with Aadhi
Aran uses Aadhi as its identity provider, including Shared Signals for revocation. It was first proven against Keycloak.
Device agents
Aran verifies device statements but does not produce them. A test agent is included, and a real deployment would use your device management tool.
Availability
Not publicly released yet. Get in touch if you would like to see it running.

The rest of the family

Want to put Aran in front of your apps?

Tell us what you are protecting and how people sign in today. We will show you Aran running with Aadhi.

Email contact@nexuvius.comMeet Aadhi