Integrations · Enterprise

Add Obelisk as your SAML identity provider

Obelisk is a SAML 2.0 Identity Provider. Point any SAML service provider — GitHub, Google Workspace, AWS, Slack, Atlassian and more — at Obelisk, and your team signs in to it with a passkey, through one audited front door. This is the step-by-step setup.

How it works

In SAML terms, the platform you're protecting (GitHub, Slack, AWS, …) is the service provider (SP), and Obelisk is the identity provider (IdP). When a user signs in, the SP hands them to Obelisk, Obelisk authenticates them passkey-first, and then auto-POSTs a signed SAML assertion back to the SP's Assertion Consumer Service (ACS). The SP trusts the assertion because it's signed by Obelisk's pinned certificate.

It's a two-way exchange. You give the SP Obelisk's IdP values (metadata URL, entity ID, SSO URL, certificate). The SP gives you its SP values (ACS URL, entity ID), which Obelisk registers per SP. Once both sides know each other, sign-in just works.

Obelisk's IdP values

These are the values a service provider asks you to supply. They're stable for the obeliskgate.com tenant:

Field the SP asks forObelisk value
IdP metadata URLhttps://obeliskgate.com/saml/idp/metadata
IdP Entity ID / Issuerhttps://obeliskgate.com
SSO / Sign-on URLhttps://obeliskgate.com/saml/idp/sso
Signing certificateX.509 cert embedded in the metadata above
BindingHTTP-POST (the assertion is POSTed to your ACS)
Signature algorithmRSA-SHA256, certificate-pinned

The fastest path is to hand the SP the metadata URL — most platforms parse the entity ID, SSO URL, and certificate out of it automatically, so there's nothing to copy by hand. Where a platform only accepts pasted values, read them from /saml/idp/metadata.

Step by step

  1. Open SSO settings at the service provider. Find its SAML / single sign-on configuration (e.g. GitHub org or enterprise SSO, Slack Configure SAML, AWS IAM Identity Center external IdP). It will show you the SP's ACS URL (a.k.a. Reply / Consume URL) and its Entity ID / Audience.
  2. Register the SP with Obelisk. Give Obelisk the SP's acsUrl and spEntityId so the IdP knows where to POST the signed assertion and which audience to stamp. (Federation is gated by OBELISK_FEDERATION=on plus a configured IdP signing key/certificate.)
  3. Give the SP Obelisk's IdP values. Provide the metadata URL https://obeliskgate.com/saml/idp/metadata (preferred — it carries the SSO URL and certificate), or paste the entity ID, SSO URL, and X.509 certificate manually.
  4. Map the nameID and attributes. Obelisk asserts a stable subject as the SAML NameID (most platforms expect emailAddress format) and can carry email and name attributes. Match these to the SP's expected attribute names.
  5. Test before you enforce. Do a test sign-in before turning SSO on for everyone — a misconfigured ACS or audience is the most common way to lock admins out. Keep a break-glass admin path until the test passes.
  6. Enforce. Once a test passage works end to end, enable SSO enforcement at the SP. Every sign-in is now passkey-first and receipt-anchored through Obelisk.

How the assertion is secured

Every SAML Response Obelisk issues is signed with real RSA-SHA256 via node-native crypto and pinned to a specific X.509 certificate — there is no homemade signing. The signing path is tamper-rejecting: an altered assertion fails verification, which is proven in Obelisk's own test suite. Because the user proved themselves to Obelisk with a passkey first, the downstream platform inherits a phishing-resistant, assurance-bound sign-in it could never enforce on its own.

Each passage is also a signed, hash-chained receipt in Obelisk's audit chain — so a SAML sign-in to a downstream tool is independently verifiable after the fact. More on the trust model →

Next

Browse the full connector catalogue to see which of your platforms speak SAML vs OIDC, or read the developer integration guide for putting Obelisk in front of your own app. Questions on a specific platform? hello@obeliskgate.com.