Request a Briefing

ARIA platform reference

Identity, security controls, and compliance alignment

ARIA provides technical controls configured for high-consequence environments and FedRAMP High–aligned implementations in customer-managed environments. Authorization belongs to the deployed system and your authorizing official.

Identity and access

  • Role-based access control. Users, groups, roles, and fine-grained permissions such as "can create agents," with resource ownership and sharing. API keys use the same permission model.
  • Password policy. Configurable length, complexity, history, and minimum age, with stricter presets for DoD-style environments. Account lockout, idle and absolute session timeouts, and a login consent banner are available and configurable.
  • Multi-factor authentication. Authenticator-app codes (TOTP), HOTP, OATH hardware tokens, and backup codes. Emailed codes are available as a weaker option where an email channel is configured. Administrators turn MFA on and set who must use it.
  • Single sign-on (OpenID Connect). OIDC with PKCE, with a Keycloak preset, works with any compliant identity provider. Organizations that use LDAP, Active Directory, or SAML connect them through a Keycloak broker. ARIA does not bind to LDAP or act as a SAML service provider itself. Local password login remains available.
  • CAC/PIV. X.509 client-certificate authentication with chain validation, validity checks, path-length enforcement, and CRL-based revocation. Deployments enable it and maintain their CRL sources. Certificates from a directly trusted PKI are supported. OCSP is not supported.
  • Device trust. Recording and listing of devices is available. Refusing unapproved devices is an administrator option.
  • Sessions. Tokens are tied to a server-side session registry. Sign-out, password change, and administrator revocation invalidate a token.

Cryptography and secrets

  • Key management. Integration with AWS KMS, Azure Key Vault, and HashiCorp Vault, with key rotation. KMS protects stored-object keys and the audit signing key.
  • FIPS-aware operation. ARIA detects a FIPS-enabled host, uses approved key-derivation and hashing algorithms in FIPS mode, and can refuse to start without an active FIPS provider when you require it.
  • Optional FIPS container profile. An optional container image runs on Red Hat Enterprise Linux's OpenSSL FIPS Provider, which holds FIPS 140-3 validation under CMVP certificate #4857. That certificate is Red Hat's, not ARIA's. The profile requires a FIPS-mode host on x86-64, IBM Z, or Power, and does not run on ARM.
  • Encryption at rest. Application-layer AES-256-GCM protects configuration secrets, MFA secrets, run checkpoints, and (optionally) stored files. Database-level encryption is provided by your deployment.
  • In transit. ARIA can terminate TLS, supports TLS to OpenSearch, and sends HSTS headers. Production deployments refuse placeholder signing secrets.

Audit and monitoring

Standard audit logging is on by default. An administrator can enable a hash-chained tamper-evident log with append-only storage on OpenSearch 2.19 and later, weekly full-chain verification, security-event querying, and forwarding to Splunk, Datadog, Elasticsearch/OpenSearch, or syslog. See Trust layer and audit.

Multi-organization (add-on)

The Multi-Organization add-on hosts several organizations, such as divisions or commands, in one deployment with separate members, roles, data, settings, budgets, API keys, and usage. Central administrators enter an organization read-only or through an audited, time-limited session. Separation is enforced by the application.

Licensing for add-ons is described in Models and deployment.

How ARIA maps to your compliance program

ARIA's compliance features are designed to support control implementations consistent with FedRAMP High–aligned baselines, configured for high-consequence environments, when deployed in customer-managed environments and assessed by the customer's authorizing official. ARIA provides documentation, evidence-export tooling, and engineering support for authorization packages.

Security control implementation and system authorization depend on the deployed architecture, its configuration, and the customer's authorizing official. No deployment is compliant merely by installing ARIA. Compliance features are enabled by administrators.

Frequently asked questions

Does ARIA use FIPS-validated cryptography?

ARIA offers an optional container profile that runs on Red Hat's FIPS 140-3 validated OpenSSL module (CMVP certificate #4857, held by Red Hat). The platform itself is not a validated module, and overall validation status depends on the host and environment you deploy in.

Does ARIA support single sign-on?

Yes, through OpenID Connect. LDAP, Active Directory, and SAML are supported through a Keycloak broker.

Back to the ARIA overview

Want to review ARIA's controls against your authorization package?

Contact ADS