Securing Applications using SGNL’s Access APIs

For customers with diverse application landscapes that include niche SaaS applications or homegrown applications, it can be a challenge to find a scalable solution for building and maintaining connections between these systems and your identity landscape. Often, this results in a piecemeal approach to how policies are enforced and dependencies on open-source solutions. Often requiring notable engineering investments, or an inability to get the degree of enforcement or reporting on enforcement your team requires.

SGNL’s Access APIs are a suite of APIs and SDKs built for modern access management in the modern enterprise’s application landscape. Access APIs enable SGNL to connect to any application in your organization to inform and audit access decisions run through SGNL Policy Engine.

Protected Systems can make authorization requests using Access APIs and the Policy Engine will return the dynamic and context-informed access decision back to the control point or application.

Apart from securing access to any application, SGNL Access APIs give identity teams the ability to request detailed information about authorization decisions, the assets that authorized principals can access, or the principals allowed to access a specific asset according to the configured policy.

SGNL Access APIs

What is included in the suite of SGNL Access APIs? We will examine each of the Access APIs and explore how SGNL customers utilize these APIs.

Access Evaluation API

At the heart of the suite of SGNL Access APIs is the Access Evaluation API, which addresses the fundamental question most organizations have with regards to access to protected assets:

Can this Principal perform an Action on an Asset?

Based on business context from Systems of Record, including SaaS applications like Salesforce or Workday, at the time of the request, the Access API returns a clear “Allow” or “Deny” response.

Case Study: Access as Required

A multi-national financial firm operates a portal that centralizes platform access for partners. Certain features of the platform require unique, enhanced security measures and the organization’s access policies must enforce access to meet strict compliance guidelines and allow only specific, authorized actions.

The solution leverages SGNL’s human-readable policies, the Access Evaluation API, and the SGNL Policy Engine with business context ingested from the firm’s Systems of Record. The policy enforcement works as follows:

1. Data Ingestion: SGNL ingests data from the organization’s Identity Provider, Partner IdP, Case Management System, and API Management Platform in order to bring context into the platform. SGNL creates a graph linking employees and partners to groups, roles and products.
2. User Authentication and Authorization Process: The authentication process initiates at the developer portal where the user’s credentials are verified by the Partner IdP, leveraging the identity provider for the actual authentication. Subsequently, the API Management layer undertakes the validation of tokens, extracting essential OIDC claims such as email, displayName, userName, phoneNumbers, partnerID, and partnerName. Upon successful token validation, the API Management layer calls SGNL’s Access API incorporating user attributes as context information.
3. Access Decision: With all pertinent information in place, SGNL applies its human-readable policies to make a “Allow” or “Deny” decision that is then passed back to the API Management layer, which enforces SGNL’s policy decision. If authorization is granted, the user is presented with the appropriate API products and can execute the actions that have been authorized.

For more information on the Access Evaluation API, please refer to our help documentation on policy enforcement and our API developer documentation.

Asset Search API

The Asset Search API shifts the focus to the “what” instead of the “who”. It allows organizations to answer the following question:

What Assets can this Principal perform an Action on?

The Asset Search API returns the set of organizational assets a principal (user or system) can access. The response also contains all attributes of the assets allowing the caller to take further action on the response.

Case Study: Protecting Customer Data

A technology company wanted to change the management of access by various internal teams to customer data in AWS S3 buckets. The primary objective is to remove standing access to customer AWS S3 buckets, replacing it with a tightly controlled and monitored system where access is temporary and tied to specific business justifications.

The solution leverages SGNL’s human-readable policies, the Asset Search API and organization data ingested from the customer’s Systems of Record and works as follows:

1. Data Ingestion: SGNL Adapters for a ticket management system, an identity provider (IdP) and an on-call management system ingest relevant data into SGNL. SGNL creates a graph linking users to issues, schedules and customers.
2. Access Request and Approvals: A SGNL policy enforces the rule that users must be assigned to approved tickets that are associated with customer S3 buckets they wish to access.
3. User Authentication, Federation and Authorization Process: The process begins with user authentication via the IdP. The IdP is configured to send the SAML assertion to the SGNL Search API. SGNL extracts the principal and returns the updated SAML assertion with AWS session principal tags for specific customers the user is allowed to access. AWS utilizes these principal tags to control access to customer S3 buckets.

This solution allows for just-in-time access to customer S3 buckets, with no static permissions. Access is managed through easy-to-maintain and human-readable SGNL policies.

For more information on the Asset Search API, please refer to our help documentation on policy enforcement and our API developer documentation.

Principal Search API

Sometimes, organizations need to flip the perspective and ask the question:

Which Principals can perform an Action on this Asset?

The Principal Search API returns the set of principals (users or systems) that are permitted by policy to perform the specified actions on the asset. The response also contains all attributes of the principal allowing the caller to take further action on the response.

Case Study: Support Cases to Authorized Users

A global technology holding company wants to secure their support case management system. Using fine-grained policy enforcement, the CMS will only present options to users authorized by the relevant policies to handle the case.

The solution leverages SGNL’s human-readable policies and the business context derived from the customer’s Systems of Record, as well as the Principal Search API, and functions as follows:

1. Data Ingestion: SGNL Adapters for the customer’s Identity Provider (IdP) and Salesforce ingest pertinent data into SGNL. SGNL then constructs a graph that links employees and groups in the IdP to cases.
2. Authorization and Case Assignment Process: When a case is initiated and requires assignment to an employee within the support or engineering groups, our out-of-the-box SGNL for Salesforce solution is preconfigured to invoke SGNL’s Principal Search API with the case details. The access service reviews the SGNL graph and returns a list of all employees who are authorized by policy to be potential case owners.

For more information on the Principal Search API, please refer to our help documentation on policy enforcement and our API developer documentation.

Our comprehensive suite of Access APIs offers robust configurability and can integrate any enterprise’s diverse technology stack to SGNL for dynamic, context-based and fine-grained access management