Skip to content

Kong/konnect-portal-dcr-handler

Repository files navigation

Konnect Portal DCR Handler

This repository is an open source reference implementation of an HTTP DCR bridge to enable Dynamic Client Registration integration between the Konnect Dev Portal and a third-party Identity Provider. The HTTP DCR bridge acts as a proxy and translation layer between your IDP and DCR applications made in the Konnect Dev Portal.

NOTE: This repository contains an example HTTP DCR bridge implementation and is not meant to be deployed in production. We encourage you to use this application as a guide to create your own implementation.

This project is utilized within our integration tests, employing Okta as the IDP, and deployed as a serverless solution on AWS Lambda. This design ensures that the Developer Portal remains implementation-agnostic with respect to the IDP implementation.

Implementation

A lightweight Fastify HTTP Server implementing the HTTP DCR API is instantiated in app.ts. The handlers (declared in handlers/handler.ts):

  • Check that the calls received from Konnect are valid using the schemas.
  • Verify (in preHandler) that the header X-API-KEY is present and is one of the API Key present in the env variable KONG_API_TOKENS, ensuring the call is legit.
  • Transform the payload and forward the call to the IDP.
  • If necessary, transform the response from the IDP to comply with the specification.

Environment configuration

The application requires specific environment variables to be set for proper functionality:

  • KONG_API_TOKENS: is the comma-separated list of tokens used by Konnect to call the application. Konnect only supports one DCR Token at a time. However, if you'd like to rotate your token, we need to be able to check against multiple values to allow for rotation. To rotate your token:
    • Generate and add a new token to KONG_API_TOKENS.
    • Change the token in Konnect Dev Portal > Settings > Application Setup > DCR Token. Be sure to save your changes.
    • Remove the older token from KONG_API_TOKENS.
  • OKTA_DOMAIN: is the base-url for calls to the external IDP. It's usually unique to your organization.
  • OKTA_API_TOKEN: is the API Token to authenticate calls to the external IDP. Various IDPs may use different auth methods.

Getting started

Prerequisites

Install dependencies

yarn install --frozen-lockfile

Run tests with

yarn test

Start local instance

yarn start

Deployment

This project is the lambda handler that the Konnect Portal project uses to execute synthetic tests for the HTTP DCR integration with Okta. It is automatically updated when merged to main branch, more information on the ci in ./github/workflows/ci.yml.

The current deployment uses an AWS Lambda and can be accessed via the Kong Lambda Plugin.

Please note that there's 2 entrypoints for the project:

  • src/app.ts: This one is used to locally test the application or run in a non lambda context
  • src/lambda.ts: This one wraps the app.ts into a lambda adapter which makes the application able to behave as a lambda app.

Example deployment via terraform module:

module "dcr_http_lambda" {
  source  = "terraform-aws-modules/lambda/aws"
  version = "6.5.0"

  function_name = "name of my function"
  runtime       = "nodejs20.x"
  timeout       = 10

  package_type   = "Zip"
  publish        = true
  create_package = false
  handler        = "lambda.handler" // Note that this is the "lambda.ts" file and the name of the exported function

  // bucket where you want to deploy the function
  s3_existing_package = {
    bucket = aws_s3_bucket.this.id
    key    = "lambda-dcr-http.zip"
  }

  // Tokens should be stored in SSM
  environment_variables = {
    OKTA_API_TOKEN  = data.aws_ssm_parameter.okta_api_token.value
    OKTA_DOMAIN     = data.aws_ssm_parameter.okta_domain.value
    KONG_API_TOKENS = data.aws_ssm_parameter.kong_api_tokens.value
  }

  cloudwatch_logs_retention_in_days = var.cloudwatch_log_retention_days
  cloudwatch_logs_kms_key_id        = data.aws_kms_alias.cloudwatch_logs.target_key_arn
}

Join the Community

Contributing

Please take the time to become familiar with our standards outlined below. First and foremost please and comply with the standards outlined in the CODE_OF_CONDUCT.

Branch naming conventions

Please follow the following branch naming scheme when creating your branch:

  • feat/foo-bar for new features
  • fix/foo-bar for bug fixes
  • test/foo-bar when the change concerns only the test suite
  • refactor/foo-bar when refactoring code without any behavior change
  • style/foo-bar when addressing some style issue
  • docs/foo-bar for updates to the README.md, this file, or similar documents
  • ci/foo-bar for updates to the GitHub workflows or actions

License

Copyright 2016-2023 Kong Inc.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.