locked
Azure API hosting architecture RRS feed

  • Question

  • Architecture question.  I want to secure (OAuth 2.0) my HTTP/REST services such that they can be completely agnostic of things like authentication, authorisation, auditing, quotas, etc.  Where they run is unimportant, but for completeness they'll be Java based services running in Docker.

    I'm not interested at the moment in developer portals, etc.  This primarily for machine-machine calls from 3rd parties and from an SPA (Single Page Application) web app to the API.  Either the machine will have client creds or the web app will get the auth token from the provider (Auth0) by asking the user (our customers) to provide their username/password.  Once authenticated the web app will use the auth token for API calls.

    If I was doing this in AWS I'd have a setup like this (in fact I do have this setup and it works):

    --------

    HTTP request to API Gateway

        |-> Check Authorisation

            |-> Invoke a custom authoriser

                |-> Validate OAuth 2.0 token with external provider (Auth0 in my case)

                |-> Based on the user's metadata, create an AWS IAM policy to reflect what they can access

                |-> Return the AWS IAM policy

        |-> API Gateway evaluates the request for the specified resource in combination with the IAM policy to determine if the requestor is allowed access to the specified resource

        |-> Apply basic transformations, sign the request with a client-side certificate and invoke the real service

        |-> Get the response, apply some basic transformations (e.g. CORS stuff) and send it back to the requestor

    --------

    I can see Azure API Management can do the basic transformation stuff, I can also see you can register an external OAuth identity provider to check authentication.  I assume that I could apply a Policy through API Management to logically provide the same functions as the Custom Authoriser.

    Does that above architecture make sense in the Azure world?  Have I chosen the right components?

    Thanks

    Dan

    BTW - The Custom Authoriser in AWS is just an AWS Lambda function we wrote which calls out to Auth0 and generates a simple AWS IAM policy.

    • Edited by TeaMan_ Friday, March 10, 2017 2:50 PM clarification
    Friday, March 10, 2017 11:24 AM

Answers

  • Hi Dan,

    This seems reasonable and certainly can be achieved on Azure.

    HTTP request to API Gateway

        |-> Check Authorisation

            |-> Invoke a custom authorizer

                |-> Validate OAuth 2.0 token with external provider (Auth0 in my case)

    This can be done using either our validate-jwt policy or validate the token with Auth0 using send-request policy.

                |-> Based on the user's metadata, create an AWS IAM policy to reflect what they can access

    This can be done using Azure functions (equivalent to Lamda) or our control flow policy.

                |-> Return the AWS IAM policy

        |-> API Gateway evaluates the request for the specified resource in combination with the IAM policy to determine if the requestor is allowed access to the specified resource

    Use control flow policy.

        |-> Apply basic transformations, sign the request with a client-side certificate and invoke the real service

    We don't have a policy out of box to sign the request, but this can be done by using policy expressions.

        |-> Get the response, apply some basic transformations (e.g. CORS stuff) and send it back to the requestor

    Not a problem.

    • Marked as answer by TeaMan_ Wednesday, March 29, 2017 9:19 AM
    Wednesday, March 15, 2017 5:25 PM

All replies

  • You can refer this article: https://docs.microsoft.com/en-us/azure/api-management/api-management-howto-policies which describes, how to use policies in Azure API Management.

    Also, you can check this link: https://docs.microsoft.com/en-us/azure/api-management/api-management-policy-reference for API Management policy reference.

    Saturday, March 11, 2017 6:00 AM
  • Thanks yes, I did see those.  I was hopefully looking for an answer like "yes, that is reasonable architectural approach using Azure components and it should work"
    Monday, March 13, 2017 11:45 AM
  • Hi Dan,

    This seems reasonable and certainly can be achieved on Azure.

    HTTP request to API Gateway

        |-> Check Authorisation

            |-> Invoke a custom authorizer

                |-> Validate OAuth 2.0 token with external provider (Auth0 in my case)

    This can be done using either our validate-jwt policy or validate the token with Auth0 using send-request policy.

                |-> Based on the user's metadata, create an AWS IAM policy to reflect what they can access

    This can be done using Azure functions (equivalent to Lamda) or our control flow policy.

                |-> Return the AWS IAM policy

        |-> API Gateway evaluates the request for the specified resource in combination with the IAM policy to determine if the requestor is allowed access to the specified resource

    Use control flow policy.

        |-> Apply basic transformations, sign the request with a client-side certificate and invoke the real service

    We don't have a policy out of box to sign the request, but this can be done by using policy expressions.

        |-> Get the response, apply some basic transformations (e.g. CORS stuff) and send it back to the requestor

    Not a problem.

    • Marked as answer by TeaMan_ Wednesday, March 29, 2017 9:19 AM
    Wednesday, March 15, 2017 5:25 PM