EDCS · Capabilities
Each item below is labeled Available now or In development. Only the first kind is something you can run today, and one also marked Test installation only is not yet running in our own production. What EDCS does not include is listed on the overview.
Issues signed access tokens to your applications under the OAuth 2.0 and OpenID Connect (OIDC) standards. A discovery document lets an application find the endpoints and signing keys on its own. Supports the password, refresh-token and client-credentials grants.
Time-based one-time password (TOTP) codes from an authenticator app, single-use backup codes issued at enrollment, and trusted devices that each person can list and revoke.
A one-time sign-in link sent by email. The link returns people only to addresses on your allowlist.
Access tokens are short-lived and are renewed with refresh tokens, so a leaked token has a short useful life. Every directory, vault and configuration application programming interface (API) call needs a valid token that carries the right scope.
A hosted sign-in page and the authorization-code flow with Proof Key for Code Exchange (PKCE), so people sign in once in the browser and move between applications without handing each one their password.
Test installation only
Sign-in with a Common Access Card (CAC) or Personal Identity Verification (PIV) card certificate, with certificate revocation checking that refuses the sign-in when the revocation status cannot be confirmed. Per organization, it also accepts partners’ PIV-Interoperable (PIV-I) cards and derived PIV credentials on mobile devices.
Test installation only
An identity provider for applications that sign in with Security Assertion Markup Language (SAML) 2.0, with a registry of the partners you trust and the attributes each one receives.
Test installation only
Fast IDentity Online 2 (FIDO2) and Web Authentication (WebAuthn) security keys and passkeys, as the second factor after a password or, per organization, for passwordless sign-in. An organization can require a phishing-resistant factor.
Test installation only
Every user token states how the person signed in and carries the authenticator assurance level (AAL1, AAL2 or AAL3) that EDCS computes from the factors it verified, mapped to National Institute of Standards and Technology (NIST) Special Publication (SP) 800-63B Revision 3. Whether a deployment meets a level is your assessor’s decision. An application can demand a higher level, or a fresh sign-in, before a sensitive action.
Test installation only
People from a partner organization sign in with their own organization’s identity provider, over OpenID Connect or SAML 2.0. Their accounts are linked by an administrator, not automatically.
Test installation only
Token introspection and revocation, a user-information endpoint, sign-out that reaches the other applications in the session, and administrator revocation of a person’s sessions. The session idle timeout is on by default at 15 minutes and is set per organization and per application.
Test installation only
An optional notice that people must acknowledge before they are asked for a credential, with each acknowledgment recorded. Off by default.
Test installation only
People and groups live in a Lightweight Directory Access Protocol (LDAP) directory, and your applications read and manage them through a web API instead of speaking LDAP themselves.
A System for Cross-domain Identity Management (SCIM) 2.0 endpoint, so an authoritative source such as a human-resources system can create, change and deactivate people and groups without a person retyping them.
Test installation only
Changes to people and their access are pushed to downstream applications by SCIM or by a signed notification, through a durable queue with retries and a list of failed deliveries that an administrator can retry or dismiss.
Test installation only
Rules grant access from a person’s attributes, such as their organization, and each application receives only the attributes you release to it.
Test installation only
Each version of a secret is encrypted under its own 256-bit data key, and that key is encrypted under a key-encryption key that is never written to disk unencrypted. Earlier versions are kept, so a change can be traced and rolled back.
Settings and feature flags for each application, kept in one place. A setting can point at a vault secret: the value is fetched when an application with permission to read it asks, and is never copied into the configuration.
Each application gets its own client identity with only the scopes it needs, so one application cannot read another’s secrets or settings.
An application can authenticate with a signed assertion (private_key_jwt) or with a client certificate over mutual Transport Layer Security (mTLS), and receives tokens bound to that certificate.
Test installation only
Directory sign-in attempts, secret reads and changes, and configuration changes are recorded with who, what, when, the source address, and whether it succeeded.
One record of who holds which access in each application, with history. An accountable owner confirms that access is correct when it is granted, and again on a schedule; access that is not reconfirmed by the deadline is removed.
Test installation only
Rules that stop one person from holding two roles that must stay apart, such as entering a payment and approving it.
Test installation only
People ask for access and an owner approves or denies it, optionally with a second approver. Access can carry an end date, and separation-of-duties rules still apply to an approved request.
Test installation only
A policy decision point that an application can ask whether a person may do something: role-based rules with attribute conditions, and a refusal unless a rule allows it.
Test installation only
Each audit record is linked to the one before it by a SHA-256 hash, so an edited, deleted or missing record is detected by the verification check (deletion of the newest records shows only against the SIEM copy), and optional checkpoints keyed with a hash-based message authentication code (HMAC) catch a rewritten chain. Records can be sent to your security information and event management (SIEM) system as they are written; export is off by default.
Test installation only
Off by default. When it is on, each service checks at start-up that the operating system’s Federal Information Processing Standard (FIPS) provider is loaded and enforcing, and refuses to start if it is not. EDCS relies on that platform module and claims no validation of its own. The standard images do not include a FIPS provider; a FIPS deployment uses images built on a FIPS-capable base.
Test installation only
Off by default. With a hardware security module (HSM) reached through Public-Key Cryptography Standards #11 (PKCS#11), token and SAML signing keys are generated on the module and never leave it. If the module cannot be reached, signing stops; EDCS never falls back to a software key.
Test installation only
Token and SAML signing keys roll over with the next key published before it signs, and the old key kept, signing nothing, while what it signed is still in use. Administrators can also rotate on demand, or revoke all of an organization’s keys after a compromise.
Test installation only
Every service can run as several instances behind a load balancer, sharing sessions, keys, lockout counters and rate limits through the database. Replication between data centers is not included.
Test installation only
A web console for organizations, people, groups, application clients, secrets, configuration and two-factor settings. Its demonstration-data reset, for applications that offer one, does nothing until an administrator lists the hosts allowed to receive it.
An organization’s administrator can open a registered application signed in as one of that organization’s people, to see what they see. The session gets that person’s access, never the administrator’s, through a token that lasts 5 minutes by default and cannot be refreshed. The token is marked as impersonation and carries the administrator’s own assurance level, and an application’s access rules still apply. Each token issued is audited, and so is each one refused because the caller is not an administrator or the person may not use the application. It is available to the organization’s administrators and has no separate switch.
Each organization gets its own databases and its own branch of the directory, selected by web address or organization code, so one installation can serve several organizations without their data mixing.
Delegates scoped to particular applications, who can grant and remove access to those applications and nothing else. A delegation can expire and be withdrawn, a delegate cannot grant access to themselves, and every delegated action is audited.
Test installation only
Tell us how your people sign in today and which applications they use. We’ll show you EDCS, scope where it should run, and quote the license and support that fit.