Authentifizierung verstärken

improve this page | report issue

Übersicht

Ressourcen können mit diversen Sicherheitsüberprüfungen geschützt werden. In einem solchen Szenario sendet MobileFirst Server alle relevanten Abfragen gleichzeitig an die Anwendung.

Eine Sicherheitsüberprüfung kann von einer anderen Sicherheitsüberprüfung abhängig sein. Daher ist es wichtig, dass gesteuert werden kann, wann die Abfragen gesendet werden.
In diesem Lernprogramm ist beispielsweise eine Anwendung beschrieben, deren beide Ressourcen mit einem Benutzernamen und einem Kennwort geschützt sind. Für die zweite Ressource ist zudem ein PIN-Code erforderlich.

Voraussetzung: Gehen Sie die Lernprogramme CredentialsValidationSecurityCheck und UserAuthenticationSecurityCheck durch, bevor Sie hier fortfahren.

Fahren Sie mit folgenden Abschnitten fort:

Verweis auf eine Sicherheitsüberprüfung

Erstellen Sie die beiden Sicherheitsüberprüfungen StepUpPinCode und StepUpUserLogin. Die Erstimplementierung dieser Überprüfungen ist die in den Lernprogrammen Berechtigungsnachweise validieren und Benutzerauthentifizierung beschriebene Implementierung.

In diesem Beispiel ist StepUpPinCode abhängig von StepUpUserLogin. Der Benutzer sollte erst nach einer erfolgreichen Anmeldung bei StepUpUserLogin aufgefordert werden, einen PIN-Code einzugeben. Zu diesem Zweck muss StepUpPinCode in der Lage sein, die Klasse StepUpUserLogin zu referenzieren.

Das MobileFirst-Framework stellt eine Annotation zum Injizieren einer Referenz bereit.
Fügen Sie zu Ihrer Klasse StepUpPinCode auf der Klassenebene Folgendes hinzu:

@SecurityCheckReference
private transient StepUpUserLogin userLogin;

Wichtiger Hinweis: Beide Implementierungen von Sicherheitsüberprüfungen müssen in einem Adapter gebündelt werden.

Zum Auflösen dieser Referenz sucht das Framework nach einer Sicherheitsüberprüfung mit der entsprechenden Klasse und injiziert diese Referenz in die abhängige Sicherheitsüberprüfung.
Für den Fall, dass es für eine Klasse mehr als eine Sicherheitsüberprüfung gibt, hat die Annomation einen optionalen Parameter name, mit dem Sie einen eindeutigen Namen der referenzierten Überprüfung angeben können.

Zustandsmaschine

Alle Klassen, die CredentialsValidationSecurityCheck erweitern (wozu StepUpPinCode und StepUpUserLogin gehören), übernehmen eine einfache Zustandsmaschine. Die Sicherheitsüberprüfung kann sich zu jedem konkreten Zeitpunkt in einem der folgenden Zustände befinden:

  • STATE_ATTEMPTING: Eine Abfrage wurde gesendet, und die Sicherheitsüberprüfung wartet auf die Clientantwort. Während dieses Zustands wird die Anzahl der Versuche gezhählt.
  • STATE_SUCCESS: Die Berechtigungsnachweise wurden erfolgreich validiert.
  • STATE_BLOCKED: Die maximale Anzahl von Versuchen ist erreicht und die Überprüfung wird gesperrt.

Der aktuelle Zustand kann mit der übernommenen Methode getState() abgerufen werden.

Fügen Sie in StepUpUserLogin eine Methode hinzu, mit der Sie ohne großen Aufwand überprüfen können, ob der Benutzer zurzeit angemeldet ist. Diese Methode wird später im Lernprogramm verwendet.

public boolean isLoggedIn(){
    return this.getState().equals(STATE_SUCCESS);
}

Methode Authorize

Die Schnittstelle SecurityCheck definiert eine Methode mit der Bezeichnung authorize. Diese Methode ist für die Implementierung der wesentlichen Logik der Sicherheitsüberprüfung verantwortlich, z. B. für das Senden einer Abfrage oder für die Validierung der Anforderung.
Die Klasse CredentialsValidationSecurityCheck, die StepUpPinCode erweitert, enthält bereits eine Implementierung dieser Methode. In diesem Fall besteht das Ziel jedoch darin, den Zustand von StepUpUserLogin zu überprüfen, bevor das Standardverhalten der Methode authorize ausgelöst wird.

Dafür müssen Sie die Methode authorize überschreiben:

@Override
public void authorize(Set<String> scope, Map<String, Object> credentials, HttpServletRequest request, AuthorizationResponse response) {
    if(userLogin.isLoggedIn()){
        super.authorize(scope, credentials, request, response);
    }
}

Diese Implementierung überprüft den aktuellen Zustand der StepUpUserLogin-Referenz:

  • Wenn der Zustand STATE_SUCCESS ist (d. h. der Benutzer angemeldet ist), folgt der normale Ablauf der Sicherheitsüberprüfung.
  • Wenn sich StepUpUserLogin in einem anderen Zustand befindet, wird kein Schritt ausgeführt. Das bedeutet, es wird keine Abfrage gesendet und es gibt keine Erfolgs- oder Fehlermeldung.

Angenommen, die Ressource wird mit ** StepUpPinCode und mit StepUpUserLogin geschützt. In dem Fall stellt der Ablauf sicher, dass der Benutzer angemeldet ist, bevor er zur Eingabe eines zweiten Berechtigungsnachweises (des PIN-Codes) aufgefordert wird. Der Client emfpängt beide Abfragen nie zur selben Zeit, auch wenn beide Sicherheitsüberprüfungen aktiviert sind.

Wenn die Ressource dagegen nur mit StepUpPinCode geschützt wird (das Framework also nur diese Sicherheitsüberprüfung aktiviert), können Sie die Implementierung von authorize so ändern, dass StepUpUserLogin manuell ausgelöst wird.

@Override
public void authorize(Set<String> scope, Map<String, Object> credentials, HttpServletRequest request, AuthorizationResponse response) {
    if(userLogin.isLoggedIn()){
        // Wenn StepUpUserLogin erfolgreich ist, mit normaler Verarbeitung von StepUpPinCode fortfahren
        super.authorize(scope, credentials, request, response);
    } else {
        // In allen anderen Fällen stattdessen StepUpUserLogin verarbeiten
        userLogin.authorize(scope, credentials, request, response);
    }
}

Aktuellen Benutzer abrufen

In der Sicherheitsüberprüfung StepUpPinCode geht es darum, die ID des aktuellen Benutzers zu erfahren, damit in einer Datenbank nach dem PIN-Code dieses Benutzers gesucht werden kann.

Fügen Sie in der Sicherheitsüberprüfung StepUpUserLogin die folgende Methode hinzu, um den aktuellen Benutzer aus dem Autorisierungskontext abzurufen:

public AuthenticatedUser getUser(){
    return authorizationContext.getActiveUser();
}

In StepUpPinCode können Sie dann die Methode userLogin.getUser() verwenden, um den aktuellen Benutzer von der Sicherheitsüberprüfung StepUpUserLogin abzurufen und den gültigen PIN-Code für diesen konkreten Benutzer zu überprüfen:

@Override
   protected boolean validateCredentials(Map<String, Object> credentials) {
        // Richtigen PIN-Code aus der Datenbank abrufen
    User user = userManager.getUser(userLogin.getUser().getId());

    if(credentials!=null &&  credentials.containsKey(PINCODE_FIELD)){
        String pinCode = credentials.get(PINCODE_FIELD).toString();

        if(pinCode.equals(user.getPinCode())){
            errorMsg = null;
            return true;
        }
        else{
            errorMsg = "Wrong credentials. Hint: " + user.getPinCode();
        }
    }
    return false;
}

Abfrage-Handler

Auf der Clientseite gibt es keine spezifischen APIs für die Handhabung mehrerer Schritte. Vielmehr handhabt jeder Abfrage-Handler seine eigenen Abfragen. In diesem Beispiel müssen Sie zwei separate Abfrage-Handler registrieren, einen für die Abfragen von StepUpUserLogin und einen für die Abfragen von StepUpPincode.

Beispielanwendung für Intensivierung

Beispielanwendungen

Sicherheitsüberprüfung

Die Sicherheitsüberprüfungen StepUpUserLogin und StepUpPinCode sind im SecurityChecks-Projekt unter dem StepUp-Maven-Projekt verfügbar. Klicken Sie hier, um das Maven-Projekt für Sicherheitsüberprüfungen herunterzuladen.

Anwendungen

Beispielanwendungen sind für iOS (Swift), Android, Cordova, Windows 8.1/10 und das World Wide Web verfügbar.

Verwendung des Beispiels

Anweisungen finden Sie in der Datei README.md zum Beispiel.

Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.
Last modified on February 27, 2020