Ultrahost/ docs
All examples

Example 07

Experiment

Role-Based Access Control

Decide who can do what, then keep checking that it is still true.

This example is where grants are created; the previous one is where they are used. Teams, roles, and policies are defined for the features they unlock, then audited on a schedule, measured by how often access is exercised, and analyzed as a graph of who is connected to what.

Chapter one

When access is set up

Before anyone can be allowed to do anything, the rules have to exist. Each step adds one layer, from the group of people to the feature they can reach.

  1. 1
    Authorization Layer

    Teams are created

    Users belong to teams, and teams are what gets granted access around the platform.

  2. 2
    Authorization Layer

    Roles are defined

    Roles describe the kinds of access a team can take on, such as viewer, editor, or admin.

  3. 3
    Authorization Layer

    Policies grant roles access to features

    A policy ties a role to a feature in your application, and says what that role may do there.

Chapter two

Audit authorizations

A grant is only as good as the last time someone checked it. Three blocks keep the picture honest.

Time to look at who can do what

Grants pile up quietly, so the check runs on its own rhythm instead of waiting for someone to remember.

  • On a schedule

    Who has access to what

    The Cron engine runs periodic audits of every grant, so stale or surprising access is easy to spot.

    Cron

  • Over time

    How often access is used

    Each time a user is authorized to do something, it is counted as a series, so you can see what was done and how often.

    Timeseries Database

  • By connection

    Who is connected to what

    Grants, policies, teams, and users are loaded into the graph, so you can analyze how every person is connected to every permission.

    Graph Database

Make it yours

Variations worth trying

  • Begin with two roles and one protected resource before modeling a whole organization.
  • Turn the audit into a weekly report instead of an automatic revocation.
  • Skip the usage counts until you need to explain why a permission exists.

Starting point

Ask your coding agent for your version

Use this prompt as a starting point, then change whatever does not fit your idea.

Build role-based access control with teams, roles, and policies for the features they unlock, periodic audits, a record of how often access is used, and a graph of who is connected to what.

Use these Ultrahost building blocks, in this flow.

When access is set up:
1. Authorization Layer: Users belong to teams, and teams are what gets granted access around the platform.
2. Authorization Layer: Roles describe the kinds of access a team can take on, such as viewer, editor, or admin.
3. Authorization Layer: A policy ties a role to a feature in your application, and says what that role may do there.

Audit authorizations:
- On a schedule (Cron): The Cron engine runs periodic audits of every grant, so stale or surprising access is easy to spot.
- Over time (Timeseries Database): Each time a user is authorized to do something, it is counted as a series, so you can see what was done and how often.
- By connection (Graph Database): Grants, policies, teams, and users are loaded into the graph, so you can analyze how every person is connected to every permission.

Treat this as a starting point. Keep the parts that fit my idea and adapt the rest.

Next example

Unified Search