Kann Awingu einen externen Identitätsanbieter wie Azure AD oder Okta verwenden?

Als Unified-Workplace-Lösung deckt Awingu viele Aspekte ab. Die Authentifizierung ist einer davon. Lassen Sie uns Awingu als Plattform betrachten, die eine Single-Sign-On-Authentifizierung für legacy-Systeme ermöglicht, anstatt Awingu als "Workspace"-Plattform zu betrachten.

Zunächst müssen wir einen Unterschied machen zwischen

A. Authentifizierung am Awingu-Arbeitsplatz

B. Authentifizierung bei Back-End-Diensten (z. B. ein Remote Desktop, eine legacy-Windows-Anwendung oder ein Dateiserver)

Zwei Phasen des Authentifizierungsprozesses

A. Authentifizierung bei Awingu

Awingu unterstützt viele Techniken zur Authentifizierung. Die heute am häufigsten verwendete ist immer noch die klassische Benutzername/Passwort' Anmeldung Verfahren (1). Die Anmeldeinformationen basieren auf Active Directory (oder LDAP). Awingu unterstützt auch viele Möglichkeiten, Multi-Faktor-Authentifizierung (MFA) hinzuzufügen. Awingu unterstützt von Haus aus sowohl Time-based password (TOTP) als auch Counter-based password (HOTP) als 2^und Faktor (d. h. Sie können native mobile Anwendungen wie Microsoft Authenticator und Google Authenticator verwenden, um ein sicheres Token zu erzeugen). Neben dem integrierten Flavor, Awingu unterstützt viele andere kommerzielle Plattformen.

Mit dem Aufkommen von SaaS-Diensten kam auch das Aufkommen von externen Identitätsanbietern (IdP). Ich denke dabei an Dienste wie Okta und Microsoft Azure AD. Ihr ursprüngliches Angebot konzentrierte sich auf die Zusammenführung der Logins für SaaS-Dienste, um Endbenutzern und Administratoren das Leben zu erleichtern. Von dort aus haben sie sich weiterentwickelt und auf andere Bereiche ausgedehnt. Awingu kann diese externen IDPs entweder in einem "Vor-Authentifizierungs"-Modus (ab Awingu 4.2) oder in einem "vollständigen Single-Sign-On"-Modus (ab Awingu 4.3) nutzen. Awingu unterstützt die Protokolle SAML und OpenID Connect (eine Weiterentwicklung von OAuth), um eine Vertrauensbasis mit dem gewählten IdP aufzubauen. Diese Standards werden von der großen Mehrheit der Anbieter unterstützt.

(2) Vor-Authentifizierung bedeutet, dass sich der Benutzer zunächst beim IdP authentifizieren und dann den Anmeldevorgang in Awingu abschließen muss. Der IdP ist zentral und hat einen vollständigen Überblick über alle Benutzeraktivitäten. Zusätzliche Dienste des IdP (z. B. MFA, Geo-Fencing, zeitlich eingeschränkter Zugang, ...) können ebenfalls genutzt werden.

(3) Vollständiges SSO bedeutet, dass sich der Benutzer nur beim IdP authentifizieren muss. Es ist kein weiterer Anmeldevorgang erforderlich. Auch in diesem Szenario können die IdP-Dienste genutzt werden.

In einigen Fällen werden Smartcard-basierte Plattformen verwendet. Diese sind zum Beispiel im Gesundheitswesen und in der Finanzbranche keine Seltenheit. Awingu kann auch einige dieser Szenarien unterstützen. Einige der Plattformanbieter unterstützen SAML oder OpenID Connect, andere - wie z. B. Imprivata - bieten auch die Speicherung von Anmeldedaten an.

B. Authentifizierung bei Anwendungen und Dateiservern

Okay, Sie haben sich also im Awingu-Arbeitsbereich authentifiziert. Nun möchten Sie auf die Anwendungen, Desktops und Dateiserver zugreifen, zu deren Nutzung Sie berechtigt sind.

Bei den Diensten unterstützt Awingu Folgendes:

• RDP-basierte Windows-Anwendungen und -Desktops. Hier wird Awingu Folgendes unterstützen
  • klassische Authentifizierung auf der Basis von Benutzernamen und Passwort
  • ein proprietäres PKI-Zertifikat-basiertes Authentifizierungsmodell (ab Awingu 4.3). Dies ist erforderlich, wenn "vollständiges SSO" mit einem externen IdP verwendet wird. In diesem Szenario verfügt Awingu nicht über den tatsächlichen Benutzernamen und das Kennwort, um damit zu arbeiten. Awingu "vertraut" dem IdP, wenn es einen bestimmten Benutzer als den besagten Benutzer authentifiziert (Achtung: es findet keine Identifizierung des Benutzers statt).
• SaaS-Dienste: Es gibt 2 Möglichkeiten, Endbenutzern ein SSO-Erlebnis für SaaS-Dienste innerhalb von Awingu zu bieten:
  • Verwenden Sie Awingu als IdP. Awingu verfügt über einen vordefinierten Satz von Konnektoren mit beliebten SaaS-Diensten wie Office 365, Google Apps und Salesforce. Wenn Sie diese Konnektoren verwenden, wird Awingu als externer IdP verwendet.
  • Verwendung eines externen IdP, in Kombination mit den Awingu-Authentifizierungsoptionen (2) und (3). In diesem Fall werden die SaaS-Dienste mit dem gewählten externen IdP verbunden, und die Links zu den SaaS-Diensten werden in Awingu ohne weitere Angaben veröffentlicht. Sobald sich der Endbenutzer in den Awingu-Arbeitsbereich einloggt, ist er gegenüber dem IdP und damit für seine SaaS-Dienste authentifiziert. Dieses Szenario erlaubt das Hinzufügen von viel mehr SaaS-Diensten im Vergleich zu Awingu als IdP.
• Intranet oder interne Webanwendungen: Awingu unterstützt hier die 'Basic Authentication'. Achtung, es erfordert eine Benutzername/Passwort-basierte Authentifizierung, funktioniert also nicht in Verbindung mit (3)
• Dateiserver: Awingu unterstützt CIFS und WebDAV (Basic Authentication) für die Verbindung zu Dateiservern ("SMB-Laufwerke"). Letzteres wird nicht unterstützt in Verbindung mit (3)

Zusammenfassender Überblick: Primäre Authentifizierungsoption mit Awingu

In der obigen Übersicht haben wir die netzbasierte Authentifizierung abstrahiert. In einigen Szenarien kann dies eine zusätzliche Anforderung sein. Auf dieser Ebene kann Awingu auch Kerberos- und NTLM-basierte Authentifizierung unterstützen.