How Oktually Works
In General
Oktually works by ingesting data from your Okta tenant, via Okta’s APIs. Oktually only reads data, it does not make changes to Okta. There are two broad categories of data that Oktually ingests, Event data and State data.
Event data comes from your Okta log and covers immutable happenings in Okta, like logins, new user creation or group assigment.
State data comes from other read-only APIs and covers configuration like the users in a group, an application’s description or the rules of a sign in policy.
Data Flow
Oktually’s orchestrator reaches out to Okta and pulls data into a dedicated database for your Okta tenant.
Queries and scripts mutate the data into the forms required to answer specific questions, or be used by tools in the platform.
When you access the Oktually web application, it uses data from the database or extracts from the database kept in an object storage bucket. The app does not directly connect to your Okta tenant. Where it makes sense, the app caches data for speed and to reduce strain on the database.
Wherever possible, Oktually uses incremental loading to speed up ingestion and reduce load on your Okta tenant. For logs, this involves knowing the published time for the most recent event that Oktually ingested. For state data, this is using the lastUpdated field in Okta’s APIs to poll only for changed objects (lastUpdated is not available from all of Okta’s APIs).
Freshness
Oktually’s use case, as a day-to-day workhorse for general administration insights, means it doesn’t need the very latest data from Okta at all times.
During the Alpha stage, Oktually ingests both Event & State data up to once per hour. In later stages, Oktually aims to stream logs in near real-time and ingest State data up to every fifteen minutes.
Architecture
Oktually makes use of cloud infrastructure hosted in the EU. Oktually’s compute & databases are run from within a VPC, reaching out to your Okta tenant through a single gateway with a single IP address (yes, you can IP limit Oktually’s access to your tenant).
Database instances are managed by the cloud provider, for reliable service & patching.
Oktually achieves multi-tenancy by having separate customer databases & web application instances. Resources for each customer’s Oktually web app can therefore be scaled separately.
Security
Once submitted, all secrets and configuration required for accessing your Okta tenant are stored in a cloud secret manager service.
In its current state, the Oktually web app is strictly IP limited on a per-customer basis — only your instance is accessible to your chosen IPs.
Authentication to the app is using a random, basic-auth password and encrypted cookie. Individual user authentication is expected before the Beta stage, with SSO following after — Oktually will not charge a security tax for SSO.
Authentication to your Okta for collecting data is implemented using an API token. Backend service app integration is expected before the end of the Beta stage.
Each customer’s Oktually web application has a dedicated TLS certificate issued from Let’s Encrypt.
Oktually’s databases are encrypted at rest. Communication between compute & the databases never leaves the VPC but is currently unencrypted; encryption between the two is expected before Oktually reaches the beta stage.
Oktually practices identity separation wherever possible — each service accessing a customer’s database has its own uniquely named credentials specific to the customer; each customer’s web application has its own identity for accessing cloud services.