API Authorization
In most cases, authorization to API endpoints and service operations is based on a static or “ambient” set of access permissions. Complex authorization logic is sometimes implemented in the front end API gateway, sometimes in the backend microservice, or sometimes in both. These permissions may be based on groups, roles, or attributes of the principal contained in the API request context. Usually permission assignments do not change unless specifically acted upon by a security administrator or external permissions management service.
Quite often, permissions are left intact due to complex application requirements or burdensome API security and access reviews. This complexity and lack of nimbleness results in API clients having excessive permissions to API endpoints and the sensitive data they expose.
Over the years, I have seen the following risks manifest in different scenarios, projects, and programs.
- Accidental sensitive data leakage
- Inadvertent elevated permissions for a principal
- Account take over and lateral movement for exfiltrating data
- Deprecated security controls and authorization policies due to constantly changing APIs and underlying business justification for access
SGNL provides just-in-time access management by building a dynamic graph directory through continuous data ingestion from systems of record. Using human readable policies, access control is enforced consistently and easily across internal and external development portals and API gateways for all types of API consumers (services, internal and external developers, and partners). With Azure APIM and SGNL, you can minimize sensitive data exposure and implement a fine grained least privileged approach to secure your APIs and deliver enterprise-scale continuous adaptive access management.
With Azure APIM and SGNL, you can minimize sensitive data exposure and implement a fine grained least privileged approach to secure your APIs and deliver enterprise-scale continuous adaptive access management.
Azure APIM Authorization Considerations
Enterprise grade access management must be considered to define an overall security strategy for Azure APIM. Here are some points to consider.
Go beyond authentication - Review your security requirements and strategy for frontend and backend APIs. Determine what level of authorization controls, audit, logging, and centralized policy management you will need. These requirements go well beyond using subscription keys, OAuth 2.0, OpenID Connect, and mutual TLS.
Extend security to the backend - It is good to think about authentication and authorization from the front-end all the way to the back-end. In other words, consider the impact of the front end security controls and determine if the same requirements exist for the backend. Will you need coarse grained authorization or fine grained authorization or both?
How Does Azure APIM Work
Azure APIM acts as an API gateway. Requests for published APIs first go through Azure APIM for a variety of enterprise functions. Most common functions are security, transformation, API usage quota management, request and response routing, monitoring, and reporting.
Azure APIM allows developers to strengthen their API implementations with enterprise grade API gateway functionality. With Azure APIM, Developers are free to focus on business logic rather than operational requirements and considerations.
Benefits of Using SGNL For Azure APIM
Here are the benefits of using SGNL with Azure APIM:
Business Data Driven Continuous API Authorization. Any changes recorded in an organization’s business systems (e.g. ServiceNow, Salesforce, HRIS) of record are automatically and rapidly reflected in API access decisions without changing Azure APIM policy.
Simplified Azure APIM authorization policy. Azure APIM policies are simplified by sending a principal, action, and authorization query to SGNL for the API and endpoint being accessed. In addition, an Azure APIM policy may also send a series of JSON key/value elements in the request to SGNL. This can answer questions such as: Can a user update their own checking account information.
Real-time Audit and Comprehensive Reporting. All API access decisions are logged centrally with the policies that contributed to the decision to grant or deny access.
Centralized Human Readable Policies. Human readable policies using reusable snippets enable organizations to scale policies without losing manageability.
Consistent Authorization Decisions Across All Apps and APIs Azure APIM using SGNL provides the same decisions consistently based on centrally managed human readable policies.
Contextual API Authorization Decisions Any access decision is determined considering the context of the request. The request context received from API clients is kept intact, through Azure APIM, SGNL, and backend services.
How Does SGNL Work
SGNL continuously ingests data from systems of record to a central graph directory via resilient and performant connectors. This data not only includes identity data such as users and groups, but any relevant data required to define access policies, such as ITSM cases, or customers from CRM. Administrators can then quickly author and manage human-readable policies for granting or denying access to applications, APIs, and sensitive data. By implementing a centralized approach, SGNL provides consistency in centralized policy management, audit logging, and reporting across all assets an organization desires to protect (including APIs). These capabilities (and more) comprise SGNL’s enterprise-ready just-in-time access management platform.
Instead of having to write complex policies in APIM to evaluate access, you simply use SGNL to select policy snippets from the user interface and graphically build a human-readable policy. The SGNL APIM Policy ensures that any API call to APIM is evaluated against the latest data ingested from systems of record and the policies defined in SGNL.
Example of a real policy which denies creation of checking accounts via an API.
This human readable policy denies access for API clients acting on behalf of customer principals. when the API consumer is making a request through Azure APIM, the request is authorized by the SGNL access service.
Azure APIM and SGNL Integration
The integration between Azure APIM and SGNL is based on Azure API Management inbound policies. The inbound processing policy may be configured globally for the entire API set of endpoints or on a per API operation basis.
SGNL and Azure APIM Architecture.
Sample API
This article uses an example banking microservice. This solution demonstrates the ability to use Azure APIM front-ending a banking REST API secured by the combination of Azure APIM and SGNL’s just-in-time authorization. This banking service accepts an HTTP POST request from the Azure API Management gateway for adding a new account. The request is not sent to the backend service, if the request is denied by the SGNL Access Service based on policy.
Azure APIM Policy Expressions
The Azure APIM policy expressions below shows how you can construct an SGNL authorization request with multiple authorization queries for an incoming HTTP POST request from an API consumer. This sample takes the “principal” and “accountType” key/value pairs in the incoming JSON body in addition to the HTTP request method and backend URI path. This principal, HTTP method, and account type is then used to create the authorization request to the SGNL access service. This policy results in a Deny from SGNL which then is translated to a 403 status code back to the API consumer.
Azure APIM Policy
<inbound>
<!-- Set variables for request to SGNL Access Service. The sample gets the principal from the JSBON body, HTTP method and backend URI requesed via the request object. -->
<set-variable name="principal" value="@(context.Request.Body.As<JObject>(preserveContent: true).SelectToken("principal"))" />
<set-variable name="accountType" value="@(context.Request.Body.As<JObject>(preserveContent: true).SelectToken("account.type"))" />
<set-variable name="method" value="@(context.Request.Method)" />
<set-variable name="backendUri" value="@(context.Request.Url.Path)" />
<!-- Send the authorize request to the SGNL access service. Note: We include the principal, assetId, and action in the request. -->
<send-request mode="new" response-variable-name="response" timeout="10" ignore-error="false">
<set-url>@("https://access.sgnlapis.cloud/access/v1/evaluations")</set-url>
<set-method>POST</set-method>
<!-- Set bearer token coming in from request header. This is used to call the SGNL Access Service API. -->
<set-header name="Authorization" exists-action="override">
<value>@(context.Request.Headers.GetValueOrDefault("Authorization"))</value>
</set-header>
<!-- Set additional headers for the request to the SGNL Access Service. -->
<set-header name="Content-Type" exists-action="override">
<value>application/json</value>
</set-header>
<set-header name="Accept-Encoding" exists-action="override">
<value>gzip,deflate,br</value>
</set-header>
<!-- Set the post JSON body for the request to the SGNL Access Service using the liquid template.-->
<set-body template="liquid">
{
"principal": {
"id":"{{context.Variables["principal"]}}"
},
"queries": [{
"assetId": "{{context.Variables["backendUri"]}}",
"action": "{{context.Variables["method"]}}"
},
{
"assetId": "{{context.Variables["accountType"]}}",
"action": "Create"
}
]
}
}
</set-body>
</send-request>
<!-- Check access service resopnse. If API client is not authorized to call the API send a 401 status code. -->
<choose>
<when condition="@((int)((IResponse)context.Variables["response"]).StatusCode == 401)">
<!-- Return 401 Unauthorized -->
<return-response response-variable-name="existing response variable">
<set-status code="401" reason="SGNL Access Service - API Client Is Not Authorized" />
</return-response>
</when>
</choose>
<!-- Check access service resopnse. If Deny, then send a 403 forbidden status code to the caller. If true, APIM allows the request to continue. -->
<choose>
<when condition="@((string)((IResponse)context.Variables["response"]).Body.As<JObject>()["decisions"][0]["decision"] == "Deny")">
<!-- Return 403 Unauthorized -->
<return-response response-variable-name="existing response variable">
<set-status code="403" reason="SGNL Access Service - Not Authorized" />
</return-response>
</when>
</choose>
<choose>
<when condition="@((string)((IResponse)context.Variables["response"]).Body.As<JObject>()["decisions"][1]["decision"] == "Deny")">
<!-- Return 403 Unauthorized -->
<return-response response-variable-name="existing response variable">
<set-status code="403" reason="SGNL Access Service - Not Authorized" />
</return-response>
</when>
</choose>
<base />
</inbound>
Request Context
The following example contains a JSON document sent to a sample banking API through Azure APIM. This request is expected to open a new account with a balance of $1M, which would not be good if this was an adversary. With SGNL, you can authorize the API method (GET,POST,PUT, etc.), in addition to authorizing an action on individual assets such as name, status, and account. This article shows how you can easily implement fine grained authorization for Azure APIM enabled APIs.
{
"account": {
"id": 774893763,
"type": "Checking"
},
"name": "Aldo Pietropaolo",
"principal": "aldo@sgnl.ai.sandbox",
"status": "available",
"balance": 1000000
}
Conclusion
Using this SGNL and Azure APIM integration, organizations can reduce risk, developers can reduce authorization logic complexity and leverage a centralized access management policy platform for making complex just-in-time authorization decisions.