feat(identity): Principal directory reference#5327
Conversation
✅ Deploy Preview for kongdeveloper ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Signed-off-by: Diana <75819066+cloudjumpercat@users.noreply.github.com>
3994272 to
52cb7b3
Compare
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 |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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}}" |
There was a problem hiding this comment.
'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`. |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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"
There was a problem hiding this comment.
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 |
| * 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 |
There was a problem hiding this comment.
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" %} |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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/ |
There was a problem hiding this comment.
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}}. |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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." |
There was a problem hiding this comment.
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"`. |
There was a problem hiding this comment.
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](/). |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
Worth linking to the conditional plugin execution docs.
|
|
||
| ### Link a principal to a Consumer Group | ||
|
|
||
| placeholder, need array config |
Description
Fixes #5033
Preview Links
https://deploy-preview-5327--kongdeveloper.netlify.app/identity/principals/
TODO:
Checklist
descriptionentry in frontmatter.