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 RBAC

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 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 local pour le serveur sur lequel il est exécuté. Lorsque les clients effectuent des demandes à NSX Manager, il autorise uniquement les clients à s'authentifier si l'ID de session qu'ils présentent correspond à l'un des ID générés par le serveur. Lorsqu'un utilisateur se déconnecte de NSX Manager, l'identifiant de la session est immédiatement éliminé 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

  1. 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 -i -k -c session.txt -X POST -d '[email protected]&j_password=SecretPwsd3c4d' https://<nsx-manager>/api/session/create 2>&1 > response.txt

    Par cet exemple, la commande cURL s'authentifie sur le serveur, place le cookie de session dans le fichier sessions.txt et écrit les en-têtes et la réponse dans le fichier response.txt. Vous devrez utiliser l'un des en-têtes session.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
  2. Si vous devez créer deux sessions, modifiez le nom des fichiers session.txt afin que les deux sessions soient valides. 
    curl -i -k -c session.txt -X POST -d '[email protected]&j_password=SecretPwsd3c4d' https://<nsx-manager>/api/session/create 2>&1 > response.txt
# curl -i -k -c session2.txt -X POST -d 'j_username= [email protected]&j_password=SecretPwsd3c4d' https://<nsx-manager>/api/session/create 2>&1 > response2.txt
  3. Pour les appels suivants, utilisez le cookie de session et l'en-tête xsrf de l'étape précédente. Notez que le response.txt correspond au fichier dans les étapes précédentes. 
    # curl -k -b session.txt -H "x-xsrf-token: `grep -i xsrf response.txt | awk '{print $2}'`" https://<nsx-manager>/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 la même 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.

  4. Pour configurer le paramètre d'expiration de session, utilisez la commande connection_timeout API. L'expiration de la session par défaut est définie sur 1 800 secondes (30 minutes). 
    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. Pour supprimer un cookie de session, utilisez la commande API /api/session/destroy. 
    curl -k -b session.txt -H "x-xsrf-token: `grep -i xsrf response.txt | awk '{print $2}'`" https://<nsx-manager>/api/v1/node/version
    Par exemple : 
    curl -k -b session.txt -H "x-xsrf-token: `grep -i xsrf response.txt | awk '{print $2}'`" https://<nsx-manager>/api/v1/node/version
    {
    "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.