Autenticazione di NSX API tramite i cookie di sessione

In questo argomento viene descritto come utilizzare l'autenticazione basata su sessione NSX per generare un cookie JSESSIONID quando si utilizza l'API. Utilizzare questo metodo per ridurre il numero di volte che è necessario immettere nome utente e password. È possibile utilizzare questo tipo di autenticazione con autenticazione vIDM e LDAP.

NSX utilizza diversi meccanismi per autenticare gli utenti NSX. Includono:

Autenticazione HTTP
Autenticazione basata sulla sessione
Identità entità o autenticazione basata su certificato
Accesso single sign-on mediante vIDM e RBAC

NSX utilizza un nome utente e una password per generare un cookie di sessione durante la creazione della sessione. Una volta creato il cookie di sessione, le richieste API successive possono utilizzare il cookie di sessione anziché le credenziali di nome utente e password. In questo modo, lo stato della sessione è locale per il server in cui viene eseguita. Quando i client effettuano richieste a NSX Manager, esso consente ai client di eseguire l'autenticazione solo se l'ID di sessione che presentano corrisponde a uno degli ID generati dal server. Quando un utente si disconnette da NSX Manager, l'identificatore della sessione viene eliminato immediatamente e non può essere riutilizzato. Le sessioni inattive scadono automaticamente o possono essere eliminate tramite l'API.

L'accesso utilizzando la richiesta API genera i dettagli del registro di controllo. Questa registrazione è sempre abilitata per impostazione predefinita e non può essere disabilitata. Il controllo delle sessioni inizia all'avvio del sistema. I messaggi del registro di controllo includono il testo audit="true" nella parte dei dati strutturati del messaggio di log.

In questo esempio viene descritto l'utilizzo di cURL per creare l'autenticazione basata su sessione per le chiamate API.

Procedura

Per creare un nuovo cookie di sessione che esegue l'autenticazione in NSX Manager e recupera XSRF dall'intestazione, immettere:
```
# 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 questo esempio, il comando cURL esegue l'autenticazione nel server, posiziona il cookie di sessione nel file sessioni.txt e scrive tutte le intestazioni di risposta HTTP nel file intestazioni.txt. Sarà necessario utilizzare una delle intestazioni di headers.txt, l'intestazione x-xsrf-token, da fornire nelle richieste successive.

È inoltre possibile utilizzare la codifica unicode/URI standard per il simbolo @ nel nome utente.

Di seguito è disponibile un esempio del contenuto della sessione:
```
# 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
```

Se è necessario creare due sessioni, cambiare il nome dei file sessione.txt in modo che entrambe le sessioni siano valide.

# 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

Per le chiamate successive, utilizzare il cookie della sessione e l'intestazione xsrf del passaggio precedente.

# 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

Se si utilizza la stessa sessione con un altro nodo nel cluster, il comando non riesce e viene visualizzato il messaggio di errore:

The credentials were incorrect or the account specified has been locked.","error_code":403.

Quando la sessione scade, NSX Manager risponde con una risposta HTTP 403 Negato. È quindi necessario ottenere un nuovo cookie di sessione e x-xsrf-token.

Per configurare l'impostazione di scadenza della sessione, utilizzare il comando dell'API connection_timeout. La scadenza della sessione predefinita è impostata su 1800 secondi (30 minuti).

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
}

Per eliminare un cookie di sessione, utilizzare il comando /api/session/destroy API.

curl -k -b cookies.txt -H "`grep x-xsrf-token headers.txt`" -X POST https://<nsx-manager>/api/session/destroy

Ad esempio:

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

Risposta:

{
    "module_name" : "common-services",
    "error_message" : "The credentials were incorrect or the account specified has been locked.",
    "error_code" : "403"
}

Operazioni successive

Per esaminare i requisiti per l'autenticazione degli utenti con il servizio di autenticazione supportato basato sulla sessione, vedere Integrazione con VMware Identity Manager/Workspace ONE Access o Integrazione con LDAP.