Layer7 API Management

Hello,

Is there a reference to how API Secrets are to be used?  I understand how API Keys are evaluated and I believe this is incorporated into a portal integration include fragment.  However, I do not see how secrets can be used.

Thanks,

Alejandro

An API key is like an app's username. An API secret is its password. At a minimum, an app needs to use it's API key to identify itself to the gateway when enforcing API management policies. However, using only an API key is not secure. You could use both the API key and secret like you would use a username and password combination, but most of our customers also use OAuth. When integrated with the portal, an app's API key and secret become that app's OAuth client ID and secret.

Ben,

Thanks.  Your description of the concepts map to how I see them.  However, my question was more about how API Secrets are evaluated.  Is there a fragment that could be used to evaluate secrets similar to how API Keys are evaluated?  Or is this strictly used in the OAuth context? 

I don't use OAuth at the moment, but was interested in possibly using API Keys and Secrets for authorization.

Thanks,

Al

We provide a sample policy fragment and template that can be used in the policies of APIs that enforce API management depending on whether you publish the APIs from the gateway or from the portal. Those samples only look for the API key to be sent some way (and usually as an apikey query string parameter), and then they use the Look Up API Key policy assertion to validate just it and not the secret. However, that assertion outputs an ${apiKeyRecord.secret} context variable. So, you'd just need to change the policy fragment and template to also require the API secret be sent by the API consumer, and then after using the Look Up API Key assertion, compare its value to the ${apiKeyRecord.secret}. There are many ways a consumer could send both its API key and secret, including but not limited to, using HTTP Basic Auth, HTTP headers, query string parameters, etc.

Thanks Ben!  This was helpful.  That was the missing link for me.  I wasn't aware that the assertion populated the additional context variable for comparison.

Alejandro

Just for future information to anyone that stumbles on this. If you hover over an assertion, a little popup will display the list of context variables that the assertion sets. Alternatively, if you right click an assertion and click on "View Info" from the drop-down, it will display both the context variables that the assertion sets as well as the context variables that the assertion is using.

--Azad

Hi Ben,

Can I get a copy of the sample policy files you refer to in your answer?

"We provide a sample policy fragment and template that can be used in the policies of APIs that enforce API management depending on whether you publish the APIs from the gateway or from the portal"

I assume the samples include the encapsulated Look Up API Key policy assertion as I don't see that in our installation of the API Gateway.

Thanks

Adrian

The sample policy fragment, template and Look Up API Key assertion come with the developer portal installation artifacts, and our imported/installed on your gateway during the portal installation and gateway integration.