Zones

A zone is a logical grouping of users, applications, and resources that share a common set of security controls and policies. Zones are also referred to as security domains or trust domains.

Zones control access to resources by users and applications. Zones verify authentication credentials presented by people and agents, evaluate policies that determine allowed permissions, and issue access credentials that permit scoped access to resources.

Each zone has a default domain in the format {id}.keycard.cloud. Keycard supports custom domains to change this to any domain that you or your organization owns.

A single organization may operate multiple zones for various purposes, such as separating different departments and divisions or isolating services and environments.

User Interaction

Every zone has the ability to interact with users, displaying prompts that are necessary for authentication and authorization. These prompts include dialogs to sign in, step-up to multi-factor authentication, or grant consent for applications to access data. These prompts are typically displayed to users as HTML forms within a web browser.

These prompts become embedded user interface (UI) components within applications. When an application needs to authenticate a user or obtain authorization to access resources, it sends an authentication or authorization request to the zone. Thus, the zone is referred to as an authentication server or authorization server. Or, more broadly, an identity server.

Security Token Service

Every zone has an instance of Keycard STS, short for Security Token Service. Keycard STS is the identity server for the zone.

Keycard STS implements OpenID Connect and OAuth 2.0 - both industry standard protocols - along with a suite of extensions necessary to secure agentic applications, which operate in highly-federated environments requiring delegated authority.

As part of fulfilling its role as an authorization server, Keycard STS handles authentication and authorization requests. These requests often trigger user interaction in a sequence of challenges and responses. Assuming the challenges are sucessfully passed and policy permits access, Keycard STS issues access credentials valid at protected resources within the zone.

Federation

While a zone can be self-contained, its full capabilities are realized by connecting to other domains, in what is termed federation. Zones connect to other domains through providers.

Providers fall into one or more categories:

1. User identity providers
2. Application identity providers
3. Access credential providers

User identity providers allow people to sign in using accounts from other domains. In enterprise scenarios, this is known as single sign-on (SSO), and allows employees to sign in using their company account, from providers such as Okta or Microsoft Entra. In consumer scenarios, people can sign in using an account at Google, Apple, or a social network in what is referred to as social login.

Application identity providers allow applications to authenticate using identity tokens. These tokens are typically issued by cloud providers to applications, or workloads, running on cloud infrastructure operated by Amazon Web Services (AWS), Microsoft Azure, Google Cloud, and others. Native desktop and mobile applications may also have identity asserted by the underlying operating system or device.

Access credential providers issue access credentials, also referred to as access tokens, for resources hosted by third-parties. This is common when accessing APIs provided by software-as-a-service (SaaS) vendors. Access credential providers enable credentials to be brokered between domains.

Every zone is also capable of acting as a provider for other domains. This enables inter-zone federation within Keycard, as well as federation from Keycard zones to other identity systems.