在组合服务中管理多个订阅密钥 [英] Managing Multiple Subscription Keys Inside a Composition Service

问题描述

我有一个在外部客户端调用的Azure API管理内部注册的合成API，此合成服务将调用其他也在API管理内部注册并且还需要订阅密钥的API

I have a composition API that is registered inside Azure API Management that is called by external clients, this composition service will call other APIs which are also registered inside API Management and also need a subscription key

问题是否存在使用Azure API管理在我的撰写方案类型中管理订阅密钥的指南或最佳实践

Question Is there guidance or best practises for managing subscription keys in my type of composition scenario using Azure API Management

推荐答案

不确定指导的含义.有几件事要记住:

Not sure what you mean by guidance. There are a few things to keep in mind:

• 确保您的订阅密钥不会冲突. IE.如果Composition APIM将用于调用它的订阅密钥传递给后端APIM，那么您很可能会收到401.因此，您需要确保在处理期间在Composition APIM上删除该密钥，或者用另一个用于后端APIM的密钥覆盖它./li>
• 您可以通过在组合APIM和后端APIM上为预订密钥使用不同的标头/查询参数名称来防止它.请在此处查看subscriptionKeyParameterNames: https://docs.microsoft.com/zh-cn/rest/api/apimanagement/api/createorupdate
• 使用命名值来管理机密.您可以创建一个命名值，将其标记为秘密，并在策略中使用它而无需透露其值.

• Make sure your subscription keys do not collide. I.e. if Composition APIM passes subscription key used to call it to backend APIM you're likely to get 401. So you need to make sure to either remove key at composition APIM during processing time, or overwrite it with another key intended to backend APIM.
• You can protect against it by using different header/query parameter names for subscription keys at composition and backend APIMs. See subscriptionKeyParameterNames here: https://docs.microsoft.com/en-us/rest/api/apimanagement/api/createorupdate
• Use Named values to manage secrets. You can create a named value, mark it as secret and use it inside policy without revealing it's value.

这篇关于在组合服务中管理多个订阅密钥的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！