In the context of Airlock as a Service, we use the following terms with the meanings described below.
Term |
Definition |
|---|---|
Active Config |
The configuration that is currently used by the deployment |
Airlock Console |
→ Application for → SaaS Admins to manage the Airlock SaaS Service (see also → Management Center) |
Airlock SaaS DevOps team |
Represents a person of the Airlock SaaS DevOps team that is responsible for deploying, maintaining and monitoring Airlock SaaS.
|
|
Airlock SEC (Ergon or delegate of customer) |
Represents a person of the Airlock Security Engineering & Consulting (SEC) team that is responsible for creating/altering a Tenant IAM configuration according to a customer's requirement on Airlock SaaS. Technically, it is a SaaS Admin with special (additional) permissions. These special permissions can only be assigned manually by a member of the of the Airlock DevOps SaaS team. Only these permissions enable uploading Airlock IAM configurations as ZIP files. |
App |
An application which is protected by authentication and authorization |
Auth Flow |
Authentication- and authorization flow. Consists of steps and can be controlled by tags. |
Data Source |
Source of data like users (admins, end-users), tokens, and more |
Desired Config |
The configuration that is intended to be used by the deployment. |
Deployment |
A tenant's runtime. The deployment serves the end-user traffic as per the activated configuration. |
End-user (user) |
Represents a person who accesses the customer's end user application(s).
|
Futurae |
Airlock partner which provides Airlock 2FA functionality via their own services |
Helpdesk (user) |
An employee of the customer that is responsible for managing End-users in customer's application landscape.
Note: the corresponding feature has not yet been implemented and is mentioned for the sake of completeness and future reference. |
Invite (a→ SaaS Admin) |
The process of inviting an admin into their own organization |
IAM config |
Generic term for the entirety of all elements that lead together to the desired behavior of an IAM: IAM configuration files, like config XML, keystores, Design Kit ZIP, instance.properties, and more |
Identity propagation |
Identity information about the end-user which can be sent to the app |
Identity Provider (IdP) |
An (external) provider of user identities. Usually used on context of SAML 2.0 or OAuth 2.0/OIDC |
Management Center |
Application in Airlock SaaS for the admin to manage its tenant(s). The name of the application is → Airlock Console |
Management Platform |
All services, apps, and components to provide the Management Center functionality |
Mobile App |
An app on a smartphone, usually connected to an → App |
Organization |
An organization is the representation of the Airlock SaaS customer and as such the contracting party and data boundary. Every user is acting on behalf of an organization. An organization is defined by it's legal name and domicile. |
Protocols (Auth protocols) |
Set of standards and protocols in context of authentication and authorization, e.g. JWT, SAML 2.0, OAuth 2.0/OIDC, and more |
Runtime Platform |
The kubernetes cluster where the end-user IAM is running |
|
SaaS Admin (Delegate of customer) |
An employee of the customer or Airlock Partner who is responsible for their operational security.
|
SaaS Superadmin |
Represents a person of the Airlock SaaS team responsible for managing Airlock SaaS and assisting SaaS Admins.
|
Self-reg |
Short for self registration. IAM plugin, which implements the sign-up and invitation process. |
Self-services |
Services in IAM that the → End-user can use, e.g. password reset, self-registration, e-mail address change |
Sign-up |
Sign-up process of a → SaaS Admin, which also creates a new organization. |
Single sign-on |
The → End-user must authenticate and authorize only once to access several apps |
Staging (verb) |
The process of transferring a configuration from one – Tenant into another (e.g. from TEST tenant to PRODUCTION tenant). |
Stage (noun) |
A staging environment (stage) is a nearly exact replica of a production environment for software testing. Staging environments are made to test codes, builds, and updates under a production-like environment before application deployment. |
Superadmin (user) |
A person from Ergon who manages → SaaS Admins via the Management IAM Adminapp. Superadmins are created programmatically, are not part of any organization and are able to access the Tenant IAM Adminapp of all tenants. |
Tenant |
The Tenant is the entity for the definition and operation of one configuration (and user) data set. → SaaS Admins interact with Tenants and edit their configuration. |
Tenant config |
Results from the settings the admin makes in the management center. → IAM config is a (partial) result of a tenant config |
Tenant settings |
Configuration that define the general characteristics of a tenant but is not part of the tenant config:
|
Transformer (component) |
Transforms the tenant config into the configs needed by the runtime components like IAM, MGW, and others |
User |
Any person interacting with the system. Usually the more specific type of a user should be used in descriptions, e.g. "SaaS Admin" or "end-user" |
User management |
Part of the management center where the admin can manage the end users |