Protecting AWS Access with SGNL

Introduction

Protected Systems are applications, services, or infrastructure that you want to protect with SGNL. In this guide, we’ll describe how to achieve fine-grained access control inside of AWS with your Identity Provider (IdP) and SGNL, enabling the right amount of access to infrastructure and data inside of AWS. This guide supports integration with Okta, and Microsoft Entra ID. If you’d like to learn more about whether securing AWS with SGNL is right for your enterprise, visit our Securing AWS Blog or watch the video below to learn more.

With this integration, AWS and your Identity Provider 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 AWS Organization or Account, configured with SSO to your Identity Provider
Either an Okta Tenant or Microsoft Entra ID Tenant
A SGNL Client
A SGNL User Account with Admin privileges
At least 1 system of record integrated to SGNL (matching your Identity Provider), 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

Log-In to your SGNL Client with an Admin Account
From the left navigation pane, select Protected Systems and Add, or simply click Add from the SGNL Dashboard
Select ‘AWS’ from the Infrastructure category in the list of integrations
Give your integration a descriptive display name and description
Specify the Default Policy to be applied to your App
- 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
Next, you’ll need to configure which identifier your Identity Provider is using to describe your user/principal
- This is likely your user’s email address or login name. This should be in the format of the Principal ID of the user that will request access to the Protected System.
- e.g. If a user will be requesting access to this Protected System, AWS, with the Principal ID as their email address, the principal identifier should be the email address from your Identity Provider.
You’ll also need to define the identifiers for the types of Assets that you are looking to protect
- This might be customer identifiers sourced your CRM system, or products that your customers are buying
Once configured, click Continue to save your configuration and move on to other configuration steps

Configuring Authentication

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 AWS protected system and select the Authentication tab
Click Generate Token
Give your token a descriptive name so that you know how it’s being used in the future and click to Generate Token
On the next screen, copy the token - this will be used by your Identity Provider 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 your Identity Provider with SGNL for dynamic AWS privilege assignment

SGNL integrates with Identity Providers at sign-in time to dynamically assign permissions, roles, tags, or other permission granting objects for AWS Access. We provide support across Okta, Entra ID, and Ping Identity to dynamically assign these permissions.

Choose your Identity Provider to get started:

Integrating Okta with SGNL for AWS Privilege Assignment
Integrating Entra ID with SGNL for AWS Privilege Assignment

Integrating Okta with SGNL for AWS Privilege Assignment

This guide assumes you already have Okta integrated with AWS for SAML SSO. If that’s not the case, refer to AWS Documentation to get that configured.

Once configured, SGNL integrates with Okta via Inline Hooks on the Okta side, and SGNL Transforms (and optionally, Provider Hooks) on the SGNL side.

SGNL Transforms are available on the Protected System you created above, within the ‘Transforms’ Menu. To create a transform suitable for an Okta Inline Hook, you’ll want to:

Choose ‘Select a Search Transform’
Select ‘Okta SAML’
(Optional) Give the Transform a new Display Name
When configuring the ‘Request’ you’ll want to define Mapped Fields from the Okta Inline Hook Payload (Sample) that you want to map to a SGNL Search API Request
Id refers to the Principal Id, so you’ll want to select an attribute from the Inline Hook Payload the refects the Principal Id you’ve configured in the Request config for the Protected System, this is commonly Okta login ({$.data.context.user.profile.login}) or email ({$.data.context.user.profile.email}) other common options are available in the + menu
You can add the IP Address from the payload, if useful for policy decisions or simply for access log metadata, IP Address is available using {$.data.context.request.ipAddress}
Finally, choose the action you want to use, this is commonly a static string such as access or assumeRole, but it could be any of the attributes in the hook payload, using a method similar to the above
Next, you’ll want to configure how the SGNL Search API response should be formatted to return data to the Okta Inline Hook within the Response section
In almost all cases, you’ll want to use an ‘Add’ operation, to add assertions to the resulting SAML Payload from Okta – replace should only be used in circumstances where you have an existing claim in the token from Okta, that you would want SGNL to replace (n.b. trying to replace a claim that doesn’t exist will cause an Okta error)
Next, select an Asset from the SGNL search api response that you want to turn into a claim in the Okta token, this could represent an AWS Role, Tag, or something else, optionally – choose to give that Asset a custom name, for simplified explainability in the following steps
Next, you’ll want to specify a ‘Path’ where to Add/Replace that claim – if we assume you want to Add an AWS Role Claim, you could add /claims/https:~1~1aws.amazon.com~1SAML~1Attributes~1Role into this section, following the response samples in Okta’s Documentation, note that this field supports parameters from your asset response, so for something more complex like tags, you can dynamically set any part of this Path with a parameter, e.g. /claims/https:~1~1aws.amazon.com~1SAML~1Attributes~1{$.SNOWCI.Category}
Lastly, you’ll want to specify the value – this is likely to be an attribute on your asset response and if you’re wanting to dynamically assign a role in the format that AWS expects (e.g. RoleArn,SAMLProviderArn) you’ll likely need to concatenate two different parameters, e.g. {$.AWSRole.arn},arn:aws:iam::{$.AWSRole.accountId}:saml-provider/okta-saml
Continue to add more responses as you might need, or hit save to finalize the configuration
You can now (optionally) configure a Provider Hook and associate with this Transform – Provider Hooks have the benefit of requiring only a single Okta Inline Hook for multiple Protected Systems inside of SGNL

Once your SGNL Transform is configured, you can proceed to configure the Inline Hook within Okta, using the Token you copied from your Protected System above. Steps to create the Okta Inline Hook are available in Okta’s Help Documentation, ensuring that you specify HTTP Header Authentication with a Header name of ‘Authorization’ and a value that contains ‘Bearer ’ and then the token you copied from your Protected System. You’ll need to enter the SGNL Asset Search Endpoint as the target for the request in the Okta Inline Hook, for SGNL SaaS customers, this will be https://{your-client-name}.sgnlapis.cloud/access/v2/search?transform=true&pageSize=1000. You can find further information at SGNL’s API Documentation.

Okta Inline Hook

Integrating Entra ID with SGNL for AWS Privilege Assignment

The first step is to configure Transforms for Entra ID

Select the Protected System
Start by going to the Settings tab, and ensure that the Asset(s) being returned in the Request Configuration section are those that you want handed back to Entra ID during SSO
- Note: Transforms only manipulate the response provided by the asset search API for the chosen Protected System, they don’t allow additional querying/extraction of data from the request, from the SGNL Graph, or other sources
At this time, you might want to make a request to the asset search API to ensure that you’re returning the data you expect (or that your users actually have access to the data you expect)
Once you’re happy that policies are request configuration are correct, select the Transforms tab in the Protected System
In this example, we’re going to configure a Search Transform using Entra ID, you first need to configure the fields to map from the request, SGNL uses JSONPath to find the right values in Entra ID’s JSON request, or you can enter your own static values just by typing them in as-is – a sample request can be found in Microsoft’s Help Documentation, some sample values are provided in the console via the (+) Icon, including:
- {$.data.authenticationContext.user.userPrincipalName} –> Id (SGNL Principal Id)
- {$.data.authenticationContext.client.ip} – ipAddress (Principal’s IP Address)
- SGNL doesn’t provide recommendations for the action context – if you’re policies don’t require an action, feel free to leave this blank, otherwise you can extract data out of Entra’s request, or provide your own static value, like sign-on

We provide significant flexibility in how to transform the response to Entra - before you get started, a couple of things to note:

You can use parameters across any number of attributes on the asset returned, though you cannot choose arbitrary attributes across multiple returned assets
SGNL’s parameter syntax takes the format of “{$.<entity or node name>.<attribute name>}”

To configure the response transforms:

Select the first asset you want to add Transforms for (i.e. When this asset is returned from the asset search API, how do you want to transform the response back to Entra)
SGNL will automatically generate a name for use in the Name and Value parameters, but change this to whatever suits your needs, it’s used only in this configuration
In the Name field, specify the Claim Name you want to return, this might be as simple as something like Role or Group, but could be far more complex, such as :
- AWS Role Claim Path: /claims/https:~1~1aws.amazon.com~1SAML~1Attributes~1Role
- Static AWS Principal Tag Path: /claims/https:~1~1aws.amazon.com~1SAML~1PrincipalTag:cost-center Note: The most important thing to note here is that whatever Claim Name you return, you must have a matching Claim Name configured in the Entra ID Custom Claim Provider, you’ll get to that as part of the Provider Hook Configuration
In the Value field, specify the value of the claim that you want passed in this path, while you’re testing, this could just be a static string, but SGNL’s customers often use one or more parameters to configure the returned value, some examples:
- Say you had a simple deployment in AWS with only your Okta IdP, and you wanted to dynamically assign roles, you might use an AWS IAM Role as the asset, and the arn as the attribute that you attach to your IdP string, e.g. {$.AWSIAMRole.arn},arn:aws:iam::111111111111:saml-provider/Entra-IdP
- You might also have the whole ARN stored in the SGNL Graph, in that case you could simply return a single parameter without any extra detail, e.g. {$.AWSPermittedRole.arn}
- A slightly more complex deployment might use the accountId from the AWSIAMRole to dynamically populate the information, e.g. {$.AWSIAMRole.arn},arn:aws:iam::{$.AWSIAMRole.account}:saml-provider/Entra-IdP
Once you’re done configuring, you can hit save, this will allow you to proceed to configuring a Provider Hook for Entra ID

Assigning Policies

Once the AWS integration is created, you can start assigning versions of Policies - to get started, select Policies from the tabs in your newly created integration
Select ‘Assign Policies’
Select:
- The Policies you want to apply to the integration with the check box
- The version of the Policy you want applied
Click Next once you have the Policies and Versions configured as is appropriate
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
Select your desired Enforcement mode and select Assign
Versions of Policies will now be Assigned to your integration

Configuring Actions

As part of the SGNL CAEP Hub, AWS can be configured to receive session revocation events and other actions from SGNL. This enables real-time access control actions such as revoking AWS sessions when policy conditions change. Follow the steps below to configure AWS to enable this integration.

Initial AWS Configuration

For all authentication methods for AWS, it is required that a Role is created for SGNL to use that gives Actions the ability to make changes to you AWS Account.

Log in to the AWS Console with a user with permissions to manage IAM and create policies
Create an IAM role that SGNL will use to perform actions in AWS:
- Navigate to IAM → Roles → Create role
- Select your “AWS account” as the trusted entity type for the Trust Relationship
- Attach policies that grant permissions for the actions you want SGNL to perform (e.g., iam:PutRolePolicy for session revocation)
- Name the role (e.g., SGNL-Actions-Role) and create it
Note the role ARN for use in SGNL configuration

Example Trust Relationship. The principal will vary based on the authentication method (Access Key or Assume Role with Web Identity)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::782955330740:user/sgnl"
                ]
            },
            "Action": "sts:AssumeRole",
            "Condition": {}
        }
    ]
}

Example permission policy. Based on the actions used, the permissions may vary:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iam:PutRolePolicy",
            "Resource": "*"
        }
    ]
}

Access Key Authentication

Configuring AWS

Go to IAM - Navigate to the IAM (Identity and Access Management) service in the AWS Console
Select Users - Click on “Users” in the left sidebar
Choose your user - Click on the IAM user you want to create keys for
Security credentials tab - Click the “Security credentials” tab
Create access key - Scroll down to “Access keys” section and click “Create access key”
Note the Access Key ID and Secret

Configure SGNL

Log in to SGNL with an Admin Account
From your AWS Protected System (with a type of at least AWS-1.0.0), select Actions
Specify the Address for the Action as https://aws.amazon.com
Select Basic as the Authentication Method
Enter your AWS Access Key ID and Secret Access Key (these should have permissions to assume the role created above)
Click Save to store the configuration

Assume Role with Web Identity

Configuring AWS

For this example, we will be using Microsoft Entra ID as an Identity Provider.

Log in to the AWS Console with a user with permissions to manage IAM and create policies
In the Identity and Access Management (IAM) service, create an identity provider
- Provider: sts.windows.net/{entra-tenant-id}/
- Type: OpenID Connect
- After creating the provider, add an audience
  - Use the client id for the application you wish to use from Entra
- Note the ARN of the created Identity Provider, you will use this in the Trust relationship for the AWS Role
Create an IAM role that SGNL will use to perform actions in AWS:
- Navigate to IAM → Roles → Create role
- Select Web Identity as the trusted entity type
  - Choose the Identity Provider created in the previous step (sts.windows.net)
  - Choose the Audience created in the previous step
- Name the role (e.g., SGNL-Actions-Role) and create it
- Create new inline policies that grant permissions for the actions you want SGNL to perform (e.g., iam:PutRolePolicy for session revocation)

Example Trust Relationship for Assume Role with Web Identity

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::{iam-account}:oidc-provider/sts.windows.net/{entra-tenant-id}/"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "sts.windows.net/{entra-tenant-id}/:aud": "{entra-application-client-id}"
                }
            }
        }
    ]
}

Example permission policy. Based on the actions used, the permissions may vary:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iam:PutRolePolicy",
            "Resource": "*"
        }
    ]
}

Configuring SGNL

Log in to SGNL with an Admin Account
From your AWS Protected System (with a type of at least AWS-1.0.0), select Actions
Specify the Address for the Action as https://aws.amazon.com
Select OAuth2 Client Credentials as the Authentication Method
- Enter your Entra Application Client ID and Secret
- For Scope, enter as the following api://{entra-application-client-id}/.default
- For Token URL, enter your Entra ID Token 2.0 endpoint (this can be found under Endpoints when looking at the Application in Entra ID). It should be in the following format https://login.microsoftonline.com/{entra-tenant-id}/oauth2/v2.0/token
Under Advanced Credentials
- For AWS Role ARN, use the Role ARN created in the previous step, an:aws:iam:{account-id}:role/{role-name}
- For AWS Region, enter the default AWS region, eg. us-east-1
Click Save to store the configuration

Creating your first action

From within SGNL you can configure any change in the graph to trigger actions that are directed to downstream systems. For general documentation on how to configure Triggers and Rules that match your use-case, refer to our CAEP Hub documentation. In an example scenario, you may want to trigger an AWS Session Revocation event when an end-user’s access request expires or when a policy violation is detected. To complete this example integration, we assume someone has already configured the necessary Systems of Record in SGNL:

Select CAEP Hub from the SGNL navigation
Select Triggers
Create a new Trigger:
- Give the Trigger a Name and optionally a Description
- Select the appropriate Nodes based on your use case (e.g., User, AccessRequest, PolicyViolation)
- Set the Condition that should trigger the action (e.g., AccessRequest status equals “expired”)
- Save the Trigger
Create a new Rule:
- Give the Rule a Name and optionally a Description
- Select the Trigger you just created
- Select the option for when the ‘Matches Trigger Scope’
- Click the button to ‘Select an Action’
- Choose ‘AWS’ and the appropriate action (e.g., ‘Revoke AWS Session’)
Configure the required and optional fields:
- In the principalId field, input the value for the Principal ID (e.g., {$.User.email})
- In the roleArn field, input the AWS Role ARN that should be revoked
- Configure any additional fields as needed for your specific action
Save the Rule

That’s it. Once you’ve finished configuring your rule, SGNL will automatically perform the configured actions in AWS when the trigger conditions are met.