In diesem Abschnitt wird beschrieben, wie Sie die sitzungsbasierte NSX-Authentifizierung nutzen, um bei Verwendung der API ein JSESSIONID-Cookie zu generieren. Bei diesem Verfahren müssen Sie Ihren Benutzernamen und Ihr Kennwort nicht so oft eingeben. Sie können diesen Authentifizierungstyp mit der vIDM- und LDAP-Authentifizierung verwenden.

NSX nutzt verschiedene Mechanismen zur Authentifizierung von NSX-Benutzern. Dazu gehören:

  • HTTP-Authentifizierung
  • Sitzungsbasierte Authentifizierung
  • Prinzipalidentität oder zertifikatbasierte Authentifizierung
  • Single Sign-on mit vIDM und RBAC

NSX verwendet einen Benutzernamen und ein Kennwort, um während der Sitzungserstellung ein Sitzungscookie zu generieren. Sobald das Sitzungscookie erstellt wurde, können nachfolgende API-Anforderungen anstelle des Benutzernamens und des Kennworts dieses Sitzungscookie verwenden. Der Sitzungsstatus ist lokal für den Server, auf dem die Sitzung ausgeführt wird. Wenn Clients Anforderungen an die NSX Manager stellen, kann sich der Benutzer nur authentifizieren, wenn die angegebene Sitzungs-ID einer der vom Server generierten IDs entspricht. Wenn sich ein Benutzer von NSX Manager abmeldet, wird die Sitzungs-ID sofort gelöscht und kann nicht wiederverwendet werden. Sitzungen, die sich im Leerlauf befinden, laufen automatisch wegen einer Zeitüberschreitung ab. Sie können sie auch über die API löschen.

Der Zugriff mit der API-Anforderung generiert Überwachungsprotokolleinträge. Diese Protokollierung ist immer aktiviert und kann nicht deaktiviert werden. Die Prüfung der Sitzungen wird beim Systemstart initiiert. Überwachungsprotokollmeldungen enthalten den Text audit="true" im strukturierten Datenteil der Protokollmeldung.

In diesem Beispiel wird die Verwendung von cURL zum Erstellen der sitzungsbasierten Authentifizierung für API-Aufrufe beschrieben.

Prozedur

  1. Geben Sie Folgendes ein, um ein neues Sitzungscookie zu erstellen, das sich beim NSX Manager authentifiziert und XSRF aus dem Header abruft: 
    # curl -v -k -c session.txt -X POST -d '[email protected]&j_password=SecretPwsd3c4d' https://<manager-ip>/api/session/create 2>&1 | grep -i xsrf < x-xsrf-token: 5a764b19-5ad2-4727-974d-510acbc171c8

    In diesem Beispiel authentifiziert sich der cURL-Befehl beim Server, platziert das Sitzungscookie in der Datei „sessions.txt“ und schreibt alle HTTP-Antwortheader in die Datei „headers.txt“. Sie müssen einen Header aus „headers.txt“ verwenden – den X-XSRF-Token-Header – und diesen in nachfolgenden Anforderungen angeben.

    Sie können für das @ im Benutzernamen auch die standardmäßige Unicode-/URI-Codierung verwenden.

    Beispiel für den Sitzungsinhalt:

    # cat session.txt
      # Netscape HTTP Cookie File
      # https://curl.haxx.se/docs/http-cookies.html
      # This file was generated by libcurl! Edit at your own
        risk.
      # HttpOnly_172.182.183.135 FALSE / TRUE 0 JSESSIONID CFG588DF6DGF493C0EAEFC62685C42E1
  2. Wenn Sie zwei Sitzungen erstellen müssen, ändern Sie den Namen der „session.txt“-Dateien, damit beide Sitzungen gültig sind. 
    # curl -v -k -c session1.txt -X POST -d 'j_username= [email protected]&j_password=SecretPwsd3c4d' https://<manager-ip>/api/session/create 2>&1 | grep -i xsrf < x-xsrf-token: cbce48f3-48fc-46c0-a8e7-f2f55ebf8e15
# curl -v -k -c session2.txt -X POST -d 'j_username= [email protected]&j_password=SecretPwsd3c4d' https://<manager-ip>/api/session/create 2>&1 | grep -i xsrf < x-xsrf-token: abf1fa2c-86d5-47e4-9a0a-242424dd1761
  3. Verwenden Sie für nachfolgende Aufrufe das Sitzungscookie und den XSRF-Header aus dem vorherigen Schritt. 
    # curl -k -b session.txt -H "x-xsrf-token: 5a764b19-5ad2-4727-974d-510acbc171c8"
      https://10.182.183.135/policy/api/v1/infra/segments
      {
        "results" : [ {
          "type" : "ROUTED",
          "subnets" : [ {
            "gateway_address" : "192.168.10.1/24",
            "network" : "192.168.10.0/24"
          } ],
          "connectivity_path" :
        "/infra/tier-1s/test_t1",
          "transport_zone_path" :
        "/infra/sites/default/enforcement-points/default/transport-zones/1b3a2f36-bfd1-443e-a0f6-4de01abc963e",
          "advanced_config" : {
            "address_pool_paths" : [ ],
            "hybrid" : false,
            "multicast" : true,
            "inter_router" : false,
            "local_egress" : false,
            "urpf_mode" : "STRICT",
            "connectivity" : "ON"
          },
          "admin_state" : "UP",
          "replication_mode" : "MTEP",
          "resource_type" : "Segment",
          "id" : "seg1",
          "display_name" : "seg1",
          "path" : "/infra/segments/seg1",
          "relative_path" : "seg1",
          "parent_path" : "/infra",
          "unique_id" :
        "6573d2c9-f4f9-4b37-b410-71bded8857c3",
          "marked_for_delete" : false,
          "overridden" : false,
          "_create_user" : "admin",
          "_create_time" : 1633331197569,
          "_last_modified_user" : "admin",
          "_last_modified_time" : 1633331252660,
          "_system_owned" : false,
          "_protection" : "NOT_PROTECTED",
          "_revision" : 1
        } ],
        "result_count" : 1,
        "sort_by" : "display_name",
        "sort_ascending" : true
    Wenn Sie dieselbe Sitzung mit einem anderen Knoten im Cluster verwenden, schlägt der Befehl mit der folgenden Fehlermeldung fehl: 
    The credentials were incorrect or the account specified has been locked.","error_code":403.

    Wenn die Sitzung abläuft, antwortet NSX Manager mit der HTTP-Antwort „403 Forbidden“. Anschließend benötigen Sie ein neues Sitzungscookie und X-XSRF-Token.

  4. Um die Einstellung für das Ablaufen der Sitzung zu konfigurieren, verwenden Sie den API-Befehl „connection_timeout“. Standardmäßig läuft eine Sitzung nach 1.800 Sekunden (30 Minuten) ab. 
    PUT https://<nsx-mgr>/api/v1/cluster/api-service
GET https://<nsx-mgr>/api/v1/cluster/api-service
{
    "session_timeout": 1800,
    "connection_timeout": 30,
    "protocol_versions": [
        {
            "name": "TLSv1.1",
            "enabled": true
        },
        {
            "name": "TLSv1.2",
            "enabled": true
        }
    ],
    "cipher_suites": [
        {
            "name": "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
            "enabled": true
        },
        {
            "name": "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
            "enabled": true
        },
        {
            "name": "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
            "enabled": true
        },
        {
            "name": "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
            "enabled": true
        },
        {
            "name": "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384",
            "enabled": true
        },
        {
            "name": "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
            "enabled": true
        },
        {
            "name": "TLS_RSA_WITH_AES_128_CBC_SHA",
            "enabled": true
        },
        {
            "name": "TLS_RSA_WITH_AES_128_CBC_SHA256",
            "enabled": true
        },
        {
            "name": "TLS_RSA_WITH_AES_128_GCM_SHA256",
            "enabled": true
        },
        {
            "name": "TLS_RSA_WITH_AES_256_CBC_SHA",
            "enabled": true
        },
        {
            "name": "TLS_RSA_WITH_AES_256_CBC_SHA256",
            "enabled": true
        },
        {
            "name": "TLS_RSA_WITH_AES_256_GCM_SHA384",
            "enabled": true
        }
    ],
    "redirect_host": "",
    "client_api_rate_limit": 100,
    "global_api_concurrency_limit": 199,
    "client_api_concurrency_limit": 40,
    "basic_authentication_enabled": true,
    "cookie_based_authentication_enabled": true,
    "resource_type": "ApiServiceConfig",
    "id": "reverse_proxy_config",
    "display_name": "reverse_proxy_config",
    "_create_time": 1658339081246,
    "_create_user": "system",
    "_last_modified_time": 1658339081246,
    "_last_modified_user": "system",
    "_system_owned": false,
    "_protection": "NOT_PROTECTED",
    "_revision": 0
}
  5. Verwenden Sie den API-Befehl „/api/session/destroy“, um ein Sitzungscookie zu löschen. 
    curl -k -b cookies.txt -H "`grep x-xsrf-token headers.txt`" -X POST https://<nsx-manager>/api/session/destroy
    Beispiel: 
    curl -k -b cookies.txt -H "`grep x-xsrf-token headers.txt`" https://$TESTHOST/api/session/destroy
curl -k -b cookies.txt -H "`grep x-xsrf-token headers.txt`" https://$TESTHOST/api/v1/logical-ports
    Antwort: 
    {
    "module_name" : "common-services",
    "error_message" : "The credentials were incorrect or the account specified has been locked.",
    "error_code" : "403"
}

Nächste Maßnahme

Weitere Informationen zu den Voraussetzungen für die Authentifizierung von Benutzern mit dem sitzungsbasierten Authentifizierungsdienst finden Sie unter Integration mit VMware Identity Manager/Workspace ONE Access und Integration mit LDAP.