Authentification NSX API à l'aide d'un cookie de session

Cette rubrique décrit comment utiliser l'authentification basée sur une session NSX pour générer un cookie JSESSIONID lors de l'utilisation de l'API. Utilisez cette méthode pour réduire le nombre de fois que vous devez entrer votre nom d'utilisateur et votre mot de passe. Vous pouvez utiliser ce type d'authentification avec l'authentification vIDM et LDAP.

NSX utilise plusieurs mécanismes différents pour authentifier les utilisateurs NSX. Il s'agit notamment des éléments suivants :

Authentification HTTP
Authentification basée sur une session
Authentification par identité de principal ou par certificat
Authentification unique à l'aide de vIDM et de Cloud Service Platform (CSP)

NSX utilise un nom d'utilisateur et un mot de passe pour générer un cookie de session lors de la création de la session. Une fois le cookie de session créé, les demandes d'API suivantes peuvent aussi utiliser ce cookie de session au lieu des informations d'identification du nom d'utilisateur et du mot de passe. Cela signifie que l'état de la session est spécifique au NSX Manager particulier qui a généré le cookie de session. Lorsque les clients effectuent des demandes à NSX Manager, il autorise uniquement les clients à s'authentifier si le cookie de session qu'ils présentent correspond à l'un des cookies générés par le gestionnaire. Lorsqu'un utilisateur se déconnecte de NSX Manager, le cookie de la session est immédiatement éliminé du proxy inverse du NSX Manager et ne peut pas être réutilisé. Les sessions inactives expirent automatiquement ou vous pouvez les supprimer à l'aide de l'API.

L'utilisation à l'aide de la demande d'API génère les détails du journal d'audit. Cette journalisation est toujours activée et ne peut pas être désactivée. L'audit des sessions est initié au démarrage du système. Les messages de journal d'audit se distinguent par le texte audit="true" placé dans la partie des données structurées du message de journal.

Cet exemple décrit l'utilisation de cURL pour créer une authentification basée sur une session pour les appels d'API.

Procédure

Pour créer un cookie de session qui s'authentifie auprès de NSX Manager et récupère xsrf à partir de l'en-tête :
```
# 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
```
Dans cet exemple, la commande cURL s'authentifie sur le gestionnaire, place le cookie de session dans le fichier sessions.txt et écrit tous les en-têtes de réponse HTTP dans le fichier en-têtes.txt. Vous devrez utiliser l'un des en-têtes des en-têtes.txt, l'en-tête x-xsrf-token, pour fournir dans les demandes suivantes.

Vous pouvez également utiliser le codage unicode/URI standard pour @ dans le nom d'utilisateur.

Voici un exemple de contenu de session :
```
# 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
```

Si vous devez créer deux sessions, modifiez le nom des fichiers session.txt afin que les deux sessions soient valides.

# 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

Pour les appels suivants, utilisez le cookie de session et l'en-tête xsrf de l'étape précédente.

# 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

Si vous utilisez le même cookie de session avec un autre nœud du cluster, la commande échoue avec le message d'erreur suivant :

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

Lorsque la session expire, NSX Manager répond avec une réponse 403 Forbidden HTTP. Vous devez ensuite obtenir un nouveau cookie de session et x-xsrf-token.

Pour configurer le paramètre d'expiration de session, utilisez la commande connection_timeout API. L'expiration de la session par défaut est de 1 800 secondes (30 minutes).

Utilisez GET https://<nsx-mgr>/api/v1/cluster/api-service pour afficher un snapshot de la configuration actuelle.

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
}

Modifiez le fichier JSON avec les valeurs souhaitées et supprimez tous les champs de trait de soulignement (_xxxxx), à l'exception de _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
}

Utilisez PUT https://<nsx-mgr>/api/v1/cluster/api-service pour modifier la configuration actuelle.

Pour supprimer un cookie de session, utilisez la commande API /api/session/destroy.

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

Par exemple :

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

Réponse :

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

Que faire ensuite

Pour vérifier les exigences d'authentification des utilisateurs avec votre service d'authentification pris en charge par session, reportez-vous à Intégration avec VMware Identity Manager/Workspace ONE Access ou à Intégration avec LDAP.