Consume Zekt with your own enterprise identity

PreviewInterface preview with placeholder data. No account, token or directory is connected.

Waiting on your identity administratorYour request is with the person who can approve Zekt Gate in your Entra tenant. Anyone who administers this Zekt customer can pick it up — and the request does have a deadline, so it is worth chasing.

1. Door 1

   Your Zekt account

   Whoever owns the Zekt relationship

   GitHub, via Zekt Core

   1. ✓Sign in through Zekt CoreZekt Gate has no login of its own. Core authenticates you and tells Gate the answer.
      Why this step, and what you need: Sign in through Zekt Core

      What this establishesEstablish who you are without Zekt Gate ever handling one of your credentials.

      Why Zekt Gate needs itGate delegates and never forwards. It has no password store and no sign-in of its own, so there is exactly one place a Zekt identity can be established — and one place it can be revoked. What comes back to Gate is an assertion of who you are and which Zekt customers you may administer, never a credential.

      What you provide

      • The GitHub account your Zekt account signs in withWhere to get itYou already have it if you use Zekt. If you do not, you are handed to Zekt’s own signup and returned here afterwards — Gate does not create Zekt accounts, because a second place a customer can be born is a second place billing can start.What it commits you toThis identity is recorded as the person who enrolled, and it is the identity Zekt is re-asked about before anything is bound. Signing in with a different GitHub account means a different person, even at the same company.
   2. ✓Choose the Zekt customerCore confirms you may administer it. Membership alone is not authority.
      Why this step, and what you need: Choose the Zekt customer

      What this establishesFix which organisation this enrollment belongs to, and confirm you may act for it.

      Why Zekt Gate needs itA GitHub login identifies a person; a Zekt customer is an organisation, and one person may administer several. Selecting is not enough — Zekt must assert the authority, because a read-only member must not be able to bind their employer’s directory to a billing relationship. Gate re-checks that authority immediately before it acts, rather than trusting what was true at sign-in.

      What you provide

      • Which Zekt customer you are enrollingWhere to get itZekt offers the list you may administer. If the organisation you expect is not on it, an existing owner of that customer has to give you owner rights at Zekt first — Gate cannot grant them, and cannot see why they are missing.What it commits you toThis choice decides which account carries the charge and which Zekt organisations your directory’s tokens will be able to reach. It is not editable afterwards: moving an enrollment to a different customer means enrolling again.
   3. ✓Accept the commercial termsCore enables Gate as an add-on and remains the source of truth for billing.
      Why this step, and what you need: Accept the commercial terms

      What this establishesHave the organisation commit before anyone spends their identity administrator’s goodwill.

      Why Zekt Gate needs itThe order is deliberate. Connecting a directory carries a recurring charge, and the person who approves it is usually in another team — so the commitment is made by the person who can make it, before a colleague is asked for a favour. Zekt owns the terms and the billing; Gate renders what Zekt sends and holds no price of its own.

      What you provide

      • Your acceptance of the terms Zekt presentsWhere to get itShown to you by Zekt at sign-in, and repeated in Zekt Gate on the enrollment panel — the amount, the period it covers, and any free period that applies.What it commits you toCharging starts when your administrator’s approval completes the connection in Door 2 — not when you accept here, and not at your first call. The charge is per connected directory, so a second directory is a second charge. Any free period is stated with the terms.
2. Door 2

   Your Entra tenant

   Your Entra Global Administrator

   Microsoft Entra ID

   1. ✓Nominate the tenantA claim, not yet trusted. Typing a tenant id proves nothing on its own.
      Why this step, and what you need: Nominate the tenant

      What this establishesRecord which directory you are claiming, so Gate can prepare the exact request your administrator approves.

      Why Zekt Gate needs itA tenant identifier typed into a form proves nothing — anyone can type anyone’s. Naming one is a claim: it reserves nothing, grants nothing, and stays inert until an administrator of that directory proves it. That is also what stops a claim being used to block somebody else’s directory.

      What you provide

      • Your Microsoft Entra directory (tenant) ID00000000-0000-0000-0000-000000000000Where to get itIn the Microsoft Entra admin centre it is shown as Tenant ID on the directory’s overview page. A domain name such as contoso.com is not the same thing. Your identity administrator can read it in seconds if you do not have access yourself.What it commits you toThis is the directory whose sign-ins Zekt will trust for this account, and a directory serves at most one Zekt customer. If you name a different one later, the approval link you already sent stops working and your administrator has to be sent the new one.
   2. Grant admin consent onceOn Microsoft’s own screen. Only a tenant administrator can do this — which is what makes it proof.Waiting
      Why this step, and what you need: Grant admin consent once

      What this establishesTurn the claim into proof, by the one act that only an administrator of that directory can perform.

      Why Zekt Gate needs itThere is no DNS record to publish, no directory query to run and no support ticket to raise: the consent is the proof. Direction is what makes it safe — your directory gains permission to issue tokens naming Zekt Gate, and Gate gains no standing inside your directory. The screen lists two permissions: connecting the directory to Zekt Gate, and “Sign in and read user profile”, which Microsoft requires for any sign-in and which covers the person signing in and nobody else. No reading other users, no groups, no application permissions.

      What you provide

      • A Global Administrator of that directory, and about two minutes of their timeWhere to get itGate writes the request for you once the directory is named — what is being asked, what is explicitly not being asked, and the link. It is written to be forwarded, and the administrator needs no Zekt account and will not be asked to create one.What it commits you toThe request has a deadline set by Zekt; if it passes, the enrollment has to be started again from Door 1, so it is worth chasing. Approval creates a local record of Zekt Gate inside your directory which you own, can see, and can revoke at any time — revoking it stops Gate working immediately.
   3. Gate verifies the tenantA Microsoft-signed token carrying the tenant id turns the claim into a fact.
      Why this step, and what you need: Gate verifies the tenant

      What this establishesConvert the approval into something Gate can check cryptographically rather than take on trust.

      Why Zekt Gate needs itYour administrator returns to Gate and signs in with their own directory account. The tenant identifier inside that Microsoft-signed token is the fact the claim was waiting for — it requires no permission of any kind, and it is the moment the mapping stops being inert.

      What you provide

      • Nothing further from youWhere to get itYour administrator is returned here automatically after approving. Closing the tab at that point is common and costs nothing — the enrollment is resumable and the same link still works.What it commits you toThis is the moment the connection exists, and the moment the recurring charge for this directory starts. Everything before it can be abandoned at no cost.
3. Door 3

   Your applications

   Your developer-portal team

   Gate portal, under customer authority

   1. Register the calling applicationsAn unlisted application is refused even with an otherwise valid token.
      Why this step, and what you need: Register the calling applications

      What this establishesName which of your applications may present a token to Zekt.

      Why Zekt Gate needs itA trusted directory is not an authorised one. Without this list, anyone at your company who can obtain a token for Zekt Gate can call Zekt — which is most of your company. Gate checks the calling application on every request and refuses one that is not listed, whatever else the token proves.

      What you provide

      • The application (client) ID of each application that will call00000000-0000-0000-0000-000000000000Where to get itIn the Microsoft Entra admin centre under App registrations, on your own application’s overview page. For most customers the first one is their developer portal.What it commits you toThis is the ID of your application — the one that asks. It is not the record of Zekt Gate that consent created in your directory; those are two different objects and they are confused constantly. Until at least one application is registered, every call is refused.
   2. Map Entra roles to Zekt permissionsStart from a preset — Reader, Requestor, Administrator — and refine if needed.
      Why this step, and what you need: Map Entra roles to Zekt permissions

      What this establishesDecide what each caller may do in Zekt terms, from what your directory says about them.

      Why Zekt Gate needs itEntra hands over roles and scopes in your vocabulary; Zekt permissions are Zekt’s. Gate maps one to the other so you do not have to design a permission model — and Gate’s answer and Zekt’s must both be yes. Where either is unsure, the request is denied.

      What you provide

      • Who you assign to Zekt Gate’s roles, and which Zekt permissions each role carriesWhere to get itStart from a preset — Reader, Requestor or Administrator — and refine only if you need to. You assign people and applications to Zekt Gate’s roles on Zekt Gate’s record in your Microsoft Entra admin centre. Zekt Gate does not read your directory roles or groups.What it commits you toAccess is still granted and removed in your own directory: Zekt Gate refuses anyone your administrator has not assigned to its role. Leave Microsoft’s “Assignment required” setting off on Zekt Gate’s record, because your administrators sign in to that same record to approve it and to prove control, and requiring assignment could lock them out.
      • For each application: acting as a person, or acting as itselfWhere to get itDecide it per application rather than once for all of them. An interactive tool such as a developer portal should act on behalf of the signed-in user; a background job has no user to act for and should act as itself.What it commits you toThis is the difference between an audit record naming a person and one naming a system. Choosing "as itself" for an interactive tool is not insecure, but it permanently costs you the ability to say who asked.
   3. Constrain scope where requiredLimit which organisations a tenant or application may target. Narrowest wins.
      Why this step, and what you need: Constrain scope where required

      What this establishesLimit which of your Zekt organisations a directory or an application is allowed to act on.

      Why Zekt Gate needs itWho is calling and what they are acting on are different questions, and collapsing them is how one division provisions into another division’s estate. A retail developer portal with a valid token and a legitimate Zekt customer still should not be able to target the platform organisation. Every layer can only subtract: where a directory limit and an application limit both apply, a request must satisfy both, and Zekt’s own answer applies on top of that.

      What you provide

      • Which Zekt organisations each directory and application may targetWhere to get itThey are the organisations your Zekt customer already controls — the same ones you see at Zekt. Gate does not invent or discover them.What it commits you toThe first directory you enrol may target everything the customer controls; every directory after it requires this decision before it works at all, because a second directory usually means an acquisition or a separate division, and silently inheriting the first one’s reach is the wrong default. Removing a limit later is a grant rather than a tidy-up — it returns that directory to inactive, pending a fresh decision. Changes apply from the next request.
   4. Make a test callGate shows exactly what it saw and what it decided. Enrollment completes here.
      Why this step, and what you need: Make a test call

      What this establishesFinish on evidence rather than on configuration having been saved.

      Why Zekt Gate needs itOnboarding is not complete when settings are stored — it is complete when a real token from your directory has produced a real Zekt result. When it does not, Gate shows the chain it checked and where it broke, rather than an unexplained 401. Nearly every enterprise integration failure of this kind is an audience, a scope or a consent mistake, and from the outside all three look identical.

      What you provide

      • A token from your own directory, obtained by one of the applications you registeredWhere to get itYour application acquires it the way it normally acquires tokens, naming Zekt Gate as what the token is for. Gate’s test is a harmless read, so running it creates nothing and is not itself charged.What it commits you toThe account of what Gate saw is available only to a signed-in portal administrator, only for their own customer, and it never echoes the token itself. It shows the decision, not the credential.

POST /v1/orchestrations
Authorization: Bearer <entra-access-token>
Content-Type: application/json

{
  "services": [
    {
      "name": "vm.provision",
      "version": "3",
      "parameters": {
        "environment": "production",
        "size": "large"
      }
    }
  ]
}