Protecting Mulesoft with SGNL

Introduction

Protected Systems are applications, services, or infrastructure that you want to protect with SGNL. In this guide, we’ll enhance access control for your APIs by integrating SGNL with Mulesoft to enable continuous access evaluations. Not only will adding SGNL enhance the overall security posture of your API Gateway/Management Platform, it will also provide centralized control, visibility, and audit for access to business critical APIs. If you’re not sure if a Mulesoft and SGNL Integration is right for your enterprise, watch the video below to learn more.

With this integration, Mulesoft need not know about the policies, systems of record, or any of the data in SGNL - it simply needs to pass to SGNL:

• Who/What is requesting the access (The Principal)
• (Optional) What is attempting to be accessed (The Asset)
• (Optional) What operation is being attempted on the asset (The Action)
• An access token that ensures the Protected System is a legitimate caller into SGNL

Prerequisites

• An existing Mulesoft deployment
• A SGNL Client
• A SGNL User Account with Admin privileges
• At least 1 system of record integrated to SGNL, containing principals and (optionally) assets that will be evaluated in access evaluations
• (Optional) 1 or more policies that you want assigned to the integration

Creating a Protected System in SGNL

1. Log-In to your SGNL Client with an Admin Account
2. From the left navigation pane, select Protected Systems and Add, or simply click Add from the SGNL Dashboard
3. Select ‘Mulesoft’ from the API Gateways category in the list of integrations
4. Give your integration a descriptive display name and description
5. Specify the Default Policy to be applied to Mulesoft
   • Allow: If no policies provide a decision for an access request, SGNL will respond to the access request with an Allow decision
   • Deny: If no policies provide a decision for an access request, SGNL will respond to the access request with a Deny decision
6. Next, you’ll need to configure which identifier Mulesoft is using to describe your user/principal
   • This may be an email address or Username that can be found in your IdP, or an EmployeeID in your HRIS system. This should be in the format of the Principal ID of the user that will request access to the Protected System.
   • e.g. If an Okta user will be requesting access to this Protected System, Mulesoft, the principal identifier should be the Okta email address.
7. You’ll also need to define the types of Assets that Mulesoft is protecting
   • This might be customer identifiers sourced your CRM system, or products that your customers are buying
8. Once configured, click Continue to save your Mulesoft configuration and move on to other configuration steps

Configuring Authentication

1. Authentication ensures that only authorized systems can make requests into SGNL, as well as verifying the identity of an integration in order to effectively evaluate Policies - to access Authentication settings, open your Mulesoft protected system and select the Authentication tab

   

2. Click Generate Token

3. Give your token a descriptive name so that you know how it’s being used in the future and click to Generate Token

   

4. On the next screen, copy the token - this will be used by Mulesoft to make access requests to SGNL using the SGNL Access Service API

   Note: The value of this token is not available again after this screen, so ensure you securely store it for steps later in this guide

   

Integrating Mulesoft with SGNL

Mulesoft supports an http request connector that allows for integrating an external authorization service with the Mulesoft flow. This configuration-driven approach sends the http(s) request to the external SGNL authorization service, receiving the response which is then made available to the rest of the Mule flow. The sample flow we’ll walk through in this guide involves a listener, transform, a request out to SGNL, and the final result that’s delivered to the caller.

Configuring the Listener

In this example, we implement a HTTP(S) listener on port 8081. This is to show an example resource endpoint for a resource only accessible to principals who meet the criteria of our SGNL policy.

Configuring the Transform Message

The transform message allows for extracting the incoming request headers, requestUri, and HTTP(s) method (e.g., POST,GET). The output of the transformation is a JSON document with the requested information. This information is then sent to the SGNL_Request component.

output application/json
---
{
	"token": attributes.headers.Authorization,
	"principal": attributes.headers.principal,
	"path": attributes.requestUri,
	"action": attributes.method,
	"contractId": attributes.headers.contractId
}

The token is the token that you copied from SGNL earlier in this guide. This sample takes the principal out of a header, but can also come from an OIDC provider via a JWT token in production environments. The action is the HTTP(S) method, and the contractId is used as the asset identifier.

Configuring the Request

The SGNL Request component is a standard Mulesoft http(s) request connector that calls the SGNL REST API.

Below is a sample of the request configuration.

The followinrequestg Body content allows the http(s) connector to send the principal, assetId (e.g. contractId), and an action such as Get or Post.

{
	"principal": {
		"id": payload.principal
	},
	"queries": [{
		"assetId": payload.contractId,
        "action": payload.action
	}]
}

Configuring the Response

Finally, the set payload component simply retrieves the payload returned from the SGNL Access Service and sends it to the API client.

At this point, it’s likely that all decisions will either be Allow or Deny, based on the Default Decision you’ve selected for the Mulesoft Integration - if that’s the case, you’re ready to start assigning policies.

Assigning Policies

1. Once the Mulesoft integration is created, you can start assigning versions of Policies - to get started, select Policies from the tabs in your newly created integration

   

2. Select ‘Assign Policies’

3. Select:

   • The Policies you want to apply to the integration with the check box
   • The version of the Policy you want applied

   

4. Click Next once you have the Policies and Versions configured as is appropriate

5. Select the Enforcement mode for the Policies you chose in the previous step

   • Simulated: Policy Versions that are being simulated will only log their access decision in the SGNL logs and will not impact the access decision that SGNL hands back to an integration. Simulated policies are useful for performing what-if analysis of new policy versions as well as debugging policy changes.

     Note: It’s considered best practice to start with policies in Simulated mode, to verify that policies have been created an applied as expected

   • Enforced: Policy Versions that are being enforced will impact the access decisions that SGNL hands back to an integration. Enforced Policies will determine access for an integration

   

6. Select your desired Enforcement mode and select Assign

7. Versions of Policies will now be Assigned to your integration