Identity, tenancy and roles

Your directory is the source of truth

LayerT runs a SCIM 2.0 server. Your identity provider pushes people and groups to it, and keeps them up to date.

• Users and groups: create, read, replace, update and delete, with the standard discovery endpoints.
• Filtering supports eq and and, which is what identity providers use for provisioning.
• LayerT issues the SCIM token. It’s shown once and stored only as a hash. When you rotate it, the old token keeps working for 24 hours so provisioning doesn’t break.
• Roles come from directory groups you map in the console. Someone with no mapping gets Read-only. When several mappings apply, the most privileged one wins.

LayerT is built for JumpCloud. Other identity providers that speak SCIM 2.0 and OpenID Connect, such as Okta, Microsoft Entra ID and Google Workspace, may work but aren’t certified yet.

Signing in to the console

The console uses the OpenID Connect authorization code flow with your identity provider:

• LayerT finds your organisation from the email domain, then sends the person to your identity provider with a one-time state and nonce.
• The returned ID token is verified against your provider’s published keys: issuer, audience, expiry and nonce.
• The person must already exist in LayerT through SCIM. Nobody is created on first sign-in, and deactivated people are refused.
• The console session lives on the server and is checked on every request, including the person’s current role. Revoking it takes effect immediately, and a change to someone’s role signs them out so their next sign-in carries the new one.

Credentialing each browser

A person sets a browser up once: they type their work email and sign in through your identity provider. There is no token to paste, and the LayerT popup offers Set up this browser in a browser that hasn’t been set up. People can do this themselves. It doesn’t replace a managed roll-out: installing LayerT by device policy is still the plan for managed laptops.

At set-up, the browser makes its own signing key. It sends LayerT the public half and proves it holds the private half. From then on the browser holds two things:

• There is no long-lived refresh credential. A copy of the token alone stops working within minutes, and renewing it needs the key.
• A captured sign-in response is useless without the key, and a renewal proof is accepted once: a proof used a second time is refused.
• Revoking a browser, or deactivating its person, ends it. The next renewal is refused and the browser un-enrols. A browser that has lost its key is a new browser: it’s set up again and waits for approval like any other.

Every new browser waits for approval

A browser that has just been set up does nothing until an Owner or IT Admin approves it on Devices, under Waiting for approval. Until then it gets no rules, sends no audit events and can’t use shared accounts, and its popup says it’s waiting. LayerT’s servers refuse a waiting browser’s requests for policy, audit and shared accounts, so this doesn’t rest on the extension alone. A waiting browser can still renew its token, which is how it learns that it has been approved.

This holds however LayerT was installed. What a browser reports about how it was installed is the browser’s own word: it’s shown to the approver and decides nothing.

• With two or more browsers waiting, one button approves the browsers the page lists and no others.
• For 7 days after a decline, the browser can be put back in the queue. That approves nothing: the browser waits again.
• Each Owner and IT Admin is told at most once about each waiting browser, and the Inbox lists every browser that waits.

Admins can revoke a device from the console. It loses its LayerT credentials and its access to shared accounts, and any live shared-account sessions on it end.

When someone leaves

When your directory deactivates a person or removes them from LayerT:

1. Their console sessions end immediately.
2. Their shared-account requests and live sessions are revoked, and their browsers sign out of those accounts within about a minute.
3. Their open access requests close.
4. Their browsers can’t renew their token, so they un-enrol within minutes.
5. Nobody can approve anything for them any more.

LayerT won’t let the directory deactivate the last active Owner. It keeps them active and tells the Owner why, so an organisation can’t lock itself out.

Keeping organisations apart

• Every organisation-owned record carries its organisation and is filtered by it in the application, on every query.
• Each organisation’s policy is signed separately, and the extension refuses a policy for any organisation other than its own.
• Recordings are stored under a per-organisation prefix.
• Tests check that one organisation’s credentials can’t read another’s policy, audit events, sessions or recordings.

LayerT’s own staff

LayerT staff can’t browse an organisation’s data. To see an organisation’s diagnostics, a named LayerT operator has to ask, with a reason, for up to four hours. Only that organisation’s Owner can approve it. Every view is logged in the organisation’s own audit log.

Roles

LayerT has six built-in roles. They’re designed so that the people who configure aren’t the people who grant exceptions.

✱ Not by default. An Owner can give one named person, such as an IT Admin, the right to grant permanent exceptions.

• Nobody approves their own request. The server refuses it for access requests, shared-account use and password requests. Seeing a stored password needs two other people to approve, and one of them must be an Owner or Compliance Officer.
• Owners and IT Admins can ask to see any account’s password. Anyone else can ask only for accounts they may use or own.
• Optional two-author review stops people publishing rules they drafted themselves.
• Role changes are checked on both ends, so an IT Admin can’t demote an Owner.
• Team Approvers can currently decide requests across the organisation. Scoping them to their own team isn’t built Proposed.
• Access reviews ask each shared account’s owner, every quarter, to confirm who still needs it. Nobody confirms their own access, and nobody loses access until the reviewer submits.

The audit log

Every block, request, decision, sign-in, session, recording view, browser approval and settings change is written to one log, in plain words.

• Events are tied to the person from their credentials, never from anything the request claims.
• Values are readable by default. If a personal address was blocked, the log shows the address, so an auditor can check the decision. A rule can be set to drop its values, or partly mask them, when they arrive.
• A typing rule keeps the text of the whole field, up to 10,000 characters, not only the part that matched. Data handling says what each kind of rule records.
• Kept for 365 days by default. Each organisation can change that.
• Approvers and Auditors see the whole organisation. Everyone else sees their own events.
• The log can be filtered by date, person, action, outcome, rule, account, session and device. Whatever is on screen can be exported as CSV or JSON Lines. Typed values are left out unless the person exporting ticks a box, and the export is written to the log before the file starts.