
that thing
we do
Frends has more features than any other integration software out there. Explore, ideate, and if anything is unclear - hit us up at any time. This library is bound to grow over time.
Rollenbasierte Benutzeroberfläche
Frends verfügt über ein fein abgestuftes Benutzerzugriffsverwaltungssystem, das auf benutzerdefinierten Rollen innerhalb der frends-Plattform basiert. Die Rollen werden dann dem Identitätsverwaltungssystem Ihrer Wahl zugeordnet, z. B. Azure AD.
Die Frends-Benutzeroberfläche wurde entwickelt, um das rollenbasierte Benutzerzugriffsmanagementsystem von Grund auf zu unterstützen. Das bedeutet, dass jede Aktion hinter einer Schaltfläche und jedes Datenelement in jeder Ansicht so konfiguriert werden kann, dass der Zugriff für eine bestimmte Rolle entweder zugelassen oder blockiert wird.
Zum Beispiel eine Rolle, die für einen Entwickler konfiguriert ist:
! [Frends Benutzerverwaltung und Rollen] (//images.ctfassets.net/y3eyw5ons608/2FWHGtKBH7aXkCSlcf850u/fd92356574c88904f4ff1b0f55577242/FRENDS_User_Management.PNG)
Benutzerrollen
Die Benutzerrollen, die in frends definiert sind, dienen in der Regel dazu, die Rechte eines authentifizierten Benutzers aus Sicherheitsgründen einzuschränken, aber auch ein DevOps-Modell mit dedizierten Rollen für z.B. Tester zu unterstützen und durchzusetzen.
Ein Kunde kann z.B. Rollen für folgende Benutzertypen konfigurieren:
Rolle | Erläuterung |
---|---|
Entwickler | Der Entwickler kann so konfiguriert werden, dass er nur Zugriff auf die Entwicklungsumgebung erhält und mit Privilegien Lösungen nur für die Testumgebung bereitstellen kann. |
Tester | Der Tester kann so konfiguriert werden, dass er nur Komponententests ausführen und Integrationen nur in der Testumgebung manuell ausführen darf. Zusätzlich kann dem Tester erlaubt werden, einen Integrationsprozess als "Genehmigt" zu markieren, sobald die Tests abgeschlossen sind. |
Sachbearbeiter | Der Architekt kann so konfiguriert werden, dass er vollen Zugriff auf alle Umgebungen hat, was bedeutet, dass nur der Architekt Lösungen in der Produktion bereitstellen kann. |
Geschäftsinhaber | Der Geschäftsinhaber kann so konfiguriert werden, dass er nur Lesezugriff auf alle Produktionsdaten hat, aber er kann nichts ändern oder bearbeiten. |
Diese Benutzerrollen können vollständig an Ihre Entwicklungsprozesse und die Art der Stakeholder angepasst werden.
Manchmal werden die Rollen sogar innerhalb einer Organisation verwendet, um z. B. die API-Entwicklung logisch von der Automatisierungsentwicklung zwischen zwei Teams zu trennen.
Rollenbasierte Benutzeroberfläche
Frends verfügt über ein fein abgestuftes Benutzerzugriffsverwaltungssystem, das auf benutzerdefinierten Rollen innerhalb der frends-Plattform basiert. Die Rollen werden dann dem Identitätsverwaltungssystem Ihrer Wahl zugeordnet, z. B. Azure AD.
Die Frends-Benutzeroberfläche wurde entwickelt, um das rollenbasierte Benutzerzugriffsmanagementsystem von Grund auf zu unterstützen. Das bedeutet, dass jede Aktion hinter einer Schaltfläche und jedes Datenelement in jeder Ansicht so konfiguriert werden kann, dass der Zugriff für eine bestimmte Rolle entweder zugelassen oder blockiert wird.
Zum Beispiel eine Rolle, die für einen Entwickler konfiguriert ist:
! [Frends Benutzerverwaltung und Rollen] (//images.ctfassets.net/y3eyw5ons608/2FWHGtKBH7aXkCSlcf850u/fd92356574c88904f4ff1b0f55577242/FRENDS_User_Management.PNG)
Benutzerrollen
Die Benutzerrollen, die in frends definiert sind, dienen in der Regel dazu, die Rechte eines authentifizierten Benutzers aus Sicherheitsgründen einzuschränken, aber auch ein DevOps-Modell mit dedizierten Rollen für z.B. Tester zu unterstützen und durchzusetzen.
Ein Kunde kann z.B. Rollen für folgende Benutzertypen konfigurieren:
Rolle | Erläuterung |
---|---|
Entwickler | Der Entwickler kann so konfiguriert werden, dass er nur Zugriff auf die Entwicklungsumgebung erhält und mit Privilegien Lösungen nur für die Testumgebung bereitstellen kann. |
Tester | Der Tester kann so konfiguriert werden, dass er nur Komponententests ausführen und Integrationen nur in der Testumgebung manuell ausführen darf. Zusätzlich kann dem Tester erlaubt werden, einen Integrationsprozess als "Genehmigt" zu markieren, sobald die Tests abgeschlossen sind. |
Sachbearbeiter | Der Architekt kann so konfiguriert werden, dass er vollen Zugriff auf alle Umgebungen hat, was bedeutet, dass nur der Architekt Lösungen in der Produktion bereitstellen kann. |
Geschäftsinhaber | Der Geschäftsinhaber kann so konfiguriert werden, dass er nur Lesezugriff auf alle Produktionsdaten hat, aber er kann nichts ändern oder bearbeiten. |
Diese Benutzerrollen können vollständig an Ihre Entwicklungsprozesse und die Art der Stakeholder angepasst werden.
Manchmal werden die Rollen sogar innerhalb einer Organisation verwendet, um z. B. die API-Entwicklung logisch von der Automatisierungsentwicklung zwischen zwei Teams zu trennen.