Skip to content

feat(identity): Principal directory reference#5327

Draft
cloudjumpercat wants to merge 10 commits into
release/kong-identity-m0from
feat/principal-directory-reference
Draft

feat(identity): Principal directory reference#5327
cloudjumpercat wants to merge 10 commits into
release/kong-identity-m0from
feat/principal-directory-reference

Conversation

@cloudjumpercat

@cloudjumpercat cloudjumpercat commented May 21, 2026

Copy link
Copy Markdown
Contributor

Description

Fixes #5033

Preview Links

https://deploy-preview-5327--kongdeveloper.netlify.app/identity/principals/

TODO:

  • landing page links
  • application mapping section
  • UI steps written and tested
  • TF steps written and tested
  • Kong Identity variable
  • Add to KI index

Checklist

  • Tested how-to docs. If not, note why here.
  • All pages contain metadata.
  • Any new docs link to existing docs.
  • All autogenerated instructions render correctly (API, decK, Konnect, Kong Manager).
  • Style guide (capitalized gateway entities, placeholder URLs) implemented correctly.
  • Every page has a description entry in frontmatter.
  • Add new pages to the product documentation index (if applicable).

@cloudjumpercat cloudjumpercat added the release-docs Docs for release label May 21, 2026
@netlify

netlify Bot commented May 21, 2026

Copy link
Copy Markdown

Deploy Preview for kongdeveloper ready!

Name Link
🔨 Latest commit 98f3ef0
🔍 Latest deploy log https://app.netlify.com/projects/kongdeveloper/deploys/6a2858effef87f0008413ad3
😎 Deploy Preview https://deploy-preview-5327--kongdeveloper.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.
🤖 Make changes Run an agent on this branch

To edit notification comments on pull requests, go to your Netlify project configuration.

Signed-off-by: Diana <75819066+cloudjumpercat@users.noreply.github.com>
Signed-off-by: Diana <75819066+cloudjumpercat@users.noreply.github.com>
@cloudjumpercat cloudjumpercat force-pushed the feat/principal-directory-reference branch from 3994272 to 52cb7b3 Compare May 28, 2026 20:05
Comment thread app/kong-identity/principals-and-directories.md Outdated
Comment thread app/kong-identity/principals-and-directories.md Outdated
Co-authored-by: Diana <75819066+cloudjumpercat@users.noreply.github.com>
Signed-off-by: Diana <75819066+cloudjumpercat@users.noreply.github.com>
Signed-off-by: Diana <75819066+cloudjumpercat@users.noreply.github.com>
- text: "{{site.identity}}"
url: /kong-identity/
- text: "Centrally-managed Consumers"
url: /gateway/entities/consumer/#centrally-managed-consumers

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's drop this. We'll be pushing most CMS customers to Principals going forward, and starting to hide this.


{{site.identity}} uses principals and directories to unify how Kong products represent the entities they authenticate.

* **Principal:** Represents an entity that authenticates to a Kong product.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/a Kong Product/a Kong Gateway/

(so as to not confuse with Konnect Users or Developer Portal Developers which are different concepts entirely)

* **Principal:** Represents an entity that authenticates to a Kong product.
The entity can be a human, a workload acting on behalf of a human, or a workload acting on behalf of itself (machine authentication).
* **Directory:** Regional collection of principals.
Each {{site.konnect_short_name}} organization gets one directory per region.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/gets one directory per region/can provision up to one directory per region by default/

Each {{site.konnect_short_name}} organization gets one directory per region.

Principals can be used for:
* {{site.base_gateway}} in {{site.konnect_short_name}}: Can both authenticate clients against a principal and look up principal metadata after authentication

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest something like:

Principals can be used for:

  • In Kong Gateway in Konnect: Can be used to authenticate an entity for API traffic (using API Keys or Basic Auth usernames and passwords) or can be used to provide metadata about an entity for OAuth-authenticated traffic.
  • In Event Gateway: Can be used metadata about an authenticated entity
  • In Developer Portal: Can be used to adjust API Gateway behavior based on the authenticating Developer Portal Application

- title: Description
key: description
rows:
- usecase: "Authenticate clients at {{site.base_gateway}}"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'clients' is an OAuth term that we also use elsewhere in Kong Identity. Maybe use "authenticate API traffic" instead?


You can use metadata for policy decisions.
For example:
* A rate limiting plugin can filter by `principal.metadata.tier`.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great example, but won't actually be true until 3.16 :(

For example:
* A rate limiting plugin can filter by `principal.metadata.tier`.
* An ACL plugin can allow access only when `principal.metadata.business_unit == "payments"`.
* A logging plugin can include `principal.metadata.region` in every log line.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great example, but won't actually be true until 3.16 :(

* An ACL plugin can allow access only when `principal.metadata.business_unit == "payments"`.
* A logging plugin can include `principal.metadata.region` in every log line.

## Apply plugins to principals

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually expected this heading to talk about how to configure the api key, basic auth or ODIC plugins. While we obviously don't want a full how-to should we have a section that briefly mentions those?

This is important too but I'd suggest a more specific heading, eg. "Controlling API Gateway Plugin Execution based on Principals"

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep! I'll add those in an examples section.

* `principal.metadata.*`: Any metadata key on the principal
* `principal.identities.*`: Any identity on the principal

## Principal limitations

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this go at the end?

* An ACL plugin can allow access only when `principal.metadata.business_unit == "payments"`.
* A logging plugin can include `principal.metadata.region` in every log line.

## Apply plugins to principals

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where do we talk about configuring event GW virtual cluster authentication or policies?

Signed-off-by: Diana <75819066+cloudjumpercat@users.noreply.github.com>
Signed-off-by: Diana <75819066+cloudjumpercat@users.noreply.github.com>
Signed-off-by: Diana <75819066+cloudjumpercat@users.noreply.github.com>
## Create a directory

{% navtabs "create-directory" %}
{% navtab "API" %}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A user can provision a directory in the UI as well, so I do think it's worth noting that here. If a user has not created the directory in the API, in the UI, when the user creates their first principal, a default directory is created on their behalf.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jdemartini81 Happy to add UI instructions for the directory! Could you point me to where in the UI (or Figma mockups) where a user can configure the directory? I couldn't find it in the UI or the Unification Figma mockups.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It automatically is created when a user creates their first principal. My suggestion is to describe this behavior. For instance, if you have not yet created your directory via the API, to create it via the UI, simply create your first principal. We will create a "default" directory on your behalf. (You have a better flair for words than me.)

Signed-off-by: Diana <75819066+cloudjumpercat@users.noreply.github.com>
Signed-off-by: Diana <75819066+cloudjumpercat@users.noreply.github.com>
- text: "{{site.identity}}"
url: /kong-identity/
- text: "{{site.konnect_short_name}} control plane resource limits"
url: /gateway/control-plane-resource-limits/

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we link to the Konnect API spec for Kong Identity too?


{{site.identity}} uses principals and directories to unify how Kong products represent the entities they authenticate.

* **Principal:** Represents an external client or workload (not a human {{site.konnect_short_name}} user or {{site.dev_portal}} developer) that authenticates to a {{site.base_gateway}}.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a little misleading. A principal can reprresent a human - but one authenticating to a customer's Gateway. But it is a different entity from a Dev Portal Developer or a Konnect User.

Each {{site.konnect_short_name}} organization can provision up to one directory per region by default.

Principals can be used for:
* {{site.base_gateway}} in {{site.konnect_short_name}}: Can be used to authenticate an entity for API traffic (using API keys or basic auth usernames and passwords) or can be used to provide metadata about an entity for OAuth-authenticated traffic.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

entity for OAuth-authenticated traffic

We are going to do this for other authentication schemes too (eg. mTLS) in future releases so it might be worth re-wording this to something like "can be used to provide metadata about an entity already authenticated through another mechanism (such as OAuth)"


Principals can be used for:
* {{site.base_gateway}} in {{site.konnect_short_name}}: Can be used to authenticate an entity for API traffic (using API keys or basic auth usernames and passwords) or can be used to provide metadata about an entity for OAuth-authenticated traffic.
* {{site.event_gateway_short}}: Can use metadata about an authenticated entity

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest something like "can be used to provide metadata about an entity already authenticated through another mechanism (such as SASL/SCRAM or SASL/OAUTHBEARER)

- usecase: "Share identity across Kong products"
description: "Define a principal once and use it for {{site.base_gateway}}, {{site.event_gateway_short}}, and {{site.dev_portal}} without manually synchronizing identities."
- usecase: "Drive gateway behavior with metadata"
description: "Scope rate limits, ACLs, and conditional plugin execution by attributes that the principal carries, such as business unit or tier."

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACLs and rate limits aren't actually coming until 3.16. Conditional plugin execution is there though.

Metadata is a set of key/value pairs attached to a principal that are made available in the request context of a {{site.base_gateway}} or {{site.event_gateway_short}} after that principal has been authenticated, or looked up, in the request context.

You can use metadata to configure how a gateway behaves when that principal is authenticated to it.
For example, an ACL plugin can allow access only when `principal.metadata.business_unit == "payments"`.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACL plugin does not yet explicitly support Principals. However you can add a conditional expression to the Request Termination plugin.

* **Unify identity across Kong products:** Consumers and applications each represent the same logical entity in different ways, which makes it hard to reason about authentication, policy, and observability together. Principals replace that with one model.
* **Attach metadata to identity:** Consumers don't support metadata, which forces custom plugins or header-injection workarounds when you want per-entity rate limits, conditional plugin behavior, or richer logs. Principals support metadata natively.

If you have existing Consumers you want to migrate to principals, see [HOW TO PLACEHOLDER](/).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we decided this was going to be a fast follow :)


* `principal.id`: The UUID of the principal
* `principal.metadata.*`: Any metadata key on the principal
* `principal.identities.*`: Any identity on the principal

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we double check this is true with @jijiechen ? If so, what is the schema of the different identity objects?

## Controlling {{site.base_gateway}} plugin execution based on principals

Plugins can read principal attributes from the request context after authentication.
The only way to scope plugins to a principal is by using conditional plugin execution on the principal metadata.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth linking to the conditional plugin execution docs.


### Link a principal to a Consumer Group

placeholder, need array config

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jijiechen can help here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

release-docs Docs for release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants