NSX API-Authentifizierung mithilfe eines Sitzungscookies

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 mittels vIDM und Cloud Service Platform (CSP)

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 optional dieses Sitzungscookie verwenden. Dies bedeutet, dass der Sitzungsstatus spezifisch für den jeweiligen NSX Manager ist, der das Sitzungscookie generiert hat. Wenn Clients Anforderungen an die NSX Manager stellen, kann sich der Benutzer nur authentifizieren, wenn das angegebene Sitzungscookie einem der vom Server generierten Cookies entspricht. Wenn sich ein Benutzer von NSX Manager abmeldet, wird das Sitzungscookie sofort vom Reverse-Proxy des NSX Managers 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

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 > /dev/null | grep -i xsrf < x-xsrf-token: 5a764b19-5ad2-4727-974d-510acbc171c8
```
In diesem Beispiel authentifiziert sich der cURL-Befehl beim Manager, 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
```

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 > /dev/null | 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 > /dev/null | grep -i xsrf < x-xsrf-token: abf1fa2c-86d5-47e4-9a0a-242424dd1761

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 dasselbe Sitzungscookie mit einem anderen Knoten im Cluster verwenden, schlägt der Befehl mit folgender 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.

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.

Verwenden Sie GET https://<nsx-mgr>/api/v1/cluster/api-service, um einen Snapshot der aktuellen Konfiguration anzuzeigen.

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
        }        ,
        {
            "name": "TLS_ECDSA_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
}

Bearbeiten Sie den JSON-Text mit den gewünschten Werten und entfernen Sie alle Felder, die mit einem Unterstrich beginnen (_xxxxx), ausgenommen _revision.

 GET https://<nsx-mgr>/api/v1/cluster/api-service
{
    "global_api_concurrency_limit": 199,
    "client_api_rate_limit": 100,
    "client_api_concurrency_limit": 40,
    "connection_timeout": 30,
    "redirect_host": "",
    "cipher_suites": [     
      {"enabled": true, "name": "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"},
      {"enabled": true, "name": "TLS_RSA_WITH_AES_256_GCM_SHA384"},
      {"enabled": true, "name": "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"},
      {"enabled": true, "name": "TLS_RSA_WITH_AES_128_GCM_SHA256"}
      {"enabled": true, "name": "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384}",
      {"enabled": true, "name": "TLS_RSA_WITH_AES_256_CBC_SHA256"},
      {"enabled": true, "name": "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA"},
      {"enabled": true, "name": "TLS_RSA_WITH_AES_256_CBC_SHA"},
      {"enabled": true, "name": "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"},
      {"enabled": true, "name": "TLS_RSA_WITH_AES_128_CBC_SHA256"},
      {"enabled": false, "name": "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"},
      {"enabled": true, "name": "TLS_RSA_WITH_AES_128_CBC_SHA"},
  
      {"enabled": true, "name": "TLS_ECDSA_WITH_AES_256_GCM_SHA384"},
    ],
      "protocol_versions": [
        {"enabled": true, "name": "TLSv1.1"},
    {"enabled": true, "name": "TLSv1.2"}
  ]    
    "_revision": 0
}

Verwenden Sie PUT https://<nsx-mgr>/api/v1/cluster/api-service, um die aktuelle Konfiguration zu ändern.

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.