Wenn Sie die benutzerdefinierte Authentifizierung einrichten, können Sie den Authentifizierungsprozess genauer steuern und den Anmeldevorgang in AEM Mobile-Apps anpassen. Bei der benutzerdefinierten Authentifizierung erscheint der Anmeldebildschirm der App als Vollbild-Webansicht, die Sie selbst gestalten.

Benutzerdefinierte Anmeldung

Die folgenden Formate werden unterstützt:

  • SAML 2.0, einschließlich Unterstützung für MFA/OKTA und Gigya
  • OAuth 2.0, einschließlich Social Sharing-Anmeldung, z. B. über Facebook oder Gmail
  • Allgemein, wobei Sie das Anmeldeverhalten selbst gestalten und mit Ihrem Berechtigungsdienst verbinden können.

Beispielsweise können Sie Ihren Vertriebsmitarbeitern gestatten, sich über die OKTA-Verifizierung (SAML 2.0) mit ihrer E-Mail-Adresse und ihrem Kennwort bei der App anzumelden. Sie können auch Kunden ermöglichen, sich mit ihrem Gmail- oder Facebook-Konto (OAuth 2.0) anzumelden. Die App erhält von diesen Identitätsanbietern Autorisierungstokens, mit denen Sie Benutzer über Ihren Berechtigungsdienst für den Zugriff auf Inhalte autorisieren können. Mithilfe der setAuthToken-API können Sie verschiedene Authentifizierungsmethoden anbieten, sogar mehrere gleichrangige Authentifizierungswege innerhalb einer App.

Zwei alternative Anwendungsfälle kommen bei der Authentifizierung über allgemeine Identitätsanbieter in Betracht:

  • Bereitstellen einer eigenen Benutzeroberfläche, z. B. ein HTML-Formular anstelle der üblichen Eingabeaufforderung für den Benutzernamen und das Kennwort
  • Erstellen einer Anmeldeerfahrung, die über einen Artikel aufgerufen wird und die Standardauthentifizierung ersetzt

 

Hinweis: Bei einem Berechtigungsdienst, für den Direct Entitlement APIs der Version 2 verwendet werden, ist trotzdem eine Autorisierung von Benutzern erforderlich, damit diese auf Inhalte zugreifen können.

Sie können über APIs feststellen, ob der Benutzer authentifiziert ist, das Authentifizierungstoken abrufen sowie die Webansicht mit der Oberfläche für die Anmeldung aufrufen. Siehe Verwenden von AEM Mobile-spezifischen Cordova-kompatiblen Zusatzmodulen.

 

Video zur benutzerdefinierten Authentifizierung

Video zur benutzerdefinierten Authentifizierung
Einführungsvideo zur benutzerdefinierten Authentifizierung

Benutzerdefinierte Authentifizierung einrichten

Identitätsanbieter werden in den Haupteinstellungen eingerichtet und in den Projekteinstellungen einem Projekt zugewiesen. Auf Hauptkontoebene können Sie verschiedene Identitätsanbieter für die Verwendung in Projekten erstellen.

  1. Richten Sie einen Berechtigungsdienst für die Verwendung in AEM Mobile ein.

    Bei einem Berechtigungsdienst mit Direct Entitlement APIs der Version 2 müssen Benutzer auch dann für den Zugriff auf Inhalte autorisiert werden, wenn Sie einen benutzerdefinierten Authentifizierungsdienst aktiviert haben. Siehe Berechtigungen in AEM Mobile-Apps.

  2. Richten Sie einen Identitätsanbieter mit SAML 2.0 bzw. OAuth 2.0 oder einen allgemeinen Identitätsanbieter für die Verwendung mit AEM Mobile und Ihrem Berechtigungsdienst ein.

    Google-Identitätsanbieter

    In dieser PDF-Datei wird als Beispiel das Einrichten eines Google-Identitätsanbieters beschrieben (nur auf Englisch):  

    Herunterladen

    Facebook-Identitätsanbieter

    In dieser PDF-Datei wird als Beispiel das Einrichten eines Facebook-Identitätsanbieters beschrieben (nur auf Englisch):

    Herunterladen

    Allgemeiner Identitätsanbieter

    Ein Beispiel für das Einrichten eines allgemeinen Identitätsanbieters finden Sie hier (nur auf Englisch):

    Herunterladen

    Eine Video zu allgemeinen Identitätsanbietern finden Sie unter Video zum allgemeinen IdP (nur auf Englisch).

    Gigya

    Sie können Gigya Customer Identity Management als Identitätsanbieter verwenden, mit dem Kunden sich auf herkömmliche Weise oder über Social Media wie Facebook, Google oder LinkedIn anmelden können. Ein Beispiel für das Einrichten eines Gigya-Identitätsanbieters finden Sie hier (nur auf Englisch):

    Herunterladen

    Weitere Informationen finden Sie in diesem Artikel zu AEM Mobile in der Gigya-Dokumentation.

     

    Hinweis:

    Der Ablauf der Gigya-Authentifizierung beruht auf den Cookies, die im Browser des Benutzers gespeichert werden. Die Gigya-Authentifizierung kann in AEM Mobile-Apps fehlschlagen, wenn die App diese Cookies als Cookies von Drittanbietern erkennt und blockiert. Wenn blockierte Cookies von Drittanbietern die ordnungsgemäße Ausführung der Gigya-Authentifizierung verhindern, können Sie eine Lösung implementieren, die in der Gigya-Dokumentation beschrieben ist: Blocked Third-Party Cookies (auf Englisch).

     

    Im Beispielcode für den Berechtigungsdienst wird auch die benutzerdefinierte Authentifizierung unterstützt. Weitere Informationen finden Sie unter Einrichten eines Berechtigungsdiensts.

  3. Melden Sie sich mit einem Hauptadministrator-Konto beim On-Demand-Portal an. Klicken Sie auf „Haupteinstellungen“ und dann auf die Registerkarte „Identitätsanbieter“.

  4. Klicken Sie auf das Symbol „Identitätsanbieter erstellen“ (+) und legen Sie dann den Namen des Identitätsanbieters sowie den Typ („OAuth 2.0“, „SAML 2.0“ oder „Allgemein“) fest.

  5. Geben Sie die Informationen für den Identitätsanbieter an. Beschreibungen der Optionen finden Sie weiter unten in diesem Dokument.

  6. Damit die Verbindung zwischen dem Identitätsanbieter und Ihrer AEM Mobile-App als vertrauenswürdig gilt, kopieren Sie den Wert für den Experience Manager Mobile-Antwortendpunkt (SAML 2.0) oder den Experience Manager Mobile-Weiterleitungsendpunkt (OAuth 2.0) und fügen diesen der Konfiguration für den Identitätsanbieter hinzu.

    Anhand dieser Informationen erkennt der Dienst, wie das Ergebnis des Authentifizierungsvorgangs an AEM Mobile übermittelt werden soll. Beispielsweise unterscheidet sich das von Facebook für einen bestimmten Benutzer zurückgegebene Authentifizierungstoken vom Token Ihres Berechtigungsdiensts. In Ihrem Berechtigungsdienst muss das Facebook-Authentifizierungstoken dem Benutzer zugeordnet werden, damit der Berechtigungsdienst ordnungsgemäß antworten kann, wenn AEM Mobile Berechtigungen abruft. Der Benutzer wird dann bei der Anmeldung für die Anzeige von Inhalten autorisiert.

  7. Rufen Sie im On-Demand-Portal die Projekteinstellungen auf, bearbeiten Sie das Projekt und klicken Sie auf die Registerkarte „Zugriff“. Wählen Sie „Benutzerdefinierte Authentifizierung aktivieren“ und dann den entsprechenden Identitätsanbieter, den Sie in den Haupteinstellungen erstellt haben.

  8. Erstellen Sie eine Nicht-Preflight-App und testen Sie die Einrichtung der benutzerdefinierten Authentifizierung.

SAML 2.0-Einstellungen

Dienstanbieter-ID: Der Wert wird von AEM Mobile verwendet, um sich beim Senden einer Authentifizierungsanfrage an den Identitätsanbieter selbst zu identifizieren. Die Dienstanbieter-ID muss beim Identitätsanbieter registriert sein.

Protokollbindung: Definiert die SAML-Protokollbindung, die zum Senden der Authentifizierungsanfrage an den Identitätsanbieter verwendet wird. Als Protokollbindung werden „POST“ und „REDIRECT“ unterstützt.

NameID-Format: Wenn festgelegt, wird vom AEM Mobile-Berechtigungsdienst gefordert, dass der Themenbezeichner der Antwort das angegebene Format „Ohne“, „Dauerhaft“, „Temporär“ oder „Keine Angabe“ verwendet. Für Gigya-Identitätsanbieter verwenden Sie „Keine Angabe“.

Authentifizierungstokenquelle: Gibt an, welcher Teil der Authentifizierungsantwort das Authentifizierungstoken enthält. Wenn Sie „Attribut“ verwenden, legen Sie den Namen des Attributs in der Authentifizierungsantwort fest, das das Authentifizierungstoken enthält. Wenn Sie das NameID-Format auf „Temporär“ festgelegt ist, können Sie NameID wählen.

Authentifizierungs-URL: Die Identitätsanbieter-URL, an die AEM Mobile die Authentifizierungsanfrage senden soll.

Zertifikat für den öffentlichen Signaturschlüssel: Das X509-Zertifikat des öffentlichen Signaturschlüssels des Identitätsanbieters, mit dem die Zusicherungssignatur in AEM Mobile bestätigt wird.

Standardsitzungsablauf: Die Gültigkeitsdauer einer Antwort auf eine erfolgreiche Anmeldung in Sekunden, sofern die Dauer in der Antwort auf die Anmeldeanfrage nicht ausdrücklich angegeben ist. Nach Ablauf der Sitzung wird diese aktualisiert, wenn dies vom Identitätsanbieter unterstützt wird. Andernfalls wird der Benutzer abgemeldet. Der Standardwert ist 3600 Sekunden (eine Stunde).

Experience Manager Mobile-Antwortendpunkt: Die URL, an die der Identitätsanbieter die Zusicherungsantwort senden soll. In der Konfiguration des Identitätsanbieters muss dieser von AEM Mobile bereitgestellte Wert verwendet werden.

Zertifikat für den öffentlichen Experience Manager Mobile-Verschlüsselungsschlüssel: Das X509-Zertifikat des öffentlichen Verschlüsselungsschlüssels, das vom Identitätsanbieter verwendet wird, um den Schlüssel in der Authentifizierungsantwort bei Bedarf zu verschlüsseln.

OAuth 2.0-Einstellungen

Erteilungstyp für die Autorisierung: Bestimmt den Typ der Autorisierungserteilung: „Autorisierungscode“ oder „Implizit“.

Tokenendpunkt: Wird von AEM Mobile verwendet, um einen Autorisierungscode oder ein Aktualisierungstoken gegen ein Zugriffstoken auszutauschen. HTTPS wird dringend empfohlen.

Geheimer Clientschlüssel: AEM Mobile verwendet diesen Wert, um sich bei der Kommunikation mit dem Tokenendpunkt selbst zu authentifizieren. Der von Ihnen festgelegte geheime Clientschlüssel muss beim Identitätsanbieter registriert sein.

Standardsitzungsablauf: Die Gültigkeitsdauer einer Antwort auf eine erfolgreiche Anmeldung in Sekunden, sofern die Dauer in der Antwort auf die Anmeldeanfrage nicht ausdrücklich angegeben ist. Nach Ablauf der Sitzung wird diese aktualisiert, wenn dies vom Identitätsanbieter unterstützt wird. Andernfalls wird der Benutzer abgemeldet. Der Standardwert ist 3600 Sekunden (eine Stunde).

Autorisierungsendpunkt: Wird von AEM Mobile verwendet, um eine Autorisierung beim Identitätsanbieter abzurufen. HTTPS wird dringend empfohlen.

Client-ID: AEM Mobile verwendet diesen Wert, um sich bei der Kommunikation mit dem Identitätsanbieter selbst zu identifizieren. Die Client-ID muss beim Identitätsanbieter registriert sein.

Zugriffstoken-Gültigkeitsbereich: Beschreibt den Gültigkeitsbereich der Zugriffsanfrage. Verwenden Sie Leerzeichen, um mehrere Werte anzugeben. Beispiele für Facebook: public_profile, email, user_likes, user_friends.

Experience Manager Mobile-Weiterleitungsendpunkt: Hiermit wird die AEM Mobile-URL angegeben, zu der der Identitätsanbieter eine Weiterleitung ausführen soll, nachdem der Autorisierungsvorgang abgeschlossen ist. Dieser von AEM Mobile bereitgestellte Wert muss beim Identitätsanbieter registriert werden.

Einstellungen für allgemeine Identitätsanbieter

Authentifizierungs-URL: Geben Sie die URL der Website mit dem Anmeldeverhalten an. Diese Website muss die Informationen zum Übermitteln des Authentifizierungstokens an den Berechtigungsdienst enthalten.

Standardsitzungsablauf: Die Gültigkeitsdauer einer Antwort auf eine erfolgreiche Anmeldung in Sekunden, sofern die Dauer in der Antwort auf die Anmeldeanfrage nicht ausdrücklich angegeben ist. Nach Ablauf der Sitzung wird diese aktualisiert, wenn dies vom Identitätsanbieter unterstützt wird. Andernfalls wird der Benutzer abgemeldet. Der Standardwert ist 3600 Sekunden (eine Stunde).

Hinweise und bewährte Verfahren zur benutzerdefinierten Authentifizierung

  • Nachdem Sie den Identitätsanbieter in den Haupteinstellungen erstellt haben, können Sie den Identitätsanbietertyp (SAML 2.0 oder OAuth 2.0) nicht mehr ändern. Wenn Sie den Typ ändern möchten, erstellen Sie einen neuen Identitätsanbieter.
  • Wenn Sie den Identitätsanbieter für ein aktives Projekt ändern, werden alle Benutzer abgemeldet.
  • SAML unterstützt keine Aktualisierung. Nach einer Sitzung muss der Benutzer sich erneut anmelden. Das Gleiche gilt für OAuth, wenn der OAuth-Anbieter keine Aktualisierungstokens unterstützt.
  • Eine Abmeldung auf einem Gerät bedeutet nicht in jedem Fall, dass der Benutzer auch beim Identitätsanbieter abgemeldet wird. Der Identitätsanbieter legt die Gültigkeitsdauer der Sitzung fest.

Dieses Werk unterliegt den Bedingungen der Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.  Twitter™- und Facebook-Beiträge fallen nicht unter die Bedingungen der Creative Commons-Lizenz.

Rechtliche Hinweise   |   Online-Datenschutzrichtlinie