Authentifizierung und Sicherheit

Übersicht

Das MobileFirst-Sicherheitsframework basiert auf dem Protokoll OAuth 2.0. Gemäß diesem Protokoll kann eine Ressource mit einem Bereich geschützt werden, in dem die erforderlichen Berechtigungen für den Zugriff auf die Ressource definiert sind. Für den Zugriff auf eine geschützte Ressource muss die Clientanwendung ein passendes Zugriffstoken bereitstellen, in das der Bereich für die dem Client gewährte Autorisierung eingebunden ist.

Das OAuth-Protokoll unterscheidet die Rolle des Autorisierungsservers von der Rolle des Ressourcenservers, der die Ressourcen bereitstellt.

• Der Autorisierungsserver verwaltet die Clientberechtigungen und die Tokengenerierung.
• Der Ressourcenserver verwendet den Autorisierungsserver, um das vom Client bereitgestellte Zugriffstoken zu validieren und um sicherzustellen, dass das Token zum Schutzbereich der angeforderten Ressource passt.

Im Zentrum des Sicherheitsframeworks steht ein Autorisierungsserver, der das OAuth-Protokoll implementiert und die OAuth-Endpunkte, mit denen der Client beim Anfordern von Zugriffstoken interagiert, zugänglich macht. Das Sicherheitsframework enthält die logischen Bausteine für die Implementierung einer angepassten Autorisierungslogik unter Verwendung des Autorisierungsservers und des zugrunde liegenden OAuth-Protokolls. MobileFirst Server fungiert standardmäßig auch als Autorisierungsserver. Sie können aber auch ein IBM WebSphere-DataPower-Gerät als Autorisierungsserver konfigurieren, der mit MobileFirst Server interagiert.

Die Clientanwendung kann diese Token dann für den Zugriff auf Ressourcen eines Ressourcenservers verwenden, bei dem es sich um MobileFirst Server oder um einen externen Server handeln kann. Der Ressourcenserver überprüft die Gültigkeit des Tokens, um sicherzustellen, dass dem Client der Zugriff auf die angeforderte Ressource gewährt werden kann. Durch die Trennung von Ressourcenserver und Autorisierungsserver können Sie die Sicherheit für Ressourcen durchsetzen, die außerhalb von MobileFirst Server ausgeführt werden.

Anwendungsentwickler schützen den Zugriff auf Ressourcen, indem sie für jede Ressource den erforderlichen Bereich definieren und die Sicherheitsüberprüfungen und Abfrage-Handler implementieren. Das serverseitige Sicherheitsframework und die clientseitige API kümmern sich transparent um den OAuth-Nachrichtenaustausch und die Interaktion mit dem Autorisierungsserver, sodass sich Entwickler vollständig auf die Autorisierungslogik konzentrieren können.

Fahren Sie mit folgenden Abschnitten fort:

• Autorisierungsentitäten
• Ressourcen schützen
• Autorisierungsablauf
• Nächste Lernprogramme

Autorisierungsentitäten

Zugriffstoken

Ein MobileFirst-Zugriffstoken ist eine digital signierte Entität, die die Autorisierungsberechtigungen eines Clients beschreibt. Wenn der Autorisierungsanforderung des Clients für einen bestimmten Bereich entsprochen und der Client authentifiziert wurde, sendet der Tokenendpunkt des Autorisierungsservers eine HTTP-Antwort mit dem angeforderten Zugriffstoken an den Client.

Struktur

Das MobileFirst-Zugriffstoken enthält folgende Informationen:

• Client-ID: Eine eindeutige Kennung des Clients
• Bereich: Der Bereich, für den das Token ausgestellt wurde (siehe “OAuth-Bereiche”). Dieser Bereich umfasst nicht den obligatorischen Anwendungsbereich.
• Tokenablaufzeit: Die Zeit, nach der das Token ungültig wird (abläuft), in Sekunden

Tokenablaufzeit

Das ausgestellte Zugriffstoken bleibt gültig, bis der Ablaufzeitpunkt erreicht ist. Die Ablaufzeit des Zugriffstokens ist, verglichen mit den Ablaufzeiten aller Sicherheitsüberprüfungen im Bereich, die kürzeste. Wenn jedoch die kürzeste Ablaufzeit länger als der maximale Tokenablaufzeitraum der Anwendung ist, wird die Ablaufzeit des Tokens auf die aktuelle Zeit zuzüglich des maximalen Ablaufzeitraums gesetzt. Der Standardwert für den maximalen Tokenablaufzeitraum (d. h. die maximale Gültigkeitsdauer) liegt bei 3.600 Sekunden (1 Stunde). Der Wert kann jedoch konfiguriert werden, indem der Wert der Eigenschaft maxTokenExpiration gesetzt wird (siehe “Maximalen Ablaufzeitraum für Zugriffstoken konfigurieren”).

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
    "token_type": "Bearer",
    "expires_in": 3600,
    "access_token": "yI6ICJodHRwOi8vc2VydmVyLmV4YW1",
    "scope": "scopeElement1 scopeElement2"
}

Aktualisierungstoken

Ein Aktualisierungstoken ist eine besondere Art von Token. Wenn das Zugriffstoken abgelaufen ist, kann das Aktualisierungstoken verwendet werden, um ein neues Zugriffstoken anzufordern. Für die Anforderung eines neuen Zugriffstokens kann ein gültiges Aktualisierungstoken vorgelegt werden. Aktualisierungstoken sind langlebige Token, die länger als Zugriffstoken gültig bleiben.

Eine Anwendung muss Vorsicht walten lassen, wenn sie Aktualisierungstoken verwendet, da ein Benutzer mit einem solchen Token unbegrenzte Zeit authentifiziert bleiben kann. Social-Media-Anwendungen, E-Commerce-Anwendungen, Produktkataloganzeigen und Dienstprogrammanwendungen, bei denen Benutzer nicht regelmäßig vom Anwendungsprovider authentifiziert werden, können Aktualisierungstoken nutzen. Anwendungen, die eine regelmäßige Benutzerauthentifizierung erfordern, sollten die Verwendung von Aktualisierungstoken vermeiden.

MobileFirst-Aktualisierungstoken

Ein MobileFirst-Aktualisierungstoken ist eine digital signierte Entität wie ein Zugriffstoken, die die Autorisierungsberechtigungen eines Clients beschreibt. Aktualisierungstoken können verwendet werden, um neue Zugriffstoken desselben Geltungsbereichs zu erhalten. Wenn der Autorisierungsanforderung des Clients für einen bestimmten Bereich entsprochen und der Client authentifiziert wurde, sendet der Tokenendpunkt des Autorisierungsservers eine HTTP-Antwort mit dem angeforderten Zugriffstoken und Aktualisierungstoken an den Client. Wenn das Zugriffstoken abläuft, sendet der Client ein Aktualisierungstoken an den Tokenendpunkt des Autorisierungsservers, um ein neues Zugriffstoken und ein neues Aktualisierungstoken zu erhalten.

Struktur

Das MobileFirst-Aktualisierungstoken enthält ähnlich wie ein MobileFirst-Zugriffstoken die folgenden Informationen:

• Client-ID: Eine eindeutige Kennung des Clients
• Bereich: Der Bereich, für den das Token ausgestellt wurde (siehe “OAuth-Bereiche”). Dieser Bereich umfasst nicht den obligatorischen Anwendungsbereich.
• Tokenablaufzeit: Die Zeit, nach der das Token ungültig wird (abläuft), in Sekunden

Tokenablaufzeit

Der Ablaufzeitraum für Aktualisierungstoken ist länger als der normale Ablaufzeitraum für Zugriffstoken. Ein einmal ausgestelltes Aktualisierungstoken bleibt gültig, bis der Ablaufzeitpunkt erreicht ist. Dank dieses Gültigkeitszeitraums kann ein Client ein Aktualisierungstoken verwenden, um ein neues Zugriffstoken und ein neues Aktualisierungstoken zu erhalten. Der Ablaufzeitraum eines Aktualisierungstokens ist festgelegt und liegt bei 30 Tagen. Jedes Mal, wenn der Client erfolgreich ein neues Zugriffstoken und Aktualisierungstoken erhält, wird der Ablaufzeitraum des Aktualisierungstokens zurückgesetzt, sodass der Client den Eindruck hat, das Token würde nie ablaufen. Die Regeln für die Ablaufzeit des Zugriffstokens sind die im Abschnitt Zugriffstoken erläuterten.

            <jndiEntry jndiName="mfp/mfp.security.refreshtoken.enabled.apps" value='"com.sample.android.myapp1;com.sample.android.myapp2"'/>
            

        HTTP/1.1 200 OK
        Content-Type: application/json
        Cache-Control: no-store
        Pragma: no-cache
        {
            "token_type": "Bearer",
            "expires_in": 3600,
            "access_token": "yI6ICJodHRwOi8vc2VydmVyLmV4YW1",
            "scope": "scopeElement1 scopeElement2",
            "refresh_token": "yI7ICasdsdJodHRwOi8vc2Vashnneh "
        }
        

Hinweis: Aktualisierungstoken sind im Vergleich zu Zugriffstoken langlebig. Daher sollten Sie Aktualisierungstoken mit Vorsicht verwenden. Anwendungen, die keine regelmäßige Benutzerauthentifizierung erfordern, sind ideale Kandidaten für die Verwendung von Aktualisierungstoken.

Ab CD-Update 3 unterstützt MobileFirst Aktualisierungstoken für iOS.

Sicherheitsüberprüfungen

Eine Sicherheitsüberprüfung ist eine serverseitige Entität, die die Sicherheitslogik zum Schutz sererseitiger Anwendungsressourcen implementiert. Ein einfaches Beispiel für eine Sicherheitsüberprüfung ist die Sicherheitsüberprüfung einer Benutzeranmeldung, bei der die Berechtigungsnachweise eines Benutzers empfangen und anhand einer Benutzerregistry verifiziert werden. Ein weiteres Beispiel ist die vordefinierte Sicherheitsüberprüfung der MobileFirst-Anwendungsauthentizität, bei der die Authentizität der mobilen Anwendung validiert wird und die Anwendungsressourcen vor unbefugtem Zugriff gescützt werden. Dieselbe Sicherheitsüberprüfung kann genutzt werden, um diverse Ressourcen zu schützen.

Eine Sicherheitsüberprüfung setzt normalerweise Sicherheitsabfragen ab, auf die der Client in einer bestimmten Weise antworten muss, um die Prüfung zu bestehen. Dieser Handshake erfolgt im Rahmen des OAuth-Ablaufs für die Anforderung eines Zugriffstokens. Der Client verwendet Abfrage-Handler für die Behandlung von Abfragen der Sicherheitsüberprüfungen.

Integrierte Sicherheitsüberprüfungen

Die folgenden vordefinierten Sicherheitsüberprüfungen sind verfügbar:

• Anwendungsauthentizität
• LTPA-basiertes Single Sign-on (SSO)
• Direkte Aktualisierung

Abfrage-Handler

Wenn der Client versucht, auf eine geschützte Ressource zuzugreifen, kann er eine Abfrage erhalten. Bei dieser Abfrage kann es sich um eine Frage, einen Sicherheitstest oder eine Eingabeaufforderung des Servers handeln. Mit der Abfrage soll sichergestellt werden, dass der Client berechtigt ist, auf diese Ressource zuzugreifen. In den meisten Fällen werden im Rahmen der Abfrage Berechtigungsnachweise angefordert, z. B. ein Benutzername und ein Kennwort.

Ein Abfrage-Handler ist eine clientseitige Entität, die die clientseitige Sicherheitslogik und die zugehörigen Benutzerinteraktionen implementiert. Wichtiger Hinweis: Eine erhaltene Abfrage kann nicht ignoriert werden. Sie muss beantwortet werden oder der laufende Vorgang muss abgebrochen werden. Das Ignorieren einer Abfrage kann zu nicht erwartetem Verhalten führen.

Weitere Informationen zu Sicherheitsüberprüfungen enthält das Lernprogramm Sicherheitsüberprüfungen erstellen. Weitere Informationen zu Abfrage-Handlern finden Sie im Lernprogramm Berechtigungsnachweise validieren.

Bereiche

Sie können Ressourcen wie Adapter vor unbefugtem Zugriff schützen, indem Sie den Ressourcen einen Bereich zuweisen.

Ein Bereich ist durch eine Zeichenfolge mit einem oder mehreren, jeweils durch ein Leerzeichen getrennten Bereichselement(en) definiert (“Bereichselement1 Bereichselement2 …”) oder auf null gesetzt, wenn der Standardbereich (RegisteredClient) angewendet werden soll. Das MobileFirst-Sicherheitsframework erfordert für jede Adapterressource ein Zugriffstoken. Dies gilt auch dann, wenn der Ressource kein Bereich zugewiesen ist, solange nicht der Ressourcenschutz für die Ressource inaktiviert ist (siehe Adapterressourcen schützen).

Bereichselemente

Folgendes kann ein Bereichselement sein:

• Name der Sicherheitsüberprüfung
• Beliebiges Schlüsselwort wie access-restricted oder deletePrivilege, das die für diese Ressource erforderliche Sicherheitsstufe definiert. Dieses Schlüsselwort wird später einer Sicherheitsüberprüfung zugeordnet.

Bereichszuordnung

Die Bereichselemente, die Sie in Ihren Bereich schreiben, werden standardmäßig einer Sicherheitsüberprüfung mit demselben Namen zugeordnet.Wenn Sie beispielsweise eine Sicherheitsüberprüfung mit der Bezeichnung PinCodeAttempts schreiben, können Sie in Ihrem Bereich ein Bereichselement mit eben diesem Namen verwenden.

Die Bereichszuordnung ermöglicht die Zuordnung von Bereichselementen zu Sicherheitsüberprüfungen. Wenn der Client nach einem Bereichselement fragt, definiert diese Konfiguration, welche Sicherheitsüberprüfungen durchgeführt werden sollen. Sie können beispielsweise das Bereichselement access-restricted Ihrer Sicherheitsprüfung PinCodeAttempts zuordnen.

Die Bereichszuordnung ist hilfreich, wenn der Schutz einer Ressource von der Anwendung abhängig sein soll, die versucht, auf die Ressource zuzugreifen. Sie können einen Bereich auch einer Liste mit null oder mehr Sicherheitsüberprüfungen zuordnen.

Beispiel: scope = access-restricted deletePrivilege

• App A:
  • access-restricted ist PinCodeAttempts zugeordnet.
  • deletePrivilege ist einer leeren Zeichenfolge zugeordnet.
• App B:
  • access-restricted ist PinCodeAttempts zugeordnet.
  • deletePrivilege ist UserLogin zugeordnet.

Wenn Sie Ihr Bereichselement einer leeren Zeichenfolge zuordnen, wählen Sie im Popup-Menü Neue Zuordnung von Bereichselementen hinzufügen keine Sicherheitsüberprüfung aus.

Sie können auch die JSON-Konfigurationsdatei der Anwendung manuell bearbeiten und die erforderliche Konfiguration definieren. Senden Sie dann die Änderungen per Push-Operation zurück an MobileFirst Server.

1. Navigieren Sie in eiem Befehlszeilenfenster zum Projektstammverzeichnis und führen Sie den Befehl mfpdev app pull aus.
2. Öffnen Sie die Konfigurationsdatei aus dem Ordner [Projektordner]\mobilefirst.

3. Bearbeiten Sie Datei. Definieren Sie eine Eigenschaft scopeElementMapping und definieren Sie in dieser Eigenschaft Datenpaare, die jeweils aus dem Namen Ihres ausgewählten Bereichselements und einer Zeichenfolge mit null oder mehr durch Leerzeichen getrennten Sicherheitsüberprüfungen besteht, denen das Element zugeordnet wird. Beispiel:

    "scopeElementMapping": {
        "UserAuth": "UserAuthentication",
        "SSOUserValidation": "LtpaBasedSSO CredentialsValidation"
    }
   

4. Implementieren Sie die aktualisierte JSON-Konfigurationsdatei. Führen Sie dazu den Befehl mfpdev app push aus.

Sie können aktualisierte Konfigurationen auch per Push-Operation auf ferne Server übertragen. Sehen Sie sich dazu das Lernprogramm MobileFirst-Artefakte über die MobileFirst CLI verwalten an.

Ressourcen schützen

Im OAuth-Modell ist eine geschützte Ressource eine Ressource, für die ein Zugriffstoken erforderlich ist. Sie können das MobileFirst-Sicherheitsframework verwenden, um von einer Instanz von MobileFirst Server und von einem externen Server bereitgestellte Ressourcen zu schützen. Für den Schutz einer Ressource weisen Sie ihr einen Bereich zu, der die Berechtigungen definiert, die erforderlich sind, um ein Zugriffstoken für die Ressource beziehen zu können.

Sie können Ihre Ressourcen auf verschiedenen Wegen schützen:

Obligatorischer Anwendungsbereich

Auf der Anwendungsebene können Sie einen Bereich definieren, der auf alle von der Anwendung verwendeten Ressourcen angewendet wird. Das Sicherheitsframework führt diese Überprüfungen (soweit vorhanden) zusätzlich zu den Sicherheitsüberprüfungen des angeforderten Ressourcenbereichs aus.

Hinweis:

• Der obligatorische Anwendungsbereich wird nicht angewendet, wenn auf eine ungeschützte Ressource zugegriffen wird.
• Das Zugriffstoken, das für den Ressourcenbereich ausgestellt wird, enthält nicht den obligatorischen Anwendungsbereich.

Wählen Sie in der Navigationsseitenleiste der MobileFirst Operations Console im Abschnitt Anwendungen Ihre Anwendung und dann das Register Sicherheit aus. Wählen Sie unter Obligatorischer Anwendungsbereich die Option Zum Bereich hinzufügen aus.

Sie können auch die JSON-Konfigurationsdatei der Anwendung manuell bearbeiten und die erforderliche Konfiguration definieren. Senden Sie dann die Änderungen per Push-Operation zurück an MobileFirst Server.

1. Navigieren Sie in eiem Befehlszeilenfenster zum Projektstammverzeichnis und führen Sie den Befehl mfpdev app pull aus.
2. Öffnen Sie die Konfigurationsdatei aus dem Ordner [Projektordner]\mobilefirst.

3. Bearbeiten Sie die Datei. Definieren Sie eine Eigenschaft mandatoryScope und legen Sie als Eigenschaftswert eine Bereichszeichenfolge fest, die Ihre ausgewählten Bereichselemente jeweils mit einem Leerzeichen als Trennzeichen auflistet. Beispiel:

   "mandatoryScope": "appAuthenticity PincodeValidation"
   

4. Implementieren Sie die aktualisierte JSON-Konfigurationsdatei. Führen Sie dazu den Befehl mfpdev app push aus.

Sie können aktualisierte Konfigurationen auch per Push-Operation auf ferne Server übertragen. Sehen Sie sich dazu das Lernprogramm MobileFirst-Artefakte über die MobileFirst CLI verwalten an.

Adapterressourcen schützen

In Ihrem Adapter können Sie den schützenden Bereich für eine Java-Methode, eine JavaScript-Ressourcenprozedur oder eine ganze JavaScript-Ressourcenklasse angeben (siehe folgende Abschnitte zu Java und JavaScript). Ein Bereich ist durch eine Zeichenfolge mit einem oder mehreren, jeweils durch ein Leerzeichen getrennten Bereichselement(en) definiert (“Bereichselement1 Bereichselement2 …”) oder auf null gesetzt, wenn der Standardbereich angewendet werden soll (siehe Bereiche).

Der MobileFirst-Standardbereich ist RegisteredClient. Dieser Bereich fordert für den Zugriff auf die Ressource ein Zugriffstoken an und überprüft, ob die Ressourcenanforderung von einer Anwendung stammt, die bei MobileFirst Server registriert ist. Dieser Schutz wird immer angewendet, sofern Sie nicht den Ressourcenschutz inaktivieren. Wenn Sie also keinen Bereich für Ihre Ressource festlegen, ist die Ressource trotzdem geschütztz.

Hinweis: RegisteredClient ist ein reserviertes MobileFirst-Schlüsselwort. Definieren Sie keine angepassten Bereichselemente oder Sicherheitsüberprüfungen mit diesem Namen.

Java-Adapterressourcen schützen

Wenn Sie einer JAX-RS-Methode oder -Klasse einen schützenden Bereich zuweisen möchten, fügen Sie die Annotation @OAuthSecurity zur Methoden- oder Klassendeklaration hinzu und setzen Sie das Element scope der Annotation auf Ihren bevorzugten Bereich. Ersetzen Sie IHR_BEREICH durch eine Zeichenfolge mit einem oder mehreren Bereichselement(en) (“Bereichselement1 Bereichselement2 …”):

@OAuthSecurity(scope = "IHR_BEREICH")

Ein Klassenbereich wird auf alle Methoden der Klasse angewendet. Eine Ausnahme bilden Methoden mit eigener Annotation @OAuthSecurity.

Hinweis: Wenn das Element enabled der Annotation @OAuthSecurity auf false gesetzt ist, wird das Element scope ignoriert (siehe Java-Ressourcenschutz inaktivieren).

Beispiele

Der folgende Code schützt eine Methode helloUser durch einen Bereich, der die Bereichselemente UserAuthentication und Pincode enthält:

@GET
@Path("/{username}")
@OAuthSecurity(scope = "UserAuthentication Pincode")
public String helloUser(@PathParam("username") String name){
    ...
}

Der folgende Code schützt eine Klasse WebSphereResources durch die vordefinierte Sicherheitsprüfung LtpaBasedSSO:

@Path("/users")
@OAuthSecurity(scope = "LtpaBasedSSO")
public class WebSphereResources {
    ...
}

JavaScript-Adapterressourcen schützen

Wenn Sie einer JavaScript-Prozedur einen schützenden Bereich zuweisen möchten, setzen Sie in der Datei adapter.xml das Bereichsattribut des Elements <procedure> auf Ihren bevorzugten Bereich. Ersetzen Sie PROZEDURNAME durch den Namen Ihrer Prozedur und IHR_BEREICH durch eine Zeichenfolge mit einem oder mehreren Bereichselement(en) (“Bereichselement1 Bereichselement2 …”):

<procedure name="PROZEDURNAME" scope="IHR_BEREICH">

Hinweis: Wenn das Attribut secured des Elements <procedure> auf “false” gesetzt ist, wird das Bereichsattribut (scope) ignoriert (siehe JavaScript-Ressourcenschutz inaktivieren).

Beispiel

Der folgende Code schützt eine Prozedur userName durch einen Bereich, der die Bereichselemente UserAuthentication und Pincode enthält:

<procedure name="userName" scope="UserAuthentication Pincode">

Ressourcenschutz inaktivieren

Sie können den MobileFirst-Standardressourcenschutz für eine bestimmte Java- oder JavaScript-Adapterressource oder für eine ganze Java-Klasse inaktivieren (siehe folgende Abschnitte Java und JavaScript). Wenn der Ressourcenschutz inaktiviert ist, erfordert das MobileFirst-Sicherheitsframework kein Token für den Zugriff auf die Ressource (siehe Ungeschützte Ressourcen).

Java-Ressourcenschutz inaktivieren

Wenn Sie den OAuth-Schutz für eine Java-Ressourcenmethode oder -Ressourcenklasse vollständig inaktivieren möchten, fügen Sie die Annotation @OAuthSecurity zur Methoden- oder Klassendeklaration hinzu und setzen Sie das Element enabled auf den Wert false:

@OAuthSecurity(enabled = false)

Der Standardwert des Annotationselements enabled ist true. Wenn das Element enabled auf false gesetzt ist, wird das Element scope ignoriert und die Ressource oder Ressourcenklasse nicht geschützt.

Hinweis: Wenn Sie einer Methode einer ungeschützten Klasse einen Bereich zuweisen, wird dieser Methode ungeachtet der Klassenannotation geschützt, solange Sie das Element enabled der Ressourcenannotation nicht auf false setzen.

Beispiele

Der folgende Code inaktiviert den Ressourcenschutz für eine Methode helloUser:

    @GET
    @Path("/{username}")
    @OAuthSecurity(enabled = "false")
    public String helloUser(@PathParam("username") String name){
        ...
    }

Der folgende Code inaktiviert den Ressourcenschutz für eine Klasse MyUnprotectedResources:

    @Path("/users")
    @OAuthSecurity(enabled = "false")
    public class MyUnprotectedResources {
        ...
    }

JavaScript-Ressourcenschutz inaktivieren

Wenn Sie den OAuth-Schutz für eine JavaScript-Adapterressource (Prozedur) vollständig inaktivieren möchten, setzen Sie in der Datei adapter.xml das Attribut secured des Elements <procedure> auf false:

<procedure name="procedureName" secured="false">

Wenn das Attribut secured auf false gesetzt ist, wird das Bereichsattribut (scope) ignoriert. Die Ressource ist dementsprechend ungeschützt.

Beispiel

Der folgende Code inaktiviert den Ressourcenschutz für eine Prozedur userName:

<procedure name="userName" secured="false">

Ungeschützte Ressourcen

Eine ungeschützte Ressource ist eine Ressource, für die kein Zugriffstoken erforderlich ist. Das MobileFirst-Sicherheitsframework verwaltet nicht den Zugriff auf ungeschützte Ressourcen und überprüft oder validiert nicht die Identität von Clients, die auf solche Ressourcen zugreifen. Features wie die direkte Aktualisierung, die Blockierung des Gerätezugriffs oder die Inaktivierung einer Anwendung über Fernzugriff werden daher für ungeschützte Ressourcen nicht unterstützt.

Externe Ressourcen schützen

Zum Schutz externer Ressourcen müssen Sie einen Ressourcenfilter mit Validierungsmodul für Zugriffstoken zum externen Ressourcenserver hinzufügen. Das Tokenvalidierungsmodul verwendet den Introspektionsendpunkt des Autorisierungsservers des Sicherheitsframeworks, um die MobileFirst-Zugriffstoken zu valisieren, bevor der OAuth-Clientzugriff auf die Ressourcen gewährt wird. Sie können die MobileFirst-REST-API für die MobileFirst-Laufzeit verwenden, um für externe Server ein eigenes Validierungsmodul für Zugriffstoken zu erstellen. Sie können aber auch eine der bereitgestellten MobileFirst-Erweiterungen für den Schutz externer Java-Ressourcen nutzen. Sehen Sie sich dazu das Lernprogramm Externe Ressourcen schützen an.

Autorisierungsablauf

Die Autorisierung erfolgt in zwei Phasen:

1. Der Client fordert ein Zugriffstoken an.
2. Der Client nutzt das Token, um auf eine geschützte Ressource zuzugreifen.

Zugriffstoken anfordern

In dieser Phase durchläuft der Client Sicherheitsüberprüfungen, um ein Zugriffstoken zu erhalten.

Bevor der Client ein Zugriffstoken anfordert, registriert er sich bei MobileFirst Server. Bei der Registrierung stellt der Client einen öffentlichen Schlüssel bereit, der für die Authentifizierung der Clientidentität verwendet wird. Diese Phase gibt es während der gesamten Lebensdauer einer mobilen Anwendungsinstanz nur einmal. Wenn die Sicherheitsüberprüfung der Anwendungsauthentizität aktiviert ist, wird die Authentizität der Anwendung während ihrer Registrierung validiert.

1. Die Clientanwendung sendet eine Anforderung, um ein Zugriffstoken für einen angegebenen Bereich zu erhalten.

   Der Client fordert ein Zugriffstoken mit einem bestimmten Bereich an. Der angeforderte Bereich muss derselben Sicherheitsüberprüfung zugeordnet sein wie der Bereich der geschützten Ressource, auf die der Client zugreifen möchte. Darüber hinaus kann der angeforderte Bereich weiteren Sicherheitsüberprüfungen zugeordnet sein. Wenn der Client den Bereich der geschützten Ressource nicht kennt, kann er zunächst ein Zugriffstoken mit einem leeren Bereich anfordern. Versucht er, mit dem empfangenen Token auf die Ressource zuzugreifen, empfängt er eine Antwort mit einem Fehler 403 (Zugriff verboten) und dem erforderlichen Bereich für die angeforderte Ressource.

2. Die Clientanwendung durchläuft die im angeforderten Bereich vorgesehenen Sicherheitsüberprüfungen.

   MobileFirst Server führt die Sicherheitsüberprüfungen aus, denen der Bereich aus der Clientanforderung zugeordnet ist. Ausgehend vom Ergebnis dieser Überprüfung entspricht der Autorisierungsserver der Anforderung des Clients oder weist diese Anforderung zurück. Wenn ein obligatorischer Anwendungsbereich definiert ist, werden die Sicherheitsüberprüfungen nicht nur für den Bereich aus der Anforderung, sondern auch für den obligatorischen Bereich durchgeführt.

3. Nach erfolgreichem Abschluss des Abfrageprozesses leitet die Clientanwendung die Anforderung an den Autorisierungsserver weiter.

   Nach erfolgreicher Autorisierung wird der Client zum Tokenendpunkt des Autorisierungsservers umgeleitet, wo er mithilfe des öffentlichen Schlüssels, der bei der Clientregistrierung bereitgestellt wurde, authentifiziert wird. Auf erfolgreicher Authentifizierung stellt der Autorisierungsserver für den Client ein digital signiertes Zugriffstoken (mit der ID des Clients, dem angeforderten Bereich und der Ablaufzeit des Tokens) aus.

4. Die Clientanwendung empfängt das Zugriffstoken.

Token für den Zugriff auf eine geschützte Ressource verwenden

Sie können die Sicherheit für Ressourcen, die in MobileFirst Server ausgeführt werden (siehe Diagramm), und für Ressourcen, die auf einem externen Ressourcenserver ausgeführt werden, durchsetzen. Diesbezügliche Erläuterungen finden sie im Lernprogramm Externe Ressourcen mit MobileFirst Server authentifizieren.

Wenn der Client ein Zugriffstoken erhalten hat, hängt er das Token an alle neue Zugriffsanforderungen für geschützte Ressourcen an. Der Ressourcenserver verwendet den Introspektionsendpunkt des Autorisierungsservers, um das Token zu validieren. Für die Validierung wird die digitale Signatur des Tokens verwendet, um die Client-ID zu verfizieren. Außerdem wird während der Validierung geprüft, ob der Bereich mit dem aus der autorisierten Anforderung übereinstimmt. Zudem wird sichergestellt, dass das Token nicht abgelaufen ist. Wenn das Token validiert ist, wird dem Client der Zugriff auf die Ressource gewährt.

1. Die Clientanwendung sendet eine Anforderung mit dem empfangenen Token.
2. Das Validierungsmodul validiert das Token.
3. MobileFirst Server fährt mit dem Adapteraufruf fort.

Nächste Lernprogramme

In der Seitenleistennavigation können Sie Lernprogramme auswählen, um sich näher mit der Authentifizierung in der MobileFirst Foundation zu beschäftigen.

• Sicherheitsüberprüfung erstellen
  • Vereinbarung einer Sicherheitsüberprüfung
• CredentialsValidationSecurityCheck
  • Abfrage-Handler in Ionic-Anwendungen implementieren
  • Klasse CredentialsValidationSecurityCheck implementieren
  • Abfrage-Handler in JavaScript-Anwendungen (Cordova, Web) implementieren
  • Abfrage-Handler in iOS-Anwendungen implementieren
  • Abfrage-Handler in Android-Anwendungen implementieren
  • Abfrage-Handler in universellen Windows-8.1-Anwendungen und Windows-10-UWP-Anwendungen implementieren
• UserAuthenticationSecurityCheck
  • Klasse UserAuthenticationSecurityCheck implementieren
  • Abfrage-Handler in JavaScript-Anwendungen (Cordova, Web) implementieren
  • Abfrage-Handler in iOS-Anwendungen implementieren
  • Abfrage-Handler in Android-Anwendungen implementieren
  • Abfrage-Handler in universellen Windows-8.1-Anwendungen und Windows-10-UWP-Anwendungen implementieren
• ExternalizableSecurityCheck implementieren
• Authentifizierung verstärken
• Registrierung
• LTPA-basierte SSO-Sicherheitsüberprüfung
• Anwendungsauthentizität
• Vertrauliche Clients
• Geräte-Single-Sign-on konfigurieren
• MobileFirst Server für die Authentifizierung externer Ressourcen verwenden
  • Java-Token-Validator
  • Trust Association Interceptor
  • Node.js-Validator
  • Windows .NET Message Inspector
• Certificate Pinning
• Keystore für MobileFirst Server konfigurieren