La autenticación de certificado de cliente o autenticación TLS mutua es una forma de que un cliente se autentique en un servidor mediante un certificado. El certificado del cliente lo emite una autoridad certificadora (CA) confiable y se utiliza para autenticar al cliente en el servidor. Luego, el servidor puede usar la información del certificado para autenticar al cliente y autorizar el acceso a la API. Esta es una de las formas más seguras para que los clientes se autentiquen en sus API.
Al configurar la autenticación de certificados de cliente en Azure API Management Service, hay dos formas diferentes de hacerlo. La primera forma es usar la que tienen en la documentación principal de Microsoft carga cada certificado en su servicio de administración de API y hace que el servicio verifique si el certificado está en la lista de certificados aprobados. Este es un proceso muy manual y no es escalable y ya no lo recomiendan los estándares de la industria. La segunda forma es utilizar una autoridad de certificación y hacer que el servicio de administración de API valide que el emisor del certificado sea una autoridad de certificación confiable y pase el nombre del sujeto a su servicio backend para su autorización. Esta es una solución mucho más escalable debido a que solo tiene que administrar los certificados de CA, e incluso permite la rotación de certificados de autoservicio para sus clientes sin tener que involucrar a su equipo.
El primer paso del proyecto es comprender la arquitectura de la solución. El siguiente diagrama muestra la arquitectura de la solución. Cuando el cliente se registre para su servicio, enviará una solicitud de firma de certificado (CSR) (aprenda cómo crear uno) entonces su servicio registrará al cliente y emitirá el primer certificado para el cliente. El cliente utilizará ese certificado para autenticarse en el servicio de administración de API. El servicio de administración de API validará el certificado y pasará el nombre del sujeto al servicio backend para su autorización. Luego, el servicio de backend validará el nombre del sujeto y autorizará la solicitud. Si usa EZCA, el cliente configurará la herramienta de rotación de certificados de código abierto para renovar automáticamente el certificado antes de que caduque. Dado que el servicio de administración de API utilizará la validación de CA, no es necesario que su servicio registre el nuevo certificado (eso es lo mejor de la autenticación de certificados basada en sujetos).
Para comenzar la implementación, debemos configurar una Autoridad de certificación (CA) que pueda emitir certificados de cliente. Puede utilizar cualquier CA; sin embargo, recomendamos usar EZCA, que es una CA basada en la nube que admite la rotación automática de certificados con una herramienta de rotación de certificados de código abierto para sus clientes y fácil integración API para crear el primer certificado del usuario. Está totalmente gestionado y no tienes que preocuparte por el mantenimiento de la CA. Vea este vídeo sobre cómo crear una autoridad de certificación en Azure.
Ahora que hemos creado la CA, debemos agregar el certificado de CA al servicio de administración de API. Para hacer esto, necesitamos descargar el certificado de CA de la CA. En EZCA, puede descargar el certificado de CA desde la página de detalles de CA. Una vez que tenga el certificado de CA, puede cargarlo en el Servicio de administración de API. Para hacer esto, vaya al Servicio de administración de API y haga clic en el menú “Certificados”, en la página de certificados, asegúrese de estar en la pestaña Certificados de CA, luego haga clic en “Agregar” y cargue el certificado de CA raíz y su CA emisora. Certificado. Obtenga más información sobre root vs emisión de CA aquí.
El último paso es configurar la política de entrada para validar el certificado del cliente. Para hacer esto, vaya al Servicio de administración de API y haga clic en el menú “API”, luego haga clic en la API en la que desea habilitar la autenticación de certificado de cliente y, en la sección de procesamiento entrante, haga clic en “Agregar política” y seleccione “Otras políticas”.
En el editor de políticas, agregue la siguiente política:
<inbound>
<base />
<validate-client-certificate
validate-revocation="true"
validate-trust="true"
validate-not-before="true"
validate-not-after="true"
ignore-error="false" />
<!-- Setting the client certificate subject as a header -->
<set-header name="X-Client-Cert-Subject" exists-action="override">
<value>@(context.Request.Certificate.Subject)</value>
</set-header>
</inbound>
Esta política validará que el certificado sea emitido por una de sus CA aprobadas (y que no haya sido revocado) y pasará el nombre del sujeto al servicio backend como un encabezado ‘X-Client-Cert-Subject’. Para obtener más información sobre la política de validación-certificado-cliente, puede leer esta Documentación de Microsoft. Ahora su servicio puede validar el nombre del sujeto y autorizar la solicitud.
