Identity platform · After Dark Systems
adsas.id runs sign-in, directory, and user lifecycle for your organization over OIDC, SAML 2.0, SCIM 2.0, and LDAP. Every recorded change lands in a hash-chained audit trail you can export and verify offline, and operator access can be locked behind threshold-signed break-glass.
$ adsasctl org create -slug acme -name "Acme"
$ adsasctl app create <org> -name Wiki -slug wiki \
-protocol saml \
-acs-url https://wiki.example.com/saml/acs \
-audience https://wiki.example.com/saml
$ adsasctl audit export <org> -out acme-audit.ndjson
$ adsasctl audit verify-file acme-audit.ndjson
# verify-file needs no bearer and no networkThree products, one console
Each organization holds a set of products. A call into a product the organization does not hold is refused with product_required before any lock, engine call, or write, and the refusal is audited. Reads are never gated.
Single sign-on for the applications your people use.
Bring the directory you already run.
The people and groups in your organization.
Every workspace includes MFA with TOTP and WebAuthn passkeys, recovery codes, two-person support recovery, scoped machine credentials, the audit trail, custom branding, and verified Ethereum and Solana wallet linking (linking only; wallets do not sign anyone in).
Security architecture
Identity is where attackers aim first. These are the properties the control plane enforces, as built, with the limits written down.
An organization's calls route only to the engine recorded on its row, never to one a request names. A caller aimed at another tenant gets the same not_found as a missing object, and its denied calls are logged under its own organization, so one tenant can neither fill nor read another's log.
Each row is chained by SHA-256 to the one before it and written in the same transaction as the change it records. If the audit write fails, the change does not commit.
In break-glass mode the operator bearer alone can list organizations, read audit, and request elevation. Nothing else. Changes need a scoped, time-boxed elevation signed offline by a threshold of Ed25519 approvers.
Every SAML application created on adsas.id signs with its own keypair, so no two applications share the certificate a service provider trusts. Persistent NameIDs are HMAC-keyed per application, so relying parties cannot compute or link each other's identifiers. SHA-1 is refused outright.
Restrict management actions by verified authentication methods, sign-in age, transport peer, and access window. Rules only ever narrow access. Start in observe mode, read the versioned decision journal, then enforce.
Illustrative rows. The hashes are real SHA-256 values computed with the documented field order. Read the full security model.
Integrations
No proprietary connector to learn. adsas.id speaks the protocols your applications and directories already understand, and refuses the weak options.
Applications get a client id, a one-time secret, and an issuer. API bearers are verified RS256 against operator-configured keys, never keys a token points to.
Signed assertions with SHA-256 or stronger, HTTP-POST ACS, checked IdP metadata, and hardened SP metadata import.
Both directions: inbound sources accept Users and Groups, and outbound connectors provision into your apps.
Federate users and groups over verified TLS with a read-only bind. No password caching, no writeback.
App catalog templates are best-effort starting points that fill in a service provider's SAML fields from a few inputs. They are not vendor certifications or endorsements.
For developers
Everything the console does goes through the same HTTP API and the same permission check. adsasctl is a client of that API and nothing more.
https://api.adsas.id/v1Idempotency-Key on journaled mutationsX-Request-Id on every response, copied onto audit rowscurl -sS https://api.adsas.id/v1/orgs/$ORG/apps \
-H "Authorization: Bearer $ADSAS_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name":"Slack","slug":"slack","mfa":"required",
"catalog_id":"slack","inputs":{"workspace":"acme"}}'{
"protocol": "saml",
"mfa": "required",
"saml": {
"idp_entity_id": "https://id.adsas.id/application/saml/slack/metadata/",
"sso_url": "https://id.adsas.id/application/saml/slack/",
"catalog_id": "slack",
"metadata": "<?xml …"
}
}Tell us what you run today: the apps, the directory, the audit requirements. We will tell you plainly what fits and what does not yet.