Konfiguration einer Client-Anwendung

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

Registrierung von Client-Anwendungen bei der Covata-Plattform
Folgende Aktionen für auf der Covata-Plattform registrierte Client-Anwendungen:
- Bearbeitung, z. B. Änderung der zulässigen Erteilungstypen einer Client-Anwendung, sowie
- Deaktivierung oder Reaktivierung, 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 Safe Share-Verwaltung an.
Klicken Sie auf die Option Client-Apps links auf der Oberfläche Safe Share-Verwaltung, 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.

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
Anwendungsname	Der Name der Client-Anwendung, den Covata-Benutzer sehen, wenn sie sich über die betreffende Client-Anwendung bei der Covata-Plattform authentifizieren wollen.
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 Safe Share-Administrator eine neue Client-Anwendung registriert, generiert die Covata-Plattform automatisch eine Client-ID auf der Basis eines Universally Unique Identifier (UUID). Der Safe Share-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 von Benutzern 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 Safe Share-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 Safe Share-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.
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. (Zugriffs-Token sind unter Erteilungstypen unten näher beschrieben.) 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).
Erteilungstypen	Die Erteilungstyp(en) (d. h. Erteilung(en) von Autorisierungen), 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 (die von einem Safe Share-Administrator oder Organisations-Administrator) konfiguriert werden können). Diese Ressourcen umfassen zum Beispiel: • 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, • Funktionen der Safe Share-Verwaltung, die für Benutzer mit der Safe Share-Administrator-Rolle verfügbar sind • Funktionen der Safe Share-Organisationsverwaltung, die für Benutzer mit der Organisations-Administrator-Rolle verfügbar sind • wird der Client-Anwendung von der Covata-Plattform ausgestellt, um der Client-Anwendung Zugriff auf die Ressourcen des Covata-Benutzers 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 Einzelheiten zum Erteilungstyp unten. • Implizit - am besten für Anwendungen auf Basis eines Benutzer-Agenten geeignet, die z. B. auf der Client-Seite in einem Webbrowser ausgeführt werden. Für weitere Informationen über diesen Erteilungstyp siehe die Tabelle Einzelheiten zum Erteilungstyp 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 Einzelheiten zum Erteilungstyp unten. Das Dialogfeld Client-Anwendung hinzufügen/bearbeiten zeigt im Abschnitt Erteilungstypen auch die folgenden Optionen. Während diese Optionen selbst keine OAuth 2.0-Erteilungstypen sind, unterstützen sie die (oben genannten) OAuth 2.0-Erteilungstypen: • Aktualisierungs-Token zulassen - legt fest, ob die Covata-Plattform der Client-Anwendung Aktualisierungs-Token ausstellen kann, mit denen die Client-Anwendung anschließend neue Zugriffs-Token anfordern kann. Dies ermöglicht es, die Sitzung eines Covata-Benutzers (potenziell unbegrenzt) fortzusetzen, ohne dass der Benutzer sich nach dem Ablauf seines Zugriffs-Token neu anmelden muss. Diese Option ist nur anwendbar wenn der Erteilungstyp Autorisierungscode und/oder Passwort (siehe oben) gewählt ist/sind. • Geräteregistrierung zulassen** - legt fest, ob die (auf einem spezifischen Gerät, d. h. meistens auf einer mobilen Plattform wie iOS oder Android ausgeführte) Client-Anwendung einen spezifischen Covata-Benutzer mit einer Kennung authentifizieren kann. Sobald sich ein Covata-Benutzer (anhand seiner E-Mail-Adresse und seines Passworts) über eine auf dem Gerät ausgeführte Client-Anwendung bei der Covata-Plattform authentifiziert, kann der Benutzer eine Kennung einrichten und für die Authentifizierung bei der Covata-Plattform verwenden (ohne dass die E-Mail-Adresse bzw. das Passwort als Anmeldeinformationen benötigt werden). Für maximale Sicherheit ist eine Kennung an einen spezifischen Covata-Benutzer und ein spezifisches Gerät gebunden. ** Im Kontext von Covata-Technologien stellt ein Erteilungstyp/eine Erteilung einer Autorisierung als Anmeldeinformation die Autorisierung eines Covata-Benutzers dar, auf die geschützten 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 der 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 „Account erstellt“, nachdem sein Account über die Organisationsverwaltung oder Safe Share-Verwaltung hinzugefügt wurde, oder das er selbst geändert hat). • Client-Anmeldeinformationen - aus der Client-ID und dem geheimen Client-Schlüssel bestehende Anmeldeinformationen
Gültigkeit des Aktualisierungs-Tokens	Die Zeit (in Sekunden), die ein von der Covata-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 ist nur anwendbar (und verfügbar), wenn die Option Aktualisierungs-Token zulassen (bei den Erteilungstypen siehe oben) aktiviert ist, die wiederum nur verfügbar ist, wenn auch die Erteilungstyp-Option(en) Autorisierungscode und/oder Passwort gewählt ist/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 ist nur anwendbar (und verfügbar), wenn für den Erteilungstyp die Option(en) Autorisierungscode und/oder Implizit (bei den Erteilungstypen siehe oben) aktiviert ist/sind, da sich Benutzer bei diesen Erteilungstypen direkt über eine Weboberfläche/einen von der Covata-Plattform bedienten Benutzer-Agenten 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.

Einzelheiten zum Erteilungstyp

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-Token des Benutzers (d. h. seine Sitzungen) zu beenden (dies geschieht über die Safe Share-Webanwendung, die Organisationsverwaltung oder Safe Share-Verwaltung). • 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-Anwendungweniger 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 Covataentwickelt 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.

Bearbeitung einer registrierten Client-Anwendung

Bearbeitung auf der Covata-Plattform registrierter Client-Anwendungen:

Melden Sie sich bei der Safe Share-Verwaltung an.
Klicken Sie auf die Option Client-Apps links auf der Oberfläche Safe Share-Verwaltung, 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 oben detailliert beschriebenen) Felder für die registrierte Client-Anwendung.
Klicken Sie auf Speichern, und die registrierte Client-Anwendung wird aktualisiert.

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 Safe Share-Verwaltung an.
Klicken Sie auf die Option Client-Apps links auf der Oberfläche Safe Share-Verwaltung, 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

Organisation administrator guide

Platform administrator guide

Compatibility mode user guide

Organisation administrator guide (Deutsch)

Platform administrator guide (Deutsch)

Web user guide (Deutsch)

Windows user guide (Deutsch)

Web user guide

Windows user guide

Registrierung einer neuen Client-Anwendung

Einzelheiten zum Erteilungstyp

Bearbeitung einer registrierten Client-Anwendung

Deaktivierung und Reaktivierung einer Client-Anwendung

Bitte hinterlassen Sie uns hier Ihr Feedback.

​Registrierung einer neuen Client-Anwendung

​Einzelheiten zum Erteilungstyp

​Bearbeitung einer registrierten Client-Anwendung

​Deaktivierung und Reaktivierung einer Client-Anwendung

​Bitte hinterlassen Sie uns hier Ihr Feedback.

Registrierung einer neuen Client-Anwendung

Einzelheiten zum Erteilungstyp

Bearbeitung einer registrierten Client-Anwendung

Deaktivierung und Reaktivierung einer Client-Anwendung

Bitte hinterlassen Sie uns hier Ihr Feedback.