Governance & Access

Privat per Default.
Jedes Mal geprüft.

Relpin hält deployte Apps nur für verifizierte Mitglieder Ihrer Organisation erreichbar. Jeder Request durchläuft Session-, Organisations-, App- und Umgebungsprüfungen, bevor die App-Runtime ihn sieht.

Jetzt starten So funktioniert es
Relpin Auth Flow
Prüft
Access checks pre-dispatch
01
Session User ist bei Relpin angemeldet
02
Organisation Mitgliedschaft verifiziert
03
App-Berechtigung Rolle gewährt Zugriff auf diese App
04
Umgebung Scope: DEV / TEST / PROD
Privat per Default

Keine deployte App wird aus Versehen eine öffentliche URL.

Relpin behandelt deployte App-Routen als governed Entry Points. Dispatch-Routing liegt hinter Relpin-Autorisierung, entfernt spoofbare Identity-Header und scheitert geschlossen, wenn User- oder Organisationskontext fehlt.

01
Nicht public-by-default

Deployte App-Routen verlangen eine authentifizierte Relpin-Session, bevor Traffic die App erreicht.

02
Verifizierte Identity

Apps erhalten plattform-verifizierten User- und Org-Kontext — nie browser-supplied Header.

03
Fail-closed Dispatch

Fehlende oder ungültige Autorisierung blockiert die Route, statt zur App durchzufallen.

Privat per Default
Ohne Relpin-Zugriff
× Keine nutzbare App-Antwort
× Kein vertrauenswürdiger Org-Kontext
× Keine Browser-Identity akzeptiert
× Kein öffentlicher Fallback-Pfad
Mit Relpin-Zugriff
✓ Relpin-Account verifiziert
✓ Organisationsmitgliedschaft bestätigt
✓ Umgebung und App-Zugriff begrenzt
✓ Request mit verifiziertem Kontext weitergeleitet
Deployte Apps benötigen eine authentifizierte Relpin-Session
Organisationsmitgliedschaft wird geprüft, bevor App-Traffic bedient wird
Generierte Apps erhalten verifizierten Plattformkontext statt Browser-Identity
Fehlende oder ungültige Autorisierung blockiert die Route statt durchzufallen
Authentifizierte Session · Organisationsmitgliedschaft · Verifizierter App-Kontext · Fail-closed Dispatch
RBAC & Permission Keys

Capability-basierter Zugriff,
server-side aufgelöst.

Rollen mappen auf konventionsbasierte Permission Keys statt auf Ad-hoc-Checks im App-Code. Relpin löst Capabilities server-side auf, bevor eine Aktion läuft — dasselbe Zugriffsmodell governt jedes Tool, das Sie ausliefern.

01
Konventionsbasierte Keys

Berechtigungen folgen einer vorhersehbaren resource.action-Form, sodass Zugriffsabsicht lesbar statt geraten ist.

02
Rollen, keine Einzelfälle

Capabilities hängen an Rollen. Vergeben und Entziehen passiert an einer Stelle, nicht pro App.

03
Server-side Auflösung

Zugriff wird auf der Plattform bewertet, bevor die Aktion ausgeführt wird — der Browser hält die Entscheidung nie.

Rolle × Capability server-side
capability
Admin
Editor
Viewer
deploy
×
×
secrets
×
×
data.write
×
data.read
Permission Keys folgen einer Konvention statt bespoke Per-App-Logik
Capabilities werden über Rollen vergeben, nicht in jedes Tool kopiert
Zugriffsentscheidungen werden server-side aufgelöst, bevor eine Aktion läuft
Dasselbe Zugriffsmodell gilt über jede governed App hinweg
Konventionsbasierte Keys · Rollen-scoped Capabilities · Server-side Entscheidungen
Autorisierungsgrenze

Access Checks liegen vor der App-Runtime.

Generierte Apps sollten nicht selbst beweisen müssen, wer der User ist. Relpin prüft zuerst die Route und leitet danach nur verifizierten Identity- und Organisationskontext in die App-Runtime weiter.

01
Dispatch ist die Grenze

Eine Relpin-kontrollierte Route ist der öffentliche Entry Point, keine eigenständige App-Oberfläche.

02
Geprüft vor Code-Ausführung

Session, Mitgliedschaft, Umgebung und App-Kontext werden bewertet, bevor generierter Code läuft.

03
Nur begrenzter Kontext

Die Runtime erhält verifizierten Identity- und Org-Kontext — keine Secrets oder rohen Account-Tokens.

Request-Lifecycle
1 Request

User öffnet App-Route

Der Browser erreicht eine Relpin-kontrollierte App-Route, keine eigenständige öffentliche App-Oberfläche.

2 Verify

Relpin prüft Zugriff

Session, Organisationsmitgliedschaft, Umgebung und App-Routenkontext werden vor Dispatch bewertet.

3 Forward

Nur verifizierter Kontext

Die generierte App erhält vertrauenswürdigen Identity- und Org-Kontext, nachdem die Plattform den Request akzeptiert hat.

Credentials bleiben plattformseitig. Die App-Runtime erhält begrenzten Kontext über den Sidecar-Proxy — nie rohe Tokens.
Dispatch ist der öffentliche Entry Point für deployte Apps
Authn/Authz wird erzwungen, bevor generierter App-Code läuft
Die App-Runtime erhält begrenzten Kontext statt Secrets oder rohen Account-Tokens
Abgelehnte Requests bleiben außerhalb der generierten App-Oberfläche
Route-Auth zuerst · App-Runtime danach · Nur begrenzter Kontext
Umgebungen & Promotion

Releases durch
DEV, TEST und PROD promoten.

Jede Umgebung ist ein isolierter Scope mit eigenen Tables, Daten und Zugriff. Apps werden in DEV und TEST deployt und laufen dort, nicht nur in PROD, und Releases promoten als gepinnte Bundles vorwärts. Die Promotion ist gegatet: TEST verlangt eine Freigabe, PROD zwei mit Funktionstrennung.

01
Isolierte Umgebungen

DEV, TEST und PROD erhalten jeweils eigene Tables und Daten. Nichts blutet über einen Scope hinweg.

02
In jeder Umgebung deployt

Apps werden in DEV und TEST deployt und laufen dort, nicht nur in PROD — echtes Verhalten vor der Promotion prüfen.

03
Freigabe-gegatete Promotion

TEST verlangt eine Freigabe, PROD zwei mit Funktionstrennung. Wer eine Promotion anfordert, kann sie nicht selbst freigeben, und Freigaben binden an den exakten Artifact-Hash.

Promotion-Pfad
DEV

Deployen, ausführen und mit isolierten Daten prüfen

TEST

Gegen repräsentative Daten validieren

PROD

Nur verifizierte Mitglieder bedienen

pinned · deterministic · isolated
Gates
Umgebungsisolation
Aktiv
Zugriff pro Umgebung
Aktiv
Gepinnte Release-Promotion
Aktiv
Approval Gates · Funktionstrennung
Aktiv
DEV, TEST und PROD sind isolierte Scopes, jeder mit eigenen Tables und Daten
Apps werden in jeder Umgebung deployt und laufen dort, nicht nur in der Produktion
Zugriff auf jede Umgebung wird über Mitgliedschaft und Rolle gesteuert; Orgs können eigene Rollen mit musterbasierten Permission-Grants definieren
Die Promotion ist freigabe-gegatet: eine Freigabe für TEST, zwei für PROD, gebunden an den exakten Artifact-Hash
Isolierte Umgebungen · Freigabe-gegatete Promotion · Funktionstrennung · Hash-gebundene Freigaben
Use Cases

Interne Software, die intern bleibt.

Governance greift überall gleich — bei den Tools, die Teams tatsächlich ausliefern, wo Zugriff, Umgebung und Identity beweisbar sein müssen.

REGULIERT

Compliance-gebundene Tools

Interne Tools mit regulierten Daten bleiben hinter verifizierter Org-Mitgliedschaft und begrenztem Zugriff.

EXTERN

Contractor- & Partnerzugriff

Begrenzten, rollenbasierten Zugriff für externe Mitarbeitende vergeben, ohne eine öffentliche Oberfläche freizulegen.

ADMIN

Kundendaten-Konsolen

Admin-Tools, die Produktionsdaten lesen und schreiben, laufen hinter Capability-Checks statt geteilten Logins.

OPS

Approval- & Triage-Queues

Ops- und Finance-Workflows begrenzen, wer handeln darf, mit umgebungsbewusstem Zugriff bei jedem Schritt.

STAGING

Umgebungs-begrenzte Previews

DEV- und TEST-Builds bleiben nur für die Mitglieder erreichbar, die dieser Umgebung zugewiesen sind.

AUDITIERT

Privilegierte Admin-Aktionen

Sensible Aktionen liegen hinter rollenbasierten Capabilities, damit die richtigen Personen die richtigen Keys halten.

Reguliert · Externer Zugriff · Admin-Konsolen · Umgebungs-begrenzt
Governed Apps

Interne Software bauen,
die intern bleibt.

Relpin verbindet code-first App-Entwicklung mit Account-, Organisations- und Umgebungsgrenzen für deployte Apps.

Jetzt starten Plattform erkunden

Privat per Default · Org-scoped Access · Dispatch-Autorisierung

Account erforderlich. Organisation geprüft. App-Zugriff begrenzt.