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.)
Description
Fixes #5033
Preview Links
https://deploy-preview-5327--kongdeveloper.netlify.app/identity/principals/
TODO:
Checklist
descriptionentry in frontmatter.