Konfiguration von Client-Anwendungen

Integratoren können anhand der API der Covata-Plattform ihre eigenen Anwendungen entwickeln, um die leistungsstarken, datenzentrierten Sicherheitsfunktionen von Covata direkt nutzen zu können. Covata-Plattform-Administratoren können den Zugriff solcher Anwendungen ihrer Integratoren auf die Ressourcen der Covata-Plattform konfigurieren, indem sie diese Anwendungen bei ihrer Covata-Plattform-Instanz „registrieren“. Der Zugriff auf diese Ressourcen stützt sich auf das OAuth 2.0-Autorisierungs-Protokoll, das die Covata-Plattform für die Authentifizierung und Autorisierung verwendet. Aus der Perspektive der Covata-Plattform ist eine Anwendung eines Integrators eine Client-Anwendung, ungeachtet dessen, um welche der folgenden Arten von Anwendungen es sich handelt:

eine serverseitige Webanwendung,
eine als nativ für Mobilgeräte (z. B. Tablets oder Mobiltelefone) konzipierte Anwendung,
eine als nativ für andere Betriebssysteme (z. B. Desktop- oder Laptop-Computer) konzipierte Anwendung oder
eine Anwendung auf Basis eines Benutzer-Agenten (die z. B. auf Client-Seite in einem Webbrowser ausgeführt wird).

Client-Anwendungen können auf keine Ressourcen der Covata-Plattform zugreifen, solange sie nicht bei der Covata-Plattform registriert sind.

Konfiguration einer Client-Anwendung

Über die Seite Client-Anwendungen der Covata-Verwaltung (oben) können die folgenden Maßnahmen ausgeführt werden:

Registrierung von Client-Anwendungen bei der Covata-Plattform
Bearbeitung auf der Covata-Plattform registrierter Client-Anwendungen - z. B. Änderung der zulässigen Erteilungstypen einer Client-Anwendung
Deaktivierung oder Reaktivierung von registrierten Client-Anwendungen - z. B. um den Zugriff einer Client-Anwendung auf Ressourcen der Covata-Plattform zu blockieren (indem die betreffende Anwendung deaktiviert wird).

Registrierung einer neuen Client-Anwendung

Registrierung einer neuen Client-Anwendung bei der Covata-Plattform:

Melden Sie sich bei der Covata-Verwaltung an.
Klicken Sie auf die Option Client-Apps links auf der Covata-Verwaltung-Oberfläche, um die Seite Client-Anwendungen aufzurufen.
Klicken Sie auf die Schaltfläche Neue hinzufügen.
Füllen Sie im Dialogfeld Client-Anwendung hinzufügen die (in der Tabelle unten detailliert beschriebenen) Felder aus, um die Client-Anwendung zu registrieren.
Klicken Sie auf Speichern, und die neue Client-Anwendung erscheint als neue Eintragung auf der Seite Client-Anwendungen.

Bearbeitung einer registrierten Client-Anwendung

Bearbeitung auf der Covata-Plattform registrierter Client-Anwendungen:

Melden Sie sich bei der Covata-Verwaltung an.
Klicken Sie auf die Option Client-Apps links auf der Covata-Verwaltung-Oberfläche, um die Seite Client-Anwendungen aufzurufen.
Blättern Sie zur gewünschten Client-Anwendung (falls erforderlich) und klicken Sie auf den Link Bearbeiten.
Ändern Sie im Dialogfeld Client-Anwendung bearbeiten die (in der Tabelle unten detailliert beschriebenen) Felder für die registrierte Client-Anwendung.
Klicken Sie auf Speichern, und die registrierte Client-Anwendung wird aktualisiert.

Die folgende Tabelle beschreibt alle Pflichtfelder, die ausgefüllt werden müssen, um eine Anwendung bei der Covata-Plattform zu registrieren.

Die in der folgenden Tabelle enthaltenen Informationen können für Integratoren hilfreich sein, die anhand der API der Covata-Plattform Client-Anwendungen entwickeln.

Feld	Beschreibung
Client-ID	Der Wert „Client-ID/Client-Identifikator“ der Client-Anwendung. Dieser Wert bildet zusammen mit dem geheimen Client-Schlüssel (siehe unten) die „Client-Anmeldeinformationen“ der Anwendung, die für die OAuth 2.0-Authentifizierung und Autorisierung erforderlich sind, wenn sich ein Covata-Benutzer (mit seinen eigenen „Benutzer-Anmeldeinformationen“) bei der Covata-Plattform authentifiziert. Für weitere Informationen über diese Begriffe siehe die Definition für Erteilungstyp (unten). Wenn ein Covata-Plattform-Administrator eine neue Client-Anwendung registriert, generiert die Covata-Plattform automatisch eine Client-ID auf der Basis eines Universally Unique Identifier (UUID). Der Covata-Plattform-Administrator kann diesen Wert der Client-ID jedoch überschreiben. Hinweise:** Der Wert der Client-ID: • ist im Allgemeinen in die Client-Anwendung fest einprogrammiert, da er während der meisten OAuth 2.0-Authentifizierungs- und Autorisierungsabläufe an die Covata-Plattform weitergegeben wird. • muss in Beziehung auf alle bei der Covata-Plattform registrierten Client-Anwendungen eindeutig sein. Siehe die Abschnitte Client-Typen und Client-Identifikator der Spezifikation für das OAuth 2.0-Autorisierungs-Protokoll für weitere Informationen über Client-IDs und ihre Verwendung bei Client-Anwendungen. In dieser Spezifikation bezieht sich „Client“ auf eine Client-Anwendung und der „Autorisierungs-Server“ auf die Covata-Plattform.
Geheimer Client-Schlüssel	Der Wert „Geheimer Client-Schlüssel“ der Client-Anwendung. Dieser Wert bildet zusammen mit der Client-ID (siehe oben) die „Client-Anmeldeinformationen“ der Anwendung, die für die OAuth 2.0-Authentifizierung und Autorisierung erforderlich sind, wenn sich ein Covata-Benutzer (mit seinen eigenen „Benutzer-Anmeldeinformationen“) bei der Covata-Plattform authentifiziert. Für weitere Informationen über diese Begriffe siehe die Definition für Erteilungstyp (unten). Wenn ein Covata-Plattform-Administrator eine neue Client-Anwendung registriert, generiert die Covata-Plattform automatisch einen geheimen Client-Schlüssel auf der Basis eines Universally Unique Identifier (UUID). Der Covata-Plattform-Administrator kann diesen Wert des geheimen Client-Schlüssels jedoch überschreiben. Hinweise:** Wie der Wert der Client-ID ist auch der des geheimen Client-Schlüssels im Allgemeinen fest in die Client-Anwendung einprogrammiert, da er während der meisten OAuth 2.0-Authentifizierungs- und Autorisierungsabläufe an die Covata-Plattform weitergegeben wird. Eine Ausnahme bildet der implizite OAuth 2.0-Erteilungstyp, bei dem während der Benutzer-Authentifizierung und Autorisierung lediglich der Client-ID-Wert der Anmeldeinformationen der Anwendung an die Covata-Plattform weitergegeben wird. Siehe den Abschnitt Client-Typen und den Unterabschnitt Client-Passwort (in Client-Authentifizierung) der Spezifikation für das OAuth 2.0-Autorisierungs-Protokoll für weitere Informationen über geheime Client-Schlüssel und ihre Verwendung bei Client-Anwendungen. In dieser Spezifikation bezieht sich „Client“ auf eine Client-Anwendung und der „Autorisierungs-Server“ auf die Covata-Plattform.
Anwendungsname	Der Name der Client-Anwendung, den Covata-Benutzer sehen, wenn sie sich über die betreffende Client-Anwendung bei der Covata-Plattform authentifizieren wollen.
Erteilungstypen	Die Erteilung(en) von Autorisierungen (d. h. Erteilungstyp(en)), deren Nutzung die Covata-Plattform einer Client-Anwendung gestattet, um der Anwendung einen Zugriffs-Token auszustellen. Ein Zugriffs-Token: • definiert die Ressourcen, die einem authentifizierten Covata-Benutzer auf der Covata-Plattform (aufgrund seiner Rollen) zur Verfügung stehen. Dies sind im Allgemeinen beliebige sichere Objekte (d. h. verschlüsselte Dateien) oder Sammlungen (d. h. Ordner): • die Benutzer mit Ersteller-Rolle erstellt haben, wodurch der betreffende Benutzer der Besitzer des Elements wird, oder • auf die Benutzer mit Ersteller-, Mitwirkender- oder Ad-hoc-Rolle zugreifen können, weil der Besitzer ihnen das betreffende Element freigegeben hat, • wird der Client-Anwendung von der Covata-Plattform ausgestellt, um der Client-Anwendung Zugriff auf die Ressourcen des Covata-Benutzers (oder öffentliche Ressourcen) auf der Covata-Plattform zu geben, • hat eine begrenzte Lebensdauer. Sobald ein Zugriffs-Token abläuft, hat die Client-Anwendung keinen Zugriff auf die Ressourcen der Covata-Plattform mehr, bis der Benutzer sich bei der Covata-Plattform wieder authentifiziert oder ein Aktualisierungs-Token verwendet wird, um einen neuen Zugriffs-Token zu erhalten. Ein Aktualisierungs-Token kann einer Client-Anwendung von der Covata-Plattform anfänglich nach erfolgreicher OAuth 2.0-Authentifizierung und Autorisierung ausgestellt werden. Wenn der aktuelle Zugriffs-Token abläuft, tauscht die Client-Anwendung diesen Aktualisierungs-Token gegen einen neuen Zugriffs-Token der Covata-Plattform ein (ohne dass sich der Benutzer erneut authentifizieren muss). Die Covata-Plattform unterstützt die folgenden OAuth 2.0-Erteilungstypen, die unten vom sichersten bis zum wenigsten sicheren Typ (mit den verschiedenen Client-Anwendungen, die sich für die Implementierung der jeweiligen Erteilungstypen am besten eignen) aufgeführt sind: • Autorisierungscode - am besten für die folgenden Client-Anwendungen geeignet: • serverseitige Webanwendungen • native Desktop-/Laptop-Anwendungen oder Anwendungen für Mobilgeräte Für weitere Informationen über diesen Erteilungstyp siehe die Tabelle Erteilungstyp-Details unten. • Implizit - am besten für Anwendungen auf Basis eines Benutzer-Agenten geeignet, die z. B. auf Client-Seite in einem Webbrowser ausgeführt werden. Für weitere Informationen über diesen Erteilungstyp siehe die Tabelle Erteilungstyp-Details unten. • Passwort - am besten für die folgenden Client-Anwendungen geeignet: • native Desktop-/Laptop-Anwendungen oder Anwendungen für Mobilgeräte • von Administratoren/Systemen ausgeführte Services (z. B. geplante Jobs). Für weitere Informationen über diesen Erteilungstyp siehe die Tabelle Erteilungstyp-Details unten. Im Kontext der Covata-Technologien ist ein Erteilungstyp (bzw. eine Erteilung einer Autorisierung eine Anmeldeinformation, die die Autorisierung eines Covata-Benutzers darstellt, auf die gesicherten Ressourcen des betreffenden Benutzers auf der Covata-Plattform zuzugreifen. Diese Anmeldeinformation wird von der Client-Anwendung genutzt, um einen Zugriffs-Token zu erhalten. Die folgenden Konzepte bilden zentrale, für die Erlangung eines Erteilungstyps erforderliche Komponenten: • Anmeldeinformationen des Benutzers - aus einer E-Mail-Adresse und dem Passwort eines Covata-Benutzers bestehende Anmeldeinformationen (das Passwort erhält der Covata-Benutzer entweder in der ursprünglichen E-Mail-Benachrichtigung „Covata-Account erstellt“ oder hat der Benutzer selbst geändert) • Client-Anmeldeinformationen - aus der Client-ID und dem geheimen Client-Schlüssel bestehende Anmeldeinformationen
Gültigkeit des Zugriffs-Tokens	Die Zeit (in Sekunden), die ein von der Covata-Plattform für eine Client-Anwendung ausgestellter Zugriffs-Token gültig bleibt. Nach dem Ablauf des Zugriffs-Token müsste die Client-Anwendung: • entweder der Covata-Plattform einen gültigen Aktualisierungs-Token übermitteln, um einen neuen Zugriffs-Token zu erhalten, oder • vom Covata-Benutzer eine erneute Authentifizierung bei der Covata-Plattform (mit seinen Anmeldeinformationen) verlangen, um einen neuen Zugriffs-Token zu erhalten. Hinweis: Für maximale Sicherheit wird empfohlen, die Gültigkeit von Zugriffs-Token relativ kurz zu halten (mit Ablauf innerhalb weniger Minuten bis maximal einigen Stunden).
Gültigkeit des Aktualisierungs-Tokens	Die Zeit (in Sekunden), die ein von derCovata-Plattform für eine Client-Anwendung ausgestellter Aktualisierungs-Token gültig bleibt. Dieser Wert muss größer sein als der für die Gültigkeit des Zugriffs-Tokens. Läuft ein Aktualisierungs-Token ab, verlangt die Client-Anwendung, dass sich der Covata-Benutzer erneut authentifiziert, um die (dem betreffenden Benutzer verfügbaren) Ressourcen der Covata-Plattform weiterhin nutzen zu können. Hinweis: Dieses Feld wird nur von den Erteilungstypen Autorisierungscode und Passwort genutzt (die unten detaillierter beschrieben sind).
Eingetragene Weiterleitungs-URI(s)	Eine Liste einer oder mehrerer gültiger Uniform Resource Identifiers (URIs), die die Covata-Plattform nutzt, um den Wert des Parameters Weiterleitungs-URI (auch Weiterleitungs-Endpunkt) zu verifizieren, den die Client-Anwendung der Covata-Plattform (im Rahmen einer OAuth 2.0-Authentifizierung und einer Autorisierungsanfrage für einen Zugriffs-Token) schickt. Entspricht irgendein Teil der von der Client-Anwendung geschickten Weiterleitungs-URI (ab dem Beginn der betreffenden URI) keiner der registrierten, in diesem Feld angegebenen Weiterleitungs-URIs, beendet die Covata-Plattform den Vorgang der OAuth 2.0-Authentifizierung und Autorisierung. Hinweise: • Dieses Feld wird nur von den Erteilungstypen Autorisierungscode und Implizit genutzt (die unten detaillierter beschrieben sind), da sich Benutzer bei diesen Erteilungstypen direkt über eine(n) von der Covata-Plattform bereitgestellte(n) Weboberfläche/Benutzeragenten authentifizieren müssen. Die Covata-Plattform leitet den Benutzer-Agenten nach der Authentifizierung zur Weiterleitungs-URI/zum Weiterleitungs-Endpunkt der Client-Anwendung weiter. • Wenn die Client-Anwendung und die Covata-Plattform über das Internet kommunizieren und die Weiterleitungs-URI der Client-Anwendung (der die Covata-Plattform ihre Antwort mit dem Zugriffs-Token schickt) auf dem HTTP-Protokoll basiert, stellen Sie aus Sicherheitsgründen bitte Folgendes sicher: • Diese Weiterleitungs-URI muss für die Nutzung von HTTPS (nicht lediglich HTTP) konfiguriert sein. • Die in diesem Feld angegebenen, registrierten Weiterleitungs-URIs müssen den Präfix `https://` tragen, d. h. keine URIs in diesem Feld sollten den Präfix `http://` tragen.

Erteilungstyp-Details

Die folgende Tabelle beinhaltet Einzelheiten zu den OAuth 2.0-Erteilungstypen, deren Nutzung die Covata-Plattform Client-Anwendungen gestatten kann (d. h. über die der Anwendung Zugriffs-Token ausgestellt werden). Für eine Erläuterung der von der Covata-Plattform ausgestellten Zugriffs-Token siehe Erteilungstypen (oben). Die Angaben unten erläutern die verschiedenen Informationen, die zwischen der Client-Anwendung und der Covata-Plattform ausgetauscht werden, den Modus, über den dieser Austausch stattfindet, und damit die Auswirkungen auf die Sicherheit einer Implementierung dieser Erteilungstypen in einer Client-Anwendung.

Erteilungstyp	Details
Autorisierungscode	Der Erteilungstyp Autorisierungscode handhabt die sichere Übermittlung der Anmeldeinformationen des Benutzers und Clients sowie der Zugriffs- und Aktualisierungs-Token zwischen der Client-Anwendung und der Covata-Plattform. Die Covata-Plattform authentifiziert sowohl den Benutzer als auch die Client-Anwendung mit ihren jeweiligen Anmeldeinformationen. Benutzer-Anmeldeinformationen werden nie an die Client-Anwendung übergeben, da sich Benutzer direkt über eine von der Covata-Plattform bereitgestellte Weboberfläche authentifizieren. Von der Covata-Plattform (nach der erfolgreichen Authentifizierung des Benutzers) an die Client-Anwendung übermittelte Zugriffs-/Aktualisierungs-Token können dann von der Client-Anwendung eingesammelt werden. Dies schränkt die Fähigkeit des Covata-Benutzers ein, selbst auf Zugriffs-/Aktualisierungs-Token zuzugreifen. Dementsprechend gilt Folgendes: • Dies ist der sicherste (und daher empfohlene) OAuth 2.0-Erteilungstyp für die Implementierung in einer Client-Anwendung. • Der Erteilungstyp Autorisierungscode sollte in Client-Anwendungen implementiert werden, bei denen es sich um serverseitige Webanwendungen handelt, da diese Anwendungen ihren Quellcode (und daher ihre Client-Anmeldeinformationen) vertraulich halten können. Da die Vertraulichkeit von Client-Anmeldeinformationen von der Client-Anwendung selbst gewährleistet werden kann, werden diese Anwendungen als „vertrauliche Clients“ bezeichnet. • Dieser Erteilungstyp kann auch in „nativen“ Client-Anwendungen implementiert werden, z. B. mobilen oder Desktop-Anwendungen. Es wird jedoch davon ausgegangen, dass Client-Anmeldeinformationen bei diesen Anwendungen nicht sicher sind, sondern extrahiert werden können. Da die Vertraulichkeit von Client-Anmeldeinformationen von der Client-Anwendung nicht selbst gewährleistet werden kann, werden diese Anwendungen als „öffentliche Clients“ bezeichnet. Hinweis: Es wird aus dem folgenden Grund nicht empfohlen, in nativen Anwendungen auf Client-Anmeldeinformationen als Sicherheitsmaßnahme zu vertrauen: • Da eine native Client-Anwendung ein „öffentlicher Client“ ist, kann die Covata-Plattform die Authentizität der echten Client-Anwendung anhand der Anmeldeinformationen nicht verifizieren, wenn die Client-Anmeldeinformationen der Anwendung extrahiert und in einer nicht autorisierten Client-Anwendung implementiert werden. Wenn die Anmeldeinformationen eines Covata-Benutzers (der auf die echte Client-Anwendung zugreift) auf anderen Wegen (z. B. Phishing) beschafft und dann verwendet werden, um sich über die nicht autorisierte Client-Anwendung bei der Covata-Plattform zu authentifizieren, könnte die nicht autorisierte Anwendung Zugriff auf die (dem betreffenden Benutzer verfügbaren) Ressourcen der Covata-Plattform erhalten. Verlässt sich ein Integrator für die Sicherheit der nativen Anwendung auf Client-Anmeldeinformationen (was nicht empfohlen wird) und kommt der Verdacht auf, dass diese Anmeldeinformationen gestohlen wurden, müsste, um diese Sicherheitsverletzung unverzüglich zu beheben, die Client-Anwendung des Integrators deaktiviert werden, um alle nicht autorisierten Client-Anwendungen (in denen diese gestohlenen Client-Anmeldeinformationen implementiert sind) am Zugriff auf die Covata-Plattform zu hindern. Leider sperrt diese Maßnahme auch alle echten Installationen von Client-Anwendungen. Die Client-Anwendung kann daher nach einer Rekonfiguration der registrierten Client-Anwendung mit neuen Client-Anmeldeinformationen (sowie nach einem Rebuild und Roll-out einer neuen Version der echten Client-Anwendung mit den neuen Client-Anmeldeinformationen) auf der Covata-Plattform reaktiviert werden.
Implizit	Der implizite Erteilungstyp handhabt die sichere Übermittlung der Anmeldeinformationen des Benutzers zwischen der Client-Anwendung und der Covata-Plattform. Die Covata-Plattform authentifiziert den Benutzer mit seinen Anmeldeinformationen. Als Teil des OAuth 2.0-Protokolls wird die Client-Anwendung jedoch bei diesem Erteilungstyp nicht authentifiziert; die Covata-Plattform verifiziert lediglich die Identität der Client-Anwendung anhand der Client-ID. Während die Benutzer-Anmeldeinformationen nie an die Client-Anwendung übergeben werden, da sich Benutzer direkt über eine von der Covata-Plattform bereitgestellte Weboberfläche authentifizieren, wird der Zugriffs-Token (im Gegensatz zum Erteilungstyp Autorisierungscode) von der Covata-Plattform in einem URI-Fragment direkt an die Client-Anwendung übermittelt. Dementsprechend gilt Folgendes: • Dieser OAuth 2.0-Erteilungstyp ist bei der Implementierung in einer Client-Anwendung aus den folgenden Gründen weniger sicher (als der Autorisierungscode oben): • Da die Covata-Plattform die Client-Anwendung nicht authentifiziert, kann die Covata-Plattform die Authentizität der Client-Anwendung nicht verifizieren. • Da der Zugriffs-Token im von der Covata-Plattform übermittelten URI-Fragment verfügbar ist, kann der Zugriffs-Token unbefugten Parteien zur böswilligen Nutzung übergeben werden, u. a. für eine Attacke über einen authentifizierten Covata-Benutzer (z. B. durch Phishing). In diesen Fällen ist es möglich die Zugriffs-/Aktualisierungs-Token des Benutzers (d. h. seine Sitzungen) ablaufen zu lassen. • Aufgrund des diesem Erteilungstyp inhärenten Risikos, dass Zugriffs-Token unbefugten Parteien übergeben werden können, werden bei Verwendung des impliziten Erteilungstyps keine Aktualisierungs-Token ausgestellt. • Der implizite Erteilungstyp wird im Allgemeinen von Client-Anwendungen implementiert, die „auf Basis eines Benutzer-Agenten wie z. B. Webbrowser-Anwendungen ausgeführt werden, bei denen ausführbarer Code heruntergeladen und im Browser selbst ausgeführt wird (statt auf einem Server), da die Client-Anmeldeinformationen dem Covata-Benutzer zur Verfügung stehen. Die Implementierung des impliziten Erteilungstyps in einer Webbrowser-Anwendung kann die nahtlose Integration der Covata-Benutzer-Authentifizierung und Autorisierung über OAuth 2.0 bei gleichzeitiger Sicherung der Benutzer-Anmeldeinformationen ermöglichen.
Passwort	Der Erteilungstyp Passwort delegiert die Handhabung der Benutzer-Anmeldeinformationen an die Client-Anwendung selbst. Sowohl die Benutzer- als auch die Client-Anmeldeinformationen werden der Covata-Plattform von der Client-Anwendung zur Authentifizierung übermittelt. Von der Covata-Plattform (nach der erfolgreichen Authentifizierung des Benutzers) an die Client-Anwendung übermittelte Zugriffs-/Aktualisierungs-Token können dann von der Client-Anwendung eingesammelt werden. Dies schränkt die Fähigkeit des Covata-Benutzers ein, selbst auf Zugriffs-/Aktualisierungs-Token zuzugreifen. Beachten Sie hierbei Folgendes: • Dieser OAuth 2.0-Erteilungstyp ist bei der Implementierung in einer Client-Anwendung weniger sicher (als der Erteilungstyp Autorisierungscode und der implizite Erteilungstyp oben), weil die delegierte Handhabung der Benutzer-Anmeldeinformationen in der Client-Anwendung das Risiko erhöht, dass diese Anmeldeinformationen unbefugten Parteien für eine etwaige böswillige Nutzung übergeben werden. Das Risiko einer Übergabe von Benutzer-Anmeldeinformationen an die Client-Anwendung wird durch die Tatsache minimiert, dass diese Anmeldeinformationen nur einmal (für nur eine Anfrage der Client-Anwendung) verwendet und gegen einen Zugriffs-Token eingetauscht werden müssen. Da dieser Erteilungstyp Aktualisierungs-Token für neue Zugriffs-Token ausstellen kann (was empfohlen wird), brauchen die Client-Anwendungen keine Benutzer-Anmeldeinformationen zu speichern. • Der Erteilungstyp Passwort sollte nur von nativen Client-Anwendungen implementiert werden (d. h. mobilen oder Desktop-Anwendungen), wo von hohem Vertrauen zwischen dem Covata-Benutzer und der Client-Anwendung selbst ausgegangen werden kann. Dies sind Client-Anwendungen, die: • Teil des Betriebssystems bilden, auf dem sie ausgeführt werden (d. h. die von derselben Organisation oder Gruppe entwickelt wurden wie das Betriebssystem, auf dem sie ausgeführt werden), • mit einem hohen Level an Privilegien ausgeführt werden oder • von Covata entwickelt wurden. Sofern die Client-Anwendung dieses Vertrauenskriterium erfüllt, könnte der Erteilungstyp Passwort auch in Client-Anwendungen implementiert werden, für die der sicherere Erteilungstyp Autorisierungscode weder verfügbar noch geeignet ist.

Deaktivierung und Reaktivierung einer Client-Anwendung

Die Deaktivierung einer registrierten Client-Anwendung verhindert, dass jegliche Installationen der Client-Anwendung auf die Covata-Plattform zugreifen können. Dies ist hilfreich, wenn der Zugriff einer Client-Anwendung auf die Covata-Plattform (vorübergehend oder permanent) deaktiviert werden muss oder wenn Verdacht besteht, dass die Anmeldeinformationen der Client-Anwendung gestohlen wurden. Deaktivierung, Aktivierung und Reaktivierung auf der Covata-Plattform registrierter Client-Anwendungen:

Melden Sie sich bei der Covata-Verwaltung an.
Klicken Sie auf die Option Client-Apps links auf der Covata-Verwaltung-Oberfläche, um die Seite Client-Anwendungen aufzurufen.
Gehen Sie anschließend wie folgt vor:
- Zur Deaktivierung der Client-Anwendung - klicken Sie auf die grüne Schaltfläche Aktiviert (in der Spalte Status rechts), sodass diese Schaltfläche auf rot wechselt und als Deaktiviert angezeigt wird.
- Zur Aktivierung oder Reaktivierung der Client-Anwendung - klicken Sie auf die rote Schaltfläche Deaktiviert (in der Spalte Status rechts), sodass die Schaltfläche auf grün wechselt und als Aktiviert angezeigt wird.

Eine Client-Anwendung kann auch bearbeitet werden, wenn sie deaktiviert ist. Diese Funktion ermöglicht es, registrierte Client-Anwendungen zu konfigurieren, ehe ihr Zugriff auf die Covata-Plattform aktiviert wird.

Administrator guide

Compatibility mode user guide

Administrator guide (Deutsch)

Web user guide (Deutsch)

Windows user guide (Deutsch)

Web user guide

Windows user guide

Konfiguration einer Client-Anwendung

Registrierung einer neuen Client-Anwendung

Bearbeitung einer registrierten Client-Anwendung

Erteilungstyp-Details

Deaktivierung und Reaktivierung einer Client-Anwendung

Bitte hinterlassen Sie uns hier Ihr Feedback.

​Konfiguration einer Client-Anwendung

​Registrierung einer neuen Client-Anwendung

​Bearbeitung einer registrierten Client-Anwendung

​Erteilungstyp-Details

​Deaktivierung und Reaktivierung einer Client-Anwendung

​Bitte hinterlassen Sie uns hier Ihr Feedback.

Konfiguration einer Client-Anwendung

Registrierung einer neuen Client-Anwendung

Bearbeitung einer registrierten Client-Anwendung

Erteilungstyp-Details

Deaktivierung und Reaktivierung einer Client-Anwendung

Bitte hinterlassen Sie uns hier Ihr Feedback.