My published API is private in Dev Portal, how do I allow developers to see it?
If an API is published as private, you must enable Dev Portal RBAC and developers must sign in to see APIs.
In Okta, you’ll need your authorization server issuer URL and create the following:
In Konnect, configure an OIDC auth strategy with your Okta issuer URL, your Okta claim name, client_credentials
for the auth_methods
, and your custom Okta scope. Any developers who register an application with an API with this authentication strategy applied to it can authenticate by sending Authorization: Basic $OKTA_CLIENT_ID:$OKTA_CLIENT_SECRET
as a header, where $OKTA_CLIENT_ID:$OKTA_CLIENT_SECRET
are base64 encoded.
This is a Konnect tutorial and requires a Konnect personal access token.
Create a new personal access token by opening the Konnect PAT page and selecting Generate Token.
Export your token to an environment variable:
export KONNECT_TOKEN='YOUR_KONNECT_PAT'
Run the quickstart script to automatically provision a Control Plane and Data Plane, and configure your environment:
curl -Ls https://get.konghq.com/quickstart | bash -s -- -k $KONNECT_TOKEN --deck-output
This sets up a Konnect Control Plane named quickstart
, provisions a local Data Plane, and prints out the following environment variable exports:
export DECK_KONNECT_TOKEN=$KONNECT_TOKEN
export DECK_KONNECT_CONTROL_PLANE_NAME=quickstart
export KONNECT_CONTROL_PLANE_URL=https://us.api.konghq.com
export KONNECT_PROXY_URL='http://localhost:8000'
Copy and paste these into your terminal to configure your session.
This tutorial requires Kong Gateway Enterprise. If you don’t have Kong Gateway set up yet, you can use the quickstart script with an enterprise license to get an instance of Kong Gateway running almost instantly.
Export your license to an environment variable:
export KONG_LICENSE_DATA='LICENSE-CONTENTS-GO-HERE'
Run the quickstart script:
curl -Ls https://get.konghq.com/quickstart | bash -s -- -e KONG_LICENSE_DATA
Once Kong Gateway is ready, you will see the following message:
Kong Gateway Ready
decK is a CLI tool for managing Kong Gateway declaratively with state files. To complete this tutorial you will first need to install decK.
For this tutorial, you’ll need Kong Gateway entities, like Gateway Services and Routes, pre-configured. These entities are essential for Kong Gateway to function but installing them isn’t the focus of this guide. Follow these steps to pre-configure them:
Run the following command:
echo '
_format_version: "3.0"
services:
- name: example-service
url: http://httpbin.konghq.com/anything
routes:
- name: example-route
paths:
- "/anything"
service:
name: example-service
' | deck gateway apply -
To learn more about entities, you can read our entities documentation.
For this tutorial, you’ll need a Dev Portal and some Dev Portal settings pre-configured. These settings are essential for Dev Portal to function but configuring them isn’t the focus of this guide. If you don’t have these settings already configured, follow these steps to pre-configure them:
curl -X POST "$KONNECT_CONTROL_PLANE_URL/v3/portals" \
-H "Accept: application/json"\
-H "Content-Type: application/json"\
-H "Authorization: Bearer $DECK_KONNECT_TOKEN" \
--json '{
"name": "MyDevPortal",
"authentication_enabled": true,
"auto_approve_applications": true,
"auto_approve_developers": true,
"default_api_visibility": "public",
"default_page_visibility": "public"
}'
export PORTAL_ID='YOUR-DEV-PORTAL-ID'
export PORTAL_URL='YOUR-DEV-PORTAL-DOMAIN'
Create a page in your Dev Portal so published APIs will display:
curl -X POST "$KONNECT_CONTROL_PLANE_URL/v3/portals/$PORTAL_ID/pages" \
-H "Accept: application/json"\
-H "Content-Type: application/json"\
-H "Authorization: Bearer $DECK_KONNECT_TOKEN" \
--json '{
"title": "My Page",
"slug": "/",
"description": "A custom page about developer portals",
"visibility": "public",
"status": "published",
"content": "# Welcome to My Dev Portal\nExplore the available APIs below:\n::apis-list\n---\npersist-page-number: true\ncta-text: \"View APIs\"\n---\n"
}'
Register a test developer account with your Dev Portal by navigating to your Dev Portal and clicking Sign up:
open https://$PORTAL_URL/
For the purpose of this tutorial, we’ve set our Dev Portal to automatically approve developer registrations.
Create an API using the /v3/apis
endpoint:
curl -X POST "$KONNECT_CONTROL_PLANE_URL/v3/apis" \
-H "Accept: application/json"\
-H "Content-Type: application/json"\
-H "Authorization: Bearer $DECK_KONNECT_TOKEN" \
--json '{
"name": "MyAPI",
"attributes": {
"env": [
"development"
],
"domains": [
"web",
"mobile"
]
}
}'
Export the ID of your API from the response:
export API_ID='YOUR-API-ID'
First, send a request to the /v2/control-planes
endpoint to get the ID of the quickstart
Control Plane:
curl -X GET "$KONNECT_CONTROL_PLANE_URL/v2/control-planes?filter%5Bname%5D%5Bcontains%5D=quickstart" \
-H "Accept: application/json"\
-H "Content-Type: application/json"\
-H "Authorization: Bearer $DECK_KONNECT_TOKEN"
Export your Control Plane ID:
export CONTROL_PLANE_ID='YOUR-CONTROL-PLANE-ID'
Next, list Services by using the /v2/control-planes/{controlPlaneId}/core-entities/services
endpoint:
curl -X GET "$KONNECT_CONTROL_PLANE_URL/v2/control-planes/$CONTROL_PLANE_ID/core-entities/services" \
-H "Accept: application/json"\
-H "Content-Type: application/json"\
-H "Authorization: Bearer $DECK_KONNECT_TOKEN"
Export the ID of the example-service
:
export SERVICE_ID='YOUR-GATEWAY-SERVICE-ID'
Associate the API with a Service using the /v3/apis/{apiId}/implementations
endpoint:
curl -X POST "$KONNECT_CONTROL_PLANE_URL/v3/apis/$API_ID/implementations" \
-H "Accept: application/json"\
-H "Content-Type: application/json"\
-H "Authorization: Bearer $DECK_KONNECT_TOKEN" \
--json '{
"service": {
"control_plane_id": "'$CONTROL_PLANE_ID'",
"id": "'$SERVICE_ID'"
}
}'
Now you can publish the API to your Dev Portal using the /v3/apis/{apiId}/publications/{portalId}
endpoint:
curl -X PUT "$KONNECT_CONTROL_PLANE_URL/v3/apis/$API_ID/publications/$PORTAL_ID" \
-H "Accept: application/json"\
-H "Content-Type: application/json"\
-H "Authorization: Bearer $DECK_KONNECT_TOKEN"
Using your Okta credentials, log in to the Okta portal and click Security > API in the sidebar. The default Issuer URI should be displayed in the Authorization Servers tab. If you are using an authorization server that you configured, copy the issuer URL for that authorization server.
Export your issuer URL as an environment variable:
export ISSUER_URL='YOUR-ISSUER-URL'
To map an application from the Dev Portal to Okta, you have to create a claim.
Click Security > API in the sidebar.
Select the authorization server that you want to configure.
Click the Claims tab, and then click Add Claim.
Enter a name for this claim, and enter app.clientId
for Value. You can leave the Value type as “Expression”, and include it in any scope.
Export the name of your claim in Okta as an environment variable:
export OKTA_CLAIM_NAME='YOUR-OKTA-CLAIM-NAME'
When self-managed OIDC is enabled in Dev Portal, developers must create an application in Okta themselves.
export OKTA_CLIENT_ID='YOUR-OKTA-APP-CLIENT-ID'
export OKTA_CLIENT_SECRET='YOUR-OKTA-APP-CLIENT-SECRET'
Because we’re using the client_credentials
auth method, you must create a custom Okta scope and access policy.
Click Security > API in the sidebar.
Select the authorization server that you want to configure.
Click the Scopes tab, and click Add Scope.
Add a scope called api.access
.
On the Access Policy tab, create a new access policy and assign your Okta application you just created.
Add a new rule and configure the following settings:
api.access
Configure Okta OIDC application authentication using the /v2/application-auth-strategies
endpoint:
curl -X POST "$KONNECT_CONTROL_PLANE_URL/v2/application-auth-strategies" \
-H "Accept: application/json"\
-H "Content-Type: application/json"\
-H "Authorization: Bearer $DECK_KONNECT_TOKEN" \
--json '{
"name": "Okta OIDC",
"display_name": "Okta OIDC",
"strategy_type": "openid_connect",
"configs": {
"openid-connect": {
"issuer": "'$ISSUER_URL'",
"credential_claim": [
"'$OKTA_CLAIM_NAME'"
],
"auth_methods": [
"client_credentials"
],
"scopes": [
"api.access"
]
}
}
}'
Export the ID of the Okta OIDC auth strategy:
export AUTH_STRATEGY_ID='YOUR-AUTH-STRATEGY-ID'
Now that the application auth strategy is configured, you can apply it to an API using the /v3/apis/{apiId}/publications/{portalId}
endpoint:
curl -X PUT "$KONNECT_CONTROL_PLANE_URL/v3/apis/$API_ID/publications/$PORTAL_ID" \
-H "Accept: application/json"\
-H "Content-Type: application/json"\
-H "Authorization: Bearer $DECK_KONNECT_TOKEN" \
--json '{
"auth_strategy_ids": [
"'$AUTH_STRATEGY_ID'"
]
}'
This request will also publish the API to the specified Dev Portal.
To use your Okta OIDC credentials to authenticate with an app, you must first create an app in Dev Portal with the test developer account you created previously.
open https://$PORTAL_URL
You should see MyAPI
in the list of APIs.
Now, validate the setup by accessing the example-route
Route and passing the user credentials in Basic username:password
format. When you use the Okta OIDC authentication strategy, you use your Okta client ID as the username and your Okta client secret as the password, but they must be base64 encoded.
First, encode your credentials and export them:
echo -n "$OKTA_CLIENT_ID:$OKTA_CLIENT_SECRET" | base64
export ENCODED_CREDENTIALS='YOUR-ENCODED-CREDENTIALS'
Now, you can validate that Okta OIDC authentication was successfully enabled by sending a request with your encoded Okta credentials to the example-route
Route:
curl -i -X GET "$KONNECT_PROXY_URL/anything" \
-H "Authorization: Basic $ENCODED_CREDENTIALS"
If you created a new control plane and want to conserve your free trial credits or avoid unnecessary charges, delete the new control plane used in this tutorial.
My published API is private in Dev Portal, how do I allow developers to see it?
If an API is published as private, you must enable Dev Portal RBAC and developers must sign in to see APIs.