Grundlagen der Authentifizierung und Autorisierung

Authentifizierung und Autorisierung spielen in den meisten Anwendungssuites eine wichtige Rolle. Diese Seite bietet einen allgemeinen Überblick über die Konzepte und die Terminologie. Es ist hilfreich, wenn Sie neu auf dem Gebiet sind oder wenn Sie Ihr Wissen auffrischen möchten. Wenn Sie Ihr allgemeines Verständnis gefestigt haben, können Sie damit fortfahren, zu lernen, wie Authentifizierung und Autorisierung in CXone funktionieren.

Wenn sich Benutzer bei einer beliebigen Anwendungssuite, einschließlich CXone, anmelden, erfolgen diese beiden Schritte normalerweise in der angegebenen Reihenfolge:

• Authentifizierung - Ist der Benutzer derjenige, der er vorgibt zu sein?
• Autorisierung - Soll der authentifizierte Benutzer den angeforderten Zugriff erhalten?

Alle Benutzer müssen authentifiziert und autorisiert werden, bevor sie auf CXone zugreifen können.

Vom Standpunkt des Benutzers aus gesehen, meldet er sich einfach an. Die Authentifizierung und Autorisierung erfolgt hinter den Kulissen, damit die Anmeldung erfolgreich ist. Zu Beginn einer Anmeldung sind die Benutzer nicht authentifiziert. Das bedeutet, dass das System ihre Identität nicht kennt. Am Ende des Anmeldevorgangs sind beide authentifiziert und autorisiert. Das bedeutet, dass das System weiß, wer sie sind und welchen Zugang sie haben sollten.

Ein System tut Folgendes, um Benutzer zu authentifizieren und zu autorisieren:

1. Legt fest, welcher Authentifizierungsprozess verwendet werden soll, wenn mehr als einer unterstützt wird. Viele Systeme unterstützen mehrere Methoden. So können Systeme beispielsweise Benutzer mit einem Benutzernamen und einem Passwort, über eine einmalige Anmeldung oder über eine Multi-Faktor-Authentifizierung (MFA) identifizieren. In der Regel wählen die Benutzer auf der Anmeldeseite aus einer Liste von Authentifizierungsoptionen aus, aber die Systeme können bei Bedarf einen bestimmten Prozess verlangen.

2. Erfasst die Authentifizierungsdaten (z. B. durch Abfrage des Benutzernamens und des Passworts).

3. Verifiziert Anmeldeinformationen mithilfe eines Identitätsanbieters. Ein Identitätsanbieter ist ein separates System, das Informationen über Benutzer und ihre Identität, einschließlich ihrer Anmeldedaten, verwaltet.

4. Autorisiert die authentifizierte Person oder das Programm. Sobald die Benutzer authentifiziert sind, verwendet das System einen Autorisierungsserver, um dem Benutzer Zugang zu gewähren. Das System gewährt dem Benutzer je nach seiner Rolle und seinen Berechtigungen Zugang. Das System gewährt dem Benutzer nur Zugriff auf die Funktionen, die er sehen oder nutzen darf.

Terminologie im Zusammenhang mit der Authentifizierung

Identitätsanbieter

Identitätsanbieter (IdPs) sind Systeme, die die Identität eines Benutzers feststellen. Folgendes ist möglich:

• Intern - Teil des Systems, bei dem sich der Benutzer anmeldet. Ein Benutzer, der sich beispielsweise bei Facebook anmeldet, verwendet den Facebook IdP, um sich bei der Facebook-Anwendung zu authentifizieren.
• Extern - Unabhängig von dem System, bei dem sich der Benutzer anmeldet. Ein Beispiel: Ein Benutzer meldet sich bei einer Smartphone-App über die Facebook-IdP-Authentifizierung an.

IdPs können entweder gehostet oder cloudbasiert sein. Microsoft ADFS und Shibboleth sind gängige gehostete IdPs. Microsoft Azure AD, Okta und Ping sind nur einige der vielen Cloud-IdPs.

Authentifizierungsprotokolle

Authentifizierungsprotokolle stellen die Kommunikation zwischen Anwendungen und IdPs bzw. zwischen verschiedenen IdPs her. OpenID Connect und SAML 2.0 sind Beispiele für Authentifizierungsprotokolle. Einige Authentifizierungsprotokolle bieten zusätzliche Funktionen, wie z. B. Verschlüsselung, aber Anwendungen können diese Funktionen nutzen oder auch nicht. Wenn ein System einen integrierten IdP verwendet, spielen Authentifizierungsprotokolle keine Rolle.

Ablauf der Authentifizierung

Die meisten externen IdPs unterstützen einen oder beide der folgenden Abläufe für den Authentifizierungsprozess:

• SP-initiiert: Die Authentifizierung wird vom Dienstanbieter oder der Anwendung initiiert. Der Benutzer gibt seine Anmeldedaten ein und die Anwendung kontaktiert einen externen IdP zur Identitätsprüfung. Dies ist der häufigste Fluss.
• IdP-initiiert: Der Benutzer meldet sich zuerst beim IdP an, und der IdP startet dann die Anwendungen, nachdem er den Benutzer verifiziert hat.

Identitätsverbund-Management

Federated Identity Management wird manchmal auch als FIM oder Föderation bezeichnet. Es ist ein Überbegriff für den Prozess der Verwendung eines einzigen externen IdP zur Authentifizierung für eine oder mehrere Anwendungen. Die Föderation ist in der Regel in irgendeiner Weise zeitlich begrenzt. Ein Benutzer kann sich zum Beispiel einmal zu Beginn seiner Arbeit anmelden. Dadurch werden sie bei allen Anwendungen, die sie täglich nutzen, authentifiziert. Allerdings müssten sie sich am nächsten Tag erneut anmelden, um sich zu authentifizieren, auch wenn sie sich am Vortag nicht abgemeldet haben.

Single Sign-On

Single Sign-On (SSO) wird verwendet, um den Zugriff auf mehrere Anwendungen oder Systeme mit einer einzigen Anmeldung zu ermöglichen. Ein Beispiel: Ein Benutzer meldet sich bei Microsoft 365 an und erhält Zugriff auf alle Microsoft-Anwendungen, die sein Unternehmen für ihn autorisiert hat. Manchmal wird der Begriff SSO für Federation verwendet, obwohl die beiden Konzepte nicht genau dasselbe sind.

Mehrstufige Authentifizierung

Die Multi-Faktor-Authentifizierung (MFA) fügt der grundlegenden Authentifizierung mit Benutzername und Passwort eine weitere Sicherheitsebene hinzu. Bei MFA muss der Benutzer einen Code eingeben, eine Frage beantworten oder ein Token verwenden, bevor der IdP seine Identität als überprüft ansieht.

Vertrauen

Bei der Authentifizierung bezieht sich das Vertrauen auf Informationen oder Wissen, die von einer Anwendung oder einem System und einem externen IdP gemeinsam genutzt werden. Dieses Wissen stellt eine Beziehung zwischen den beiden her, so dass jeder weiß, dass er sich auf eine genaue und wahrheitsgemäße Kommunikation des anderen verlassen kann. Wie das Vertrauen hergestellt wird, hängt vom jeweiligen Authentifizierungsprotokoll ab. Die folgenden Beispiele basieren auf OpenID Connect und SAML 2.0.

OpenID Connect

Das Vertrauen in OpenID Connect beruht auf dem Emittenten. Ein Emittent ist ein Wert, der wie eine URL aussieht. Sie legt Ihren Identitätsanbieter fest. Google unterstützt zum Beispiel OpenID Connect und der Emittent ist https://accounts.google.com.

Je nach Emittent gibt es mehrere zusätzliche Konfigurationspunkte. So wird beispielsweise bei OpenID Connect das Vertrauen durch die Unterzeichnung von öffentlichen/privaten Zertifikaten hergestellt. Es verwendet einen Industriestandard namens JWKS. Daher bestimmt ein Teil der Konfiguration, wie diese öffentlichen Zertifikate erhalten werden.

Die meisten Identitätsanbieter unterstützen die Ermittlung dieser Informationen durch Anhängen von /.well-known/openid-configuration an den Issuer. Das Google-Discovery-Dokument finden Sie unter https://accounts.google.com/.well-known/openid-configuration.

SAML 2.0

In SAML 2.0 basiert das Vertrauen auf einem Entitätsidentifikator. Im Gegensatz zu OpenID Connect gibt es keine enge Beziehung zwischen dem Entitätsbezeichner und anderen Konfigurationswerten. Es gibt mehrere Konfigurationsparameter, die verwendet werden, um Vertrauen mit SAML 2.0 aufzubauen:

• Entity Identifier - Wert, der von der Anwendung oder dem System festgelegt wird, um seine Identität zu verifizieren

• Endpunkt-URL-Wert, der vom externen IdP festgelegt wird, an dem er Authentifizierungsanfragen empfängt

• Assertion URL - Wert, der von der Anwendung oder dem System bestimmt wird, an das der externe IdP Authentifizierungsantworten sendet

• Zertifikat - wird vom externen IdP verwendet, um die Antwort zu signieren