Extending Lumos With Webhooks

Last updated: October 7, 2024

Background

The Lumos AppStore is a single pane of glass for your employees to request and gain access to systems. Features such as pre-approvals, connectors to your identity provider, and slack-first approval process can help you bring Time-to-Resolution (TTR) for employee access requests down from days to minutes.

However, not all provisioning can be automated through your Identity Provider (IdP). Many applications do not support SAML or SCIM provisioning, and even the ones that do don't always support provisioning to groups, roles, and licenses. Here are some common examples that often aren't covered by your IdP:

  1. Internal Admin Tools

  2. Internally Managed Databases and Developer Resources

  3. SaaS Tools that don't yet support SCIM provisioning

You can now automate access to these systems through Lumos Inline Webhooks. This article will walk through how these work and how you can set them up in your environment.

Video overview

To watch a past webinar we ran on webhooks, please visit ourπŸ“„ Lumos Universitypage and click on the Extending Lumos beyond Lumos, Part 1 (Webhooks) link.

What are inline webhooks?

Inline Webhooks let you execute custom scripts before, during, or after an access request in Lumos. Your scripts can be hosted on an iPaaS tool like Okta Workflows, or through a serverless function such as AWS Lambdas.

Types of inline webhooks

Lumos supports 4 types of Inline Webhooks: Provisioning, Deprovisioning, Pre-Approval, and Request Validation Hooks.

  • Provisioning

    Provisioning Webhooks let you automate access provisioning for any application, resource, or permission, regardless of whether or not it is connected to your Identity Provider.

    Let's say you have an application, Zendesk, which supports automatic provisioning through Okta, but you can't assign licenses via Okta. Through Lumos, you can create a Provisioning Webhook to grant different types of Agent Licenses and assign each Webhook to a different permission within Lumos.

    Now, anytime someone is approved to access a Zendesk Agent License, Lumos will hit your external script to automatically provision access and no manual work is needed.

    mceclip1.png
  • Deprovisioning

    Deprovisioning Webhooks let you automate access removal for any application, resource, or permission, regardless of whether or not it is connected to your Identity Provider.

    Let's say you have an application, CustomerImpersonationTool, an internal tool to let your support team impersonate customer instances of your software. Through Lumos, you can create a Provisioning and Deprovisioning Webhook to automate the process of getting and removing access to this system.Β 

    Now you can restrict employees to only access this system for 2 hours at a time, and access is automatically removed when they are done.

    mceclip2.png
  • Pre-Approval

    Pre-Approval Webhooks let you create custom conditions for pre-approving access to systems. For example, you might want to create a rule that pre-approves access to AWS for engineers who are on-call.

    mceclip3.pngmceclip4.png
  • Request Validation

    Sometimes you don’t want employees to be able to request access to tools unless they’ve completed a required compliance or security training.

    Through Request Validation hooks, you can create a custom validation check that is run before employees request access to a system. For example, you may want to check whether they have completed a KnowBe4 training before accessing a sensitive database. If an employee tries to request access before completing their training, you can customize the error message they will receive and ask them to complete the training first.

Payload, required response format

The payload that Lumos sends to your script will depend on the type of webhook.

πŸ“„ Provisioning Webhooks

πŸ“„ Deprovisioning Webhooks

πŸ“„ Request Validation Webhooks

πŸ“„ Pre-Approval Webhooks

The HTTP response/payload format that your script needs to return to Lumos for the webhook to be parsed successfully can be found here:πŸ“„ Creating Webhooks

How to tell Lumos whether or not the script was "successful" will be different depending on the type of webhook.

πŸ“„ Provisioning Webhooks

πŸ“„ Deprovisioning Webhooks

πŸ“„ Request Validation Webhooks

πŸ“„ Pre-Approval Webhooks

For each webhook type, whether the webhook was "successful" or not will change the nature of the data you need to send Lumos (links to the specification are in each article).

Creating a webhook

Check out this article for step-by-step instructions:πŸ“„ Creating Webhooks

Storing your webhook data

All Webhook data aside from the name of the Webhook is stored securely at rest, as if it were a credential. You can safely store sensitive credentials such as API keys, usernames, and passwords in your Webhook headers.

Auditing inline webhooks

All provisioning, deprovisioning, and pre-approval webhook executions are logged in your ActivityLog as part of the request they are a part of.

mceclip6.png