Hoy os contaré, como realizar llamadas autenticadas en el API Manager de Azure sin necesidad de pasar el SubscriptionKey como parte del request.

Cuando quieres tener monitorizadas (por ejemplo para facturarlas después) las llamadas que se hacen al API Manager de Azure, los desarrolladores deberían incluir una cabecera Ocp-Apim-Subscription-Key con un subscription key válido. También pueden incluir un parámetro en el query string que se llame «subscription-key» -esto debe ser un legado de Apiphany porque no lo he visto en la documentación pero sí que funciona-. El problema viene cuando la llamada se hace desde una aplicación cliente, por ejemplo desde el javascript de una web. No queda bonito que haya una clave en el código. Claro que podemos (y debemos) usar otras medidas de seguridad como bloquear CORS por defecto o bloqueo por IP, pero de paso no está de más darles a los desarrolladores la posibilidad de hacer llamadas sin necesidad de pasar el subscription key, pero haciendo algo para que esas llamadas se queden registradas para computárselas al desarrollador en cuestión.

Para esto, podemos usar las políticas avanzadas y la información del contexto que nos proporciona el API Manager. Pero vayamos paso a paso:

1. Para que una API sea accesible sin pasárle un subscription key, lo primero que necesitaremos será un producto que no requiera de una suscripción para llamarlo. Sólo necesitas darle un nombre y descripción y desmarcar el check de que requiera suscripción.
2. A continuación tienes que incluir la API en cuestión en el producto.

Desde este momento ya podremos hacer llamadas con Postman o cualquier otra cosa sin pasar un subscription key. Ahora bien, al entrar en las analíticas veremos que están como anónimas.

3. A continuación deberemos ir a las políticas de la operación en cuestión. En ella podremos usar la política choose y la propiedad del contexto Subscription para distinguir las llamadas anónimas de las que no lo son.

<choose>
	<when condition="@(context.Subscription != null)">
		...
	</when>
	<otherwise>
		...
	</otherwise>
</choose>

De este modo, en el primer hueco podréis dejar lo que ya tuvieseis para hacer la llamada y en el else de abajo podréis trucar las llamadas anónimas.

4. El siguiente paso es que elijáis cualquier cosa del contexto que os sirva para identificar a quien realiza la llamada, desde la cabecera Referrall, a un JWT que se genere usando como secreto el subscription key que sólo tú y el desarrollador llamante conocéis. Lo simple o complicado que lo hagáis es cosa vuestra, pero influirá en que alguien que vea el código del cliente pueda o no pueda replicar las llamadas.
5. A continuación, ya sabiendo de quien proviene la llamada, podéis usar las políticas de reescritura para volver a llamar al propio API Manager, incluyendo una cabecera con el subscription key que te interese.

<set-backend-service base-url="https://apimanagerhost.azure-api.net/service/" />
<rewrite-uri template="operation" />
<choose>
	<when condition="@(context.Property = "value")">
		<set-header name="Ocp-Apim-Subscription-Key">
			<value>1234subscrition5key67890</value>
		</set-header>
	</when>
	<when condition="@(context.Property = "value2")">
		<set-header name="Ocp-Apim-Subscription-Key">
			<value>1234subscrition5key200000</value>
		</set-header>
	</when>
	<otherwise>
		<return-response>
			<set-status code="401" reason="Unauthorized" />
		</return-response>
	</otherwise>
</choose>

Con esto tendréis canalizado el flujo de las requests anónimas que se realicen y podréis rehacerlas una segunda vez ya autenticadas.

Post By Javi López (27 Posts)

Arquitecto/desarrollador, creativo, buscador de nuevas soluciones y modelos de negocio, crítico constructivo y ex muchas cosas

Website: → JaviLopezG

Connect

API, API Manager, Autenticación, Azure