Compartir a través de

Tutorial de inscripción de ejemplo

  • Artículo

En este artículo se muestran los pasos necesarios para realizar una inscripción de autoservicio de tarjeta inteligente virtual. Muestra una solicitud aprobada automáticamente con un PIN establecido por el usuario.

  1. El cliente autentica al usuario y después solicita una lista de plantillas de perfil en las que el usuario autenticado puede inscribirse:

    GET /CertificateManagement/api/v1.0/profiletemplates.

  2. El cliente muestra la lista resultante al usuario. El usuario selecciona una plantilla de perfil de vSC (tarjeta inteligente virtual) con el nombre "VPN de tarjeta inteligente virtual" y UUID 97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1.

  3. El cliente recupera la directiva de inscripción de la plantilla de perfil seleccionada mediante el UUID devuelto en el paso anterior:

    GET /CertificateManagement/api/v1.0/profiletemplates/97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1/policies/enroll

  4. El cliente analiza el campo DataCollection en la directiva devuelta, teniendo en cuenta que aparece un único elemento de recopilación de datos titulado "Motivo de la solicitud". El cliente también señala que la marca collectComments está establecida en false, por lo que no solicita al usuario que escriba ninguna.

  5. Una vez que el usuario ha escrito el motivo por el que solicita los certificados, el cliente crea una solicitud:

    POST /CertificateManagement/api/v1.0/requests

{
    "datacollection":"[{“Request Reason”:”Need VPN Certs”}]",
    "type":"Enroll",
    "profiletemplateuuid":"97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1",
    "comment":""
}

  6. El servidor crea correctamente la solicitud y devuelve el URI de la solicitud al cliente: /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5.

  7. El cliente recupera el objeto de solicitud llamando al URI devuelto:

    GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5

  8. El cliente comprueba que la propiedad state de la solicitud está establecida en aprobada. Puede comenzar la ejecución de la solicitud.

  9. El cliente examina la solicitud para ver si hay una tarjeta inteligente ya asociada a la solicitud mediante el análisis del contenido del parámetro newsmartcarduuid .

  10. Dado que solo contiene un GUID vacío, el cliente debe usar una tarjeta existente que no esté ya en uso por MIM CM o crear una si la plantilla de perfil se está configurando para tarjetas inteligentes virtuales.

  11. Puesto que lo segundo se ha indicado al cliente mediante la consulta inicial para las plantillas de perfil que se pueden inscribir (paso 1), el cliente debe crear ahora un dispositivo de tarjeta inteligente virtual.

  12. El cliente recupera la directiva de tarjeta inteligente de la plantilla de perfil. Usa el UUID de la plantilla seleccionada en el paso 3:

    GET /CertificateManagement/api/v1.0/profiletemplates/97CD65FA-AF4B-4587-9309-0DD6BFD8B4E1/configuration/smartcards

  13. La directiva de tarjeta inteligente contiene la clave de administrador predeterminada para la tarjeta en la propiedad DefaultAdminKeyHex . Al crear la tarjeta inteligente, el cliente debe establecer esta clave como la clave de administrador inicial de dicha tarjeta.

  14. Una vez que se haya creado el dispositivo de tarjeta inteligente, el cliente debe asignarlo a la solicitud:

    POST /CertificateManagement/api/v1.0/smartcards

{
    "requestid":" C6BAD97C-F97F-4920-8947-BE980C98C6B5",
    "cardid":"23CADD5F-020D-4C3B-A5CA-307B7A06F9C9",
}

  15. El servidor responde al cliente con un URI al objeto de tarjeta inteligente recién creado: api/v1.0/smartcards/D700D97C-F91F-4930-8947-BE980C98A644.

  16. El cliente recupera el objeto de tarjeta inteligente:

    GET /CertificateManagement/api/v1.0/smartcards/ D700D97C-F91F-4930-8947-BE980C98A644

  17. Al comprobar el valor de la marca diversificaciónadminkey en la directiva de tarjeta inteligente obtenida en el paso 12, el cliente sabe que tiene que diversificar la clave de administración.

  18. El cliente recupera la clave de administrador propuesta:

    GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/smartcards/D700D97C-F91F-4930-8947-BE980C98A644/diversifiedkey?cardid=23CADD5F-020D-4C3B-A5CA-307B7A06F9C9

  19. El cliente debe autenticarse en la tarjeta como administrador para establecer la clave de administrador. Para hacerlo, el cliente solicita un desafío de autenticación desde la tarjeta inteligente y lo envía al servidor:

    GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/smartcards/D700D97C-F91F-4930-8947-BE980C98A644/authenticationresponse?cardid=23CADD5F-020D-4C3B-A5CA-307B7A06F9C9&challenge=CFAA62118BBD25&diversified=false

    El servidor envía la respuesta al desafío en el cuerpo de respuesta HTTP. Busque la cadena de desafío hexadecimal, conviértala a base64 y pásela como un parámetro en la dirección URL. La dirección URL devuelve otra respuesta, que se debe convertir de nuevo al formato hexadecimal.

  20. El servidor envía la respuesta al desafío en el cuerpo de respuesta HTTP y el cliente la usa para diversificar la clave de administrador.

  21. El cliente señala que el usuario debe proporcionar su pin deseado inspeccionando el campo UserPinOption en la directiva de tarjeta inteligente.

  22. Una vez que el usuario ha especificado su pin deseado en un cuadro de diálogo, el cliente realiza una autenticación de desafío-respuesta como se describe en el paso 19, con la única diferencia de que la marca diversificada ahora debe establecerse en true:

    GET /CertificateManagement/api/v1.0/ requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/smartcards/D700D97C-F91F-4930-8947-BE980C98A644/authenticationresponse?cardid=23CADD5F-020D-4C3B-A5CA-307B7A06F9C9&challenge=CFAA62118BBD25&diversified=true

  23. El cliente usa la respuesta recibida desde el servidor para establecer el PIN de usuario deseado.

  24. El cliente ya está listo para generar solicitudes de certificados. Consulta los parámetros de generación de certificados de plantillas de perfiles para determinar cómo se deben generar las claves/solicitudes.

    GET /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/certificaterequestgenerationoptions.

  25. El servidor responde con un único objeto CertificateRequestGenerationOptions serializado por JSON. El objeto incluye parámetros para la exportabilidad de la clave, el nombre descriptivo del certificado, el algoritmo hash, el algoritmo de clave, el tamaño de la clave, etc. El cliente usa estos parámetros para generar una solicitud de certificado.

  26. La solicitud de certificado individual se envía al servidor. Además, el cliente podría especificar una contraseña PFX que se debe usar para descifrar los blobs PFX cuando la plantilla de certificado especifica archivar los certificados en la ENTIDAD de certificación, es decir, la ENTIDAD de certificación genera el par de claves y, a continuación, lo envía al cliente. El cliente también puede optar por agregar algunos comentarios.

    POST /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5/certificatedata

{
   "pfxpassword":"",
   "certificaterequests":[
       "MIIDZDC…”
    ]
}

  27. Después de unos segundos, el servidor responde con un único objeto Microsoft.Clm.Shared.Certificate serializado por JSON. Al comprobar la marca isPkcs7 , el cliente aprende que esta respuesta no es un blob PFX. El cliente extrae el blob mediante la descodificación de la cadena pkcs7 y la instala.

  28. El cliente marca la solicitud como completada.

    PUT /CertificateManagement/api/v1.0/requests/C6BAD97C-F97F-4920-8947-BE980C98C6B5

{
    "status":"Completed"
}