π€ Webhooks
Event-driven integration mechanism supporting real-time identity lifecycle management through secure webhook notifications.
Overview
Webhooks in Lumos enable event-driven identity management, allowing real-time reactions to identity lifecycle events. This pattern is crucial for organizations requiring immediate responses to changes in user status, access rights, or compliance states. Webhooks can trigger custom workflows (in iPaaS like Workato, Okta Workflows, etc.), notify external systems, or initiate automated remediation processes. This pattern is particularly useful for orchestrating workflows in external systems that should respond to identity lifecycle events.
Key Features
- Push Notifications: Lumos automatically sends data to external URLs upon triggering events.
- Workflow Automation: Chain events to triggers in other platformsβlike Slack notifications or service desk ticket creation.
- Secure Transmission: Configurable authentication methods and HTTPS ensure data integrity.
Real-World Example
- Scenario: A services company needs to immediately revoke access across all systems when an employee's status changes to "terminated."
- Outcome: Implemented webhook listeners that trigger immediate access revocation workflows, reducing security exposure window to near-zero.
- Implementation: Lumos webhooks notify a custom orchestration service that coordinates access revocation across all connected systems, with confirmation logging.
Benefits
- Immediate Alerts: Real-time notifications ensure rapid response for critical events like security breaches or urgent provisioning.
- Customized Responses: The receiving endpoint can trigger custom logicβsuch as sending an SMS or creating a Jira ticket.
- Reduced Polling: Eliminate the need for continuous API polling by listening for relevant events as they happen.
Considerations
- Webhook Security: Implement proper signing and authentication to validate payloads, preventing potential misuse.
- Endpoint Reliability: If the receiving system is down, ensure you have retry logic or a dead-letter queue to handle missed events.
- Data Sensitivity: Since webhooks can include PII or sensitive data, encrypt payloads and restrict access to secure endpoints.
Types of Webhooks
Lumos supports 4 types of Inline Webhooks:
- 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. - 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. - 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. - Request Validation Webhooks 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.
Updated about 2 months ago
Whatβs Next