Showing posts with label role. Show all posts
Showing posts with label role. Show all posts

Pipi 9 RBAC

Mike's Notes

This is a summary of the RBAC (Role-based access control) now used globally within Pipi 9.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

17/12/2025

Pipi 9 RBAC

By: Mike Peters
On a Sandy Beach: 18/09/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Summary

Pipi 9 uses automated RBAC (Role-based access control) to control user access to everything that has a namespace.

Pipi 10 will have additional authorisation frameworks available to be chosen by enterprise accounts.

User Account Properties

  • ID
  • Code Name
  • Namespace
  • Name
  • Default Language
  • Global authorisation framework (RBAC)
  • Account type
  • ...

Deployment Properties

  • ID
  • Code Name
  • Namespace
  • Name
  • Description
  • Language (eg English)
  • Inherited User Account
  • Deployment Class (type of tenancy)
  • ...

Workspace Properties

  • ID
  • Code Name
  • Namespace
  • Name
  • Description
  • Inherited language (eg English)
  • Inherited User Account
  • Inherited Deployment
  • Domain Model
  • Domain Model Template
  • ...

Autonomous Agent Properties

  • ID
  • Code Name
  • Namespace
  • Name
  • Description
  • Agent Type (Pipi System, Engine, Domain, Algorithm, CAS, Digital Twin, etc.
  • ...
  • Many Roles
  • Many Policies
  • ...

Namespace Engine key to RBAC

Mike's Notes

After a bit of experimentation, it turns out the Namespace Engine (nsp) is key to reliably implementing RBAC globally.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

12/09/2025

Namespace Engine key to RBAC

By: Mike Peters
On a Sandy Beach: 12/09/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

This afternoon, I figured out that the Namespace Engine (nsp) already has a way to register the interfaces of every agent that is automatically built by the Factory Engine (fac). This includes industry domain-based applications, such as Websites, Health and Rail.

I added additional Interface Class Types, "Role", and "Policy", and solved the problem of making this global.

Roles

This allowed for the rapid addition of roles to any autonomous agent.

Examples

  • Website Owner
  • Website Administrator
  • Website Editor
  • Website Visitor
  • Website Search Engine
  • etc

This automatically generates security role names used by the Security Engine (scr).

Policy

This allowed for the rapid addition of policy to any autonomous agent.

Examples

  • CNAME Record
  • Website Hosting
  • Patient Record
  • etc

This automatically generates security policy names used by the Security Engine (scr).

Integration

This would also enable configuration storage in XML or other open formats for interchange and documentation.

This configuration system could be used for open-source SaaS applications.

RBAC Policies

Mike's Notes

I'm building the Policy part of RBAC

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

11/09/2025

RBAC Policies

By: Mike Peters
On a Sandy Beach: 10/09/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

I'm loosely copying how Windows implements RBAC. Mainly to understand how it works.

From Windows Learn (without the pictures).

To create an access policy

  1. In Server Manager, click IPAM. The IPAM client console appears.
  2. In the navigation pane, click ACCESS CONTROL. In the lower navigation pane, right-click Access Policies, and then click Add Access Policy.
  3. The Add Access Policy dialog box opens. In User Settings, click Add.
  4. The Select User or Group dialog box opens. Click Locations.
  5. The Locations dialog box opens. Browse to the location that contains the user account, select the location, and then click OK. The Locations dialog box closes.
  6. In the Select User or Group dialog box, in Enter the object name to select, type the user account name for which you want to create an access policy. Click OK.
  7. In Add Access Policy, in User Settings, User alias now contains the user account to which the policy applies. In Access Settings, click New.
  8. In Add Access Policy, Access Settings changes to New Setting.
  9. Click Select role to expand the list of roles. Select one of the built-in roles or, if you have created new roles, select one of the roles that you created. For example, if you created the IPAMSrv role to apply to the user, click IPAMSrv.
  10. Click Add Setting.
  11. The role is added to the access policy. To create additional access policies, click Apply, and then repeat these steps for each policy that you want to create. If you do not want to create additional policies, click OK.
  12. In the IPAM client console display pane, verify that the new access policy is created.

RBAC causes a change to the Deployment Engine

Mike's Notes

Building out RBAC is leading to other changes in Pipi.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

12/09/2025

RBAC causes a change to the Deployment Engine

By: Mike Peters
On a Sandy Beach: 09/09/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Using RBAC to redesign the Pipi security model has led to some changes in other Engines. 

User Account

A User Account has one or more Deployments. 

Deployment

A Deployment is a container for one or more Workspaces. A deployment has these properties;

  • ID
  • Code Name
  • Name
  • Description
  • One language (eg English)
  • One User Account
  • One Deployment Class (type of tenancy)

Those properties are inherited by all workspaces.

Workspace

A workspace has these properties;

  • ID
  • Code Name
  • Name
  • Description
  • One inherited language (eg English)
  • One inherited User Account
  • One Deployment
  • One pre-built Domain Model (eg, Screen Production).
  • One Domain Model Template (eg, Feature Film, Documentary, Live Broadcast), These templates can be customised and shared.

Those properties are inherited. This means each Workspace/Domain Model comes with its own set of prebuilt Security Roles, Security Profiles

Security Role

A security role has these properties;

  • ID
  • Code Name
  • Name
  • Description
  • One User Account Class ( eg, Pipi, Enterprise, DevOps, SME, User)
  • One language (eg, English, French, Hebrew)
  • One Domain Model (eg, health, website, sewerage, public transport, art gallery).

Domain Model

Here is an example of Domain Model properties;

  • Domain Model/Workspace: Website
  • Domain Model Function: create CNAME, delete CNAME
  • Security Role: Webmaster, Editor, Visitor
  • Security Profile: DNS Registry, Website, Design System, CDN

Role-Based Access Control (RBAC)

Mike's Notes

I'm revisiting the role-based access control (RBAC) in Pipi.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

13/09/2025

Role-Based Access Control (RBAC)

By: Mike Peters
On a Sandy Beach: 08/09/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Pipi 4

Pipi utilised a simple role-based access control (RBAC) system. It enforced a change of passwords for both admins and users. The old data model was similar to the one depicted in this diagram.

Pipi 9

Using RBAC to administer accounts for users must scale from very simple to large. Something much more robust is required.

Requirements

Entities;

  • Users
  • Policy
  • Roles
  • Permissions
  • Groups
  • Objects
  • Sessions
  • Join tables

Roles;

  • In a hierarchy.
  • Separation of duties by allowing and denying access.
  • Fine-grained.

Uses;

  • Pipi as an ecosystem and an individual system.
  • Each account
  • Organisational structures within an account
  • Shares
  • Individual users
  • The public
The RBAC needs to be automatically logged, tested and audited.