feat: Misc Dev Portal updates from previous feedback #7638
Conversation
…istrations one page and cut down on the CRUD tasks Signed-off-by: Diana <75819066+cloudjumpercat@users.noreply.github.com>
cloudjumpercat
added
do not merge
✅ Deploy Preview for kongdocs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Signed-off-by: Diana <75819066+cloudjumpercat@users.noreply.github.com>
There was a problem hiding this comment.
@lmilan Here's the Dev Portal diagram doc we were talking about in ticket review. If you have the time, I'd love a very general/high level review of this page:
- Does the page seem helpful? Were you able to understand the information (some of the text is rough because I was just trying to get the idea out)
- Would this info be better on a different page rather than a separate page?
- Do the diagrams make sense and do they cover most of the configuration situations?
- Are the diagrams needed or could the info be presented in another way better?
cc @Guaris and @lena-larionova if you wanted to review this as well
There was a problem hiding this comment.
For "Who will be using your Dev Portal or Dev Portals?", why do we need three diagrams? It seems like the third diagram, the mix, covers all three scenarios in one diagram. I think you could use just the third one with a couple of minor tweaks.
There was a problem hiding this comment.
Looking at this from another step back, I think you can condense the whole page to one or two diagrams. The section "What will my Dev Portal be used for?" looks like it contains the diagram for "Who will be using your Dev Portal or Dev Portals?". So you could lead the user down the page this way:
- What is the dev portal for and who is using it?
- What do I do with their apps, if any?
…d redirect for auto approve doc, clean up config diagram so it's just one and the page has less text Signed-off-by: Diana <75819066+cloudjumpercat@users.noreply.github.com>
Signed-off-by: Diana <75819066+cloudjumpercat@users.noreply.github.com>
app/konnect/dev-portal/access-and-approval/manage-app-connections.md
Outdated
Show resolved
Hide resolved
cloudjumpercat
added
review:copyedit
| @@ -150,6 +142,7 @@ In the `default` control plane group, **Credential claim** is used as a **Consum | |||
|
|
|||
|
|
|||
| ## Enable app registration with multiple IdPs | |||
| <!-- what does DCR have to do with application auth? This is confusing to me and I'm not sure I see the connection here --> | |||
There was a problem hiding this comment.
DCR is one type of strategy for application auth, where Konnect is integrated directly with the Identity Provider to be able to outsource, link, and automate the credential management via that IDP. Other cases are
- using an Identity Provider, but having to manually provide and manage your own credentials outside of Konnect Dev Portal (this is OIDC with DCR)
- using Key Auth, where no IDP is involved and credentials are managed by Konnect and Kong Gateway
| ### Support for any control plane | ||
|
|
||
| App registration is fully supported in the `default` control plane when using the application `consumers` and the `acl` plugin. The `default` control plane is the one that is first created in each geo when you create an organization. | ||
| For non-`default` control planes, app registration is supported using the `konnect-application-auth` plugin available as of {{site.base_gateway}} 3.0. <!-- We mention using the different plugins, what do we need to do in those plugins to support app registration? Why do default CP and non-default CPs use different plugins and why those particular plugins? --> |
There was a problem hiding this comment.
This is indeed a complicated part or the product to explain. Here is some context and explanation:
Initially app registration in Konnect was implemented using a combination of acl, key-auth, and openid-connect plugins which are included in every version of Kong Gateway that is supported by Konnect. Using these plugins gives the benefits that they are compatible with Gateway consumers which can be mapped to portal applications, providing further plugin functionality like applying rate-limiting plugins based on the application consumer, etc.
This feature was developed when Konnect had only a single Control Plane per organization.
However, at the time that Konnect rolled out support for multiple Control Planes, the application registration feature was re-imagined so that it could scale to support APIs that might live in different control planes. As part of this, the plugins, keys, and consumers previously used were dropped from the design and replaced with a new plugin konnect-application-auth, credential management system, and access control system.
Migrating existing customers who were using the "legacy" (consumer-based) app registration design was not fully possible, however, because:
- Some customers were relying on the use of application
consumerswhich are no longer supported - The new design (and
konnect-application-authplugin) is only available on Kong Gateway versions 3.0+, and some customers were unable to upgrade from a 2.x version
This left the system in the following state:
- the (first) control plane in all existing orgs became known as the
defaultcontrol plane which would continue to support certain legacy behaviors (including consumer-based app reg) that would not be supported in newly created control planes - new orgs would still have their first control plane be considered
defaultand use the legacy consumer-based app registration - additional control planes created in any org would be considered "non-default"/non-legacy and use the new design centered around the
konnect-application-authplugin. These control planes are not compatible with Kong Gateway versions < 3.0 when using app reg
This has been the case up until recently, where an update was made so that new orgs will no longer receive a control plane that is considered "default" or legacy, and there is no longer support for using Kong Gateway < 3.0 with app registration in new orgs. The exception is "legacy mode" for app registration can still be turned on for any control plane if requested via support.
I hope that helps to clarify some of the context and I would be happy to discuss this more if needed.
There was a problem hiding this comment.
@Mierenga Thanks for the info! This is really helpful. Just to make sure I understand, the content I currently had would only apply to legacy users (whether they got Konnect before 3.0 or because they requested legacy through support), this wouldn't apply to new orgs? I wanted to delete this section about control planes, but I figured I should keep it with a note about "If you started using Konnect pre 3.0 gateway, keep the following in mind:" or something like that. What do you think?
There was a problem hiding this comment.
Yeah I think it would make the most sense to have the part about the legacy plugins be a secondary note. I would highlight two version requirements for compatibility with app reg. Perhaps something like this:
App registration is supported using the `konnect-application-auth` plugin available as of {{site.base_gateway}} 3.0.
For compatibility with app registration features, ensure all gateway nodes in relevant control planes are using the following minimum versions:
| Feature | {{site.base_gateway}} version |
| -------- | ------- |
| App registration with a single auth strategy | 3.0 |
| App registration with different auth strategies across multiple portals | 3.6 |
{:.note}
> **Note:** {{site.konnect_saas}} organizations created before July 2024 include a legacy-mode control plane by default, which uses a different app registration setup, including the `acl`, `key-auth`, and `openid-connect` plugins and `consumers`. These control planes are compatible with all {{site.konnect_saas}} supported versions {{site.base_gateway}}, including 2.x.There was a problem hiding this comment.
Thanks! I'll make those edits
Co-authored-by: Mike Swierenga <mike.swierenga@konghq.com>
Signed-off-by: Diana <75819066+cloudjumpercat@users.noreply.github.com>
Signed-off-by: Diana <75819066+cloudjumpercat@users.noreply.github.com>
| ## Next steps | ||
|
|
||
| Now that you know what your use cases are and which settings you'll need to configure, you can [create your Dev Portal or Dev Portals](/konnect/dev-portal/create-dev-portal). |
There was a problem hiding this comment.
Is this next steps section necessary? Technically they should be following the steps via links in the diagram.
Co-authored-by: lena-larionova <54370747+lena-larionova@users.noreply.github.com>
Description
DOCU-3951
Testing instructions
Preview links:
Checklist