Enabling user authentication will allow anonymous users browsing the Dev Portal to register for a developer account.
User authentication must be enabled to configure any further settings related to identity providers, RBAC, developer & application registration, or specifying application auth strategies and API keys.
Identity providers (IdPs) manage authentication of developers signing into the Dev Portal.
Konnect’s built-in authentication provider is used by default. This option generates API keys for developers.
OIDC or SAML providers can be configured as integrated IdP providers.
Learn more about configuring IdPs in Self-service developer & application registration.
v3.6+ An API must be linked to a Konnect Gateway Service to be able to restrict access to your API with authentication strategies.
Registration of developer accounts and creation of applications both require approval by Dev Portal admins by default. These approvals are managed in Access and Approvals.
The following explains the behavior when auto-approval for developers is configured:
- Enabled: Anyone can sign up for a developer account without any further approval process.
- Disabled: Dev Portal admins have to approve any new sign up in Access and Approvals.
The following explains the behavior when auto-approval for applications is configured:
- Enabled: When any approved developer creates an Application, it will be automatically approved and created.
- Once an application is approved, the developer will be able to use it to create API Keys.
- Disabled: Dev Portal admins have to approve any new Applications in Access and Approvals before a developer can create API Keys.
When RBAC is enabled for a Dev Portal, the option to configure API access policies for developers will be available when publishing the API to a portal. Otherwise, any logged in developer can see any published API that is set to Visibility: public.
An API must be linked to a Konnect Gateway Service v3.6+ or control plane v3.13+ to restrict access to your API with authentication strategies.
Authentication strategies determine how published APIs are authenticated, and how developers create API Keys.
When you link an API to a Gateway, you have two options:
These plugins are responsible for applying authentication and authorization on the Gateway Service or control plane.
The authentication strategy that you select for the API defines how clients authenticate.
The following table can help you decide which option to pick:
|
Option
|
KAA plugin
|
ACE plugin
|
|
Scope
|
Linked to a single Gateway Service
|
Linked to an entire control plane
|
|
Plugin applied…
|
Automatically on the Gateway Service linked to the API
|
Manually
|
|
Managed by…
|
Konnect. You can only modify it by configuring JSON in the advanced configuration for your application auth strategy.
|
You, by manually configuring the plugin.
|
|
Kong Gateway version
|
3.6 or later
|
3.13 or later
|
|
Can be used with declarative configuration
|
No, because the plugin is applied automatically
|
Yes, because you must configure the plugin
|
|
Can be used with API packages
|
No
|
Yes
|
Do not configure the KAA and ACE plugins on the same control plane because their overlapping interactions can be unpredictable.
Determines the default authentication strategy applied to an API as it is published to a portal. Changing this default will not retroactively change any previously published APIs.
To create a new application authentication strategy, see Application Auth.
The authentication strategy only affects the hosted Service and does not affect developers browsing the Dev Portal from viewing APIs. To change visibility of APIs in the Dev Portal, see Default Visibility and Role-Based Access Control.