Creating and Configuring an Azure API Management System of Record

Prerequisites

  • A running Azure API Management Service

Permissions Required

  • Permissions to Administer Azure API Management through an Azure RBAC Role, or delegated permissions

Configuring Azure API Management

  1. Launch the Azure API Management blade from the Azure Portal

  2. Select the API Management Service you want to synchronize to SGNL from the list of API Management Services

  3. From the left navigation menu, scroll down to “Deployment and infrastructure” and select “Management API”

    Azure APIM - Management API

  4. Ensure your management API is enabled

    Azure APIM - Enable Management

  5. Generate a Primary Key and Generate an Access Token

    Azure APIM - Generate Primary Key

  6. Take note and copy the “Access Token” you’ll use that in a moment

  7. Scroll on the left navigation bar to “Properties”

    Azure APIM - Properties

  8. From Service Information, copy the Id, it should look something like:

    • /subscriptions/a30ee614-4b7c-4e7a-a7f3-12c479a91ba0(my-subscription-Id)/resourceGroups/my-Resource-Group/providers/Microsoft.ApiManagement/service/my-ServiceName
  9. Extract the necessary configuration information from the Id, save this information, you’ll need it to enter into SGNL:

    • Your Subscription Id
    • Your Resource Group Name
    • Your Service Name
  10. Also from Properties, copy your Gateway URL Address, it should look something like this:

  11. Copy your base URL, you’ll need that in a moment

Configuring SGNL

  1. Login to the SGNL Console

  2. From the left menu, select Systems of Record

  3. Add a New System of Record and select Azure API Management

  4. Give the new System of Record a friendly Display Name and helpful Description

  5. Enter the following data into SGNL:

    • Auth Token: The Access Token you copied from Azure APIM above
    • Base URL: The base URL you copied above (e.g. my-base-url)
    • Subscription Id: The subscription Id you copied above, this will be a long UUID
    • Resource Group Name: The Resource Group Name from above
    • Service Name: Your Service Name from above
    • API Version: Recommended to use the current, stable version of the Azure API Management API, “2021-08-01”
  6. Once configured, click Continue to save your System of Record and move on to configuring Entities

  7. From the Entities tab, click on ‘Edit Attributes’ to select the entities and attributes you will need synchronized into SGNL to be used in your specified SGNL policies

    • Refer to Azure API Management’s documentation for descriptions of the attributes you choose to synchronize into SGNL: User, Group, Product
    • E.g. If you want to create a policy that AzureAPIM Users with properties__state: active are allowed to access certain assets, you will need to select the following attribute from the AzureAPIM User entity: state in addition to principal identifiers such as properties__email or id
  8. (If applicable) If you will be synchronizing entities and attributes from 2+ different Systems of Record into SGNL to define policies, click on Add join rule to specify the attribute(s) that will join the entities you’ve configured to synchronize from Azure API Management to other entities in the SGNL Graph

    • You only have to specify a join rule from one System of Record. For instance, if you specify a join rule between AzureAPIM Users and Azure Active Directory Users, you only need to configure the relationship from either the AzureAPIM or the Azure AD System of Record
    • E.g. If User Employee Emails are found in your AzureAPIM and Azure AD system and are consistent, you can choose the Employee Email Attribute in this AzureAPIM Instance and the Employee Id Attribute in your Azure AD System of Record to join these entities together
    • Join rules should only be used for entities that represent the same object across 2+ different Systems of Record. For instance, if a User in AzureAPIM represents the same User as one in Azure AD, it is a good candidate for a join rule
      • However, a User in Azure AD and a Group in ServiceNow represent different objects and are therefore not good candidates for join rules, and instead should have custom relationships created via the Relationships API. Additionally, if a User in Azure AD is not the same User as one in ServiceNow, it is not a good candidate for a join rule
  9. Save the Configuration