Skip to content
ReleasesGitHub

Set up user access for Aembit Desktop

Setting up user access is the Aembit Tenant administrator’s half of Aembit Desktop: Aembit Desktop gives a person working on a Windows 11 machine access to enterprise HTTP and HTTPS services without holding static credentials. The person signs in through their organization's Identity Provider, and a local proxy injects Aembit-brokered credentials into traffic from the tools they run., and you do it once for each Identity Provider that people sign in through. It ends with a deployed Access Policy: Access Policies define, enforce, and audit access between Client and Server Workloads by cryptographically verifying workload identity and contextual factors rather than relying on static secrets.Learn more and an Aembit Client ID that you hand to everyone running Aembit Desktop. That value identifies the Identity Provider for Aembit Desktop sign-in. A Client Workload’s Aembit Client ID is a different value. Install Aembit Desktop and sign in covers the other half, which happens on each person’s own machine.

Before you begin

Section titled “Before you begin”

Before you start, make sure you have:

  • Administrator access to your Aembit Tenant: Aembit Tenants serve as isolated, dedicated environments within Aembit that provide complete separation of administrative domains and security configurations.Learn more.

  • An Identity Provider configured for Single Sign-On in your Aembit Tenant. Aembit Desktop signs people in through that Identity Provider, which can be an OIDC 1.0 or SAML 2.0 Identity Provider.

  • An HTTP or HTTPS service that you want people to reach, and the credential that service accepts.

  • Access to the default Resource Set: Resource Sets are organizational containers that group Access Policy components together, enabling you to manage configurations across different environments, regions, or use cases.Learn more. Aembit Desktop supports only the default Resource Set, so create every component on this page there.

Enable user access on your Identity Provider

Section titled “Enable user access on your Identity Provider”

Follow Configure Identity Provider user access to enable user access, configure the session lifetimes, and copy the Aembit Client ID. Send the Aembit Client ID to the people installing Aembit Desktop, who pass it to adt login, or deliver it in a settings file, as described in Configure Aembit Desktop settings.

Create the Client Workload

Section titled “Create the Client Workload”

The Client Workload: Client Workloads represent software applications, scripts, or automated processes that initiate access requests to Server Workloads, operating autonomously without direct user interaction.Learn more is how an Access Policy recognizes that a request came from Aembit Desktop rather than from anything else in your environment.

  1. Click Client Workloads in the left sidebar, then click + New.

  2. Enter a Name, such as Aembit Desktop.

  3. Under Client Identification, select User Access IDP Client ID from the Type dropdown.

    This identifier type appears only after Aembit support enables Aembit Desktop for your Aembit Tenant.

  4. Select the Identity Provider you enabled user access on from the Select Identity Provider dropdown, then click the plus button to add the identifier.

  5. Click Save.

Create the Trust Provider

Section titled “Create the Trust Provider”

The Trust Provider: Trust Providers validate Client Workload identities through workload attestation, verifying identity claims from the workload's runtime environment rather than relying on pre-shared secrets.Learn more decides which signed-in people the Access Policy covers. Aembit Cloud verifies that the person authenticated to your Identity Provider before the Trust Provider runs. The match rules here narrow that set rather than establish it.

  1. Click Trust Providers in the left sidebar, then click + New.

  2. Enter a Name, such as Aembit Desktop users.

  3. Select User Identity Provider from the Trust Provider dropdown.

  4. Under Match Rules, select sub as the Attribute and enter the person’s email address as the Value.

    Aembit sets sub to the first email address it finds in the NameID, email, or User Principal Name (UPN) claim the Identity Provider sends, in lowercase. When none of them holds an email address, sub holds another identifier from the Identity Provider, and a rule that matches an email address doesn’t match. Add a match rule for each person the Access Policy covers.

  5. Click Save.

Attach the Server Workload and Credential Provider

Section titled “Attach the Server Workload and Credential Provider”

The Server Workload: Server Workloads represent target services, APIs, databases, or applications that receive and respond to access requests from Client Workloads.Learn more is the service people reach, and the Credential Provider: Credential Providers obtain the specific access credentials—such as API keys, OAuth tokens, or temporary cloud credentials—that Client Workloads need to authenticate to Server Workloads.Learn more supplies the credential Aembit injects into each request. Neither is specific to Aembit Desktop, so create them as you would for any Access Policy:

Deploy the Access Policy

Section titled “Deploy the Access Policy”

  1. Click Access Policies in the left sidebar, then click New.

    The Access Policy Builder opens with the Access Policy panel on top.

  2. Enter a name for the Access Policy and click Save.

    The panel closes and the builder shows a card for each component.

  3. Configure the Client Workload card with the Client Workload you created, and the Server Workload card with the Server Workload.

  4. Configure the Trust Provider card with the Trust Provider you created.

  5. Configure the Credential Provider card with the Credential Provider.

  6. Click Save Policy & Activate.

The Access Policy applies to new requests once it’s active. A request can still follow an earlier answer from Aembit Cloud until that answer expires, as Injecting a credential explains. The Aembit Tenant UI needs nothing further.

Next steps

Section titled “Next steps”