En este tema, se describe cómo utilizar la autenticación basada en sesiones de NSX para generar una cookie JSESSIONID cuando se utiliza la API. Utilice este método para reducir el número de veces que tiene que introducir su nombre de usuario y su contraseña. Puede utilizar este tipo de autenticación con la autenticación LDAP y vIDM.

NSX utiliza varios mecanismos diferentes para autenticar usuarios de NSX. Entre ellas, se incluyen las siguientes:

  • Autenticación HTTP
  • Autenticación basada en sesión
  • Autenticación basada en certificado o identidad principal
  • Inicio de sesión único mediante vIDM y RBAC

NSX utilizará un nombre de usuario y una contraseña para generar una cookie de sesión al crear la sesión. Una vez creada la cookie de sesión, las solicitudes de API posteriores podrán utilizar esta cookie de sesión en lugar de las credenciales de nombre de usuario y contraseña. Esto significa que el estado de la sesión será local para el servidor en el que se realiza. Cuando los clientes realizan solicitudes a NSX Manager, solo permite que los clientes se autentiquen si el identificador de sesión que presentan coincide con uno de los identificadores generados por el servidor. Cuando un usuario cierra sesión en NSX Manager, el identificador de la sesión se elimina de inmediato y no se puede volver a utilizar. Las sesiones inactivas se cerrarán automáticamente al agotarse el tiempo de espera, o bien puede eliminarlas mediante la API.

El acceso mediante la solicitud de API genera detalles del registro de auditoría. Este registro siempre está habilitado y no se puede deshabilitar. La auditoría de sesiones se inicia al iniciar el sistema. Los mensajes de registro de auditoría incluyen el texto audit="true" en los datos estructurados forme parte del mensaje de registro.

En este ejemplo, se describe el uso de cURL para crear una autenticación basada en sesiones para llamadas de API.

Procedimiento

  1. Para crear una nueva cookie de sesión que se autentique en NSX Manager y recupere xsrf del encabezado, introduzca: 
    # 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

    En este ejemplo, el comando cURL se autentica en el servidor, coloca la cookie de sesión en el archivo sessions.txt y escribe todos los encabezados de respuesta HTTP en el archivo headers.txt. Deberá utilizar uno de los encabezados de headers.txt, el encabezado x-xsrf-token, para usarlo en solicitudes posteriores.

    También puede utilizar la codificación Unicode/URI estándar para la @ en el nombre de usuario.

    A continuación se incluye un ejemplo del contenido de la sesión:

    # 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 necesita crear dos sesiones, cambie el nombre de los archivos de session.txt para que ambas sesiones sean válidas. 
    # 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. Para las llamadas posteriores, utilice la cookie de sesión y el encabezado xsrf del paso anterior. 
    # 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 utiliza la misma sesión con otro nodo del clúster, se producirá un error en el comando y aparecerá el siguiente mensaje: 
    The credentials were incorrect or the account specified has been locked.","error_code":403.

    Cuando la sesión caduque, NSX Manager responderá con una respuesta HTTP 403 Prohibido. A continuación, deberá obtener una nueva cookie de sesión y x-xsrf-token.

  4. Para configurar la opción de caducidad de la sesión, utilice el comando de API connection_timeout. La caducidad predeterminada de la sesión se establece en 1800 segundos (30 minutos). 
    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. Para eliminar una cookie de sesión, utilice el comando de API /api/session/destroy. 
    curl -k -b cookies.txt -H "`grep x-xsrf-token headers.txt`" -X POST https://<nsx-manager>/api/session/destroy
    Por ejemplo: 
    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
    Respuesta: 
    {
    "module_name" : "common-services",
    "error_message" : "The credentials were incorrect or the account specified has been locked.",
    "error_code" : "403"
}

Qué hacer a continuación

Para revisar los requisitos para autenticar usuarios con el servicio de autenticación compatible basado en sesiones, consulte Integración con VMware Identity Manager/Workspace ONE Access o Integración con LDAP.