Home

Welcome to the EDAMAME integrations wiki.

This wiki documents how to connect EDAMAME's conditional access control to third-party identity, source control, and Zero Trust network providers. Each guide covers the configuration you perform in the provider's own console, the details you then enter in EDAMAME Hub, and how enforcement behaves once the integration is live.

Setup guides

The Hub provider column is the name to select when you click Add Conditional Access in EDAMAME Hub, which does not always match the vendor's current product name.

Provider	Hub provider	Guide
Microsoft Entra ID (formerly Azure AD)	Azure	Setting Up Azure for Access Control Integration
Google Cloud Identity	Google	Setting Up Google for Access Control Integration
GitHub	Github	Setting Up GitHub for Access Control Integration
GitLab	Gitlab	Setting Up Gitlab for Access Control Integration
NetBird	Netbird	Setting Up Netbird for Access Control Integration
Tailscale	Tailscale	Setting Up Tailscale for Access Control Integration
Fortinet FortiGate	Fortigate	Setting Up Fortigate for Access Control Integration
Netskope	Netskope (not yet available)	Setting Up Netskope for Access Control Integration

Netskope is documented ahead of its release: the Netskope-side configuration can be prepared now, but the provider is not yet selectable in EDAMAME Hub.

Building your own integration

If your provider is not listed above, EDAMAME can drive any HTTP or GraphQL API through a JSON configuration:

• Integration principles and architecture — how an integration works, which device identifier to key on, and what a provider's API has to offer before it can be integrated at all. Start here.
• Comprehensive JSON Configuration Guide for IP Allow List Management — the configuration schema reference.

How enforcement differs by provider

The guides are not interchangeable, because providers expose different enforcement primitives. It is worth knowing which model applies before you choose one:

• Allow-list providers — Entra ID, Google Cloud Identity, GitHub, GitLab. EDAMAME maintains a list of the IP addresses of compliant devices, and the provider restricts access to that list.
• Group membership providers — NetBird, FortiGate. EDAMAME maintains the membership of a group you create, and your own policy or firewall rule decides what membership grants.
• Device authorization providers — Tailscale. EDAMAME authorizes and deauthorizes devices directly, across the whole tailnet. Read that guide's prerequisites before enabling it.
• Device tagging providers — Netskope. EDAMAME only applies and removes a tag on compliant devices; your own Netskope policy, keyed on that tag, makes the access decision. Nothing is enforced until you build that policy chain.

Apart from Netskope, EDAMAME replaces the whole list or membership on each update rather than adding entries incrementally, so manual entries you add on the provider side will be removed. Keep manual exceptions in a separate list, group, or rule. Netskope is the exception: it updates one device at a time and preserves tags applied by other tools.

Device-side requirements

The allow-list providers work from the device's public IP address, which EDAMAME already knows, so they need nothing installed beyond the EDAMAME agent itself. The same is true of FortiGate, which matches on the device's MAC address — though the FortiGate itself has to be on a network segment where it observes that MAC directly.

The NetBird, Tailscale and Netskope integrations are the exception. They identify devices by an identity that only exists inside the provider's own client, so those guides add device-side requirements: the provider's client must be installed and connected, and the EDAMAME agent must run with elevated privileges to read the identity out of it. A device that fails either requirement is silently skipped — it looks exactly like a device that has no client at all. If devices are compliant in EDAMAME but never reach the provider, that checklist is the place to start.

Netskope additionally has no Linux support, because its Linux client does not expose the device identifier the integration needs. See that guide's prerequisites.

The reasoning behind these differences — why one provider matches on a public IP, another on a MAC address, and another on an identity issued by its own client — is covered in Integration principles and architecture.