-
可以使用一些代码来实现此目的，而不是使用OpenID connect插件；实际上，您需要实现一个授权服务器，该服务器通过Admin(8001)端口与Kong进行通信，并授权使用带有外部给定用户ID的API.
It's possible to do this with some code around, instead of using the OpenID connect plugin; in effect you need to implement an Authorization Server which talks to Kong via the Admin (8001) port and authorizes the use of an API with externally given User Ids.
简而言之，它如下(此处是授权码授予):
In short, it goes as follows (here for the Authorization Code grant):
- 不是直接向Kong询问令牌，而是向授权服务器发送请求以获取特定API的令牌(硬编码或参数化，具体取决于您的需求)，并包括需要的应用程序的客户端ID通话中进行访问(实际上是实现了
/authorize端点)
- 授权服务器现在需要使用所需的任何IdP进行身份验证，以便您在授权服务器中拥有经过身份验证的用户
- 现在通过Kong Admin API获取API的配置代码，并点击Kong Gateway(端口8443)的
/oauth2/authorize端点，包括配置密钥；请注意，您可能还需要通过Admin API查找应用程序客户端ID的客户端密码，以使此工作正常进行
- 在
POST到/oauth2/authorize中包括客户端ID，客户端机密，经过身份验证的用户ID(来自您的自定义IdP)以及范围.这些值将使用应用程序现在可以使用授权码声明的访问令牌添加到对API的后端调用中
- Kong会给您一个授权码，您将通过302重定向将其传递回应用程序(为此，您需要阅读OAuth2规范)
- 应用程序使用其客户端和机密信息以及授权码从Kong的端口8443 URL
/oauth2/token获取访问令牌(和刷新令牌).
- Instead of asking Kong directly for tokens, hit the Authorization Server with a request to get a token for a specific API (either hard coded or parameterized, depending on what you need), and include the client ID of the application which needs access in the call (you implement the
/authorize end point in fact)
- The Authorization Server now needs to authenticate with whatever IdP you need, so that you have the authenticated user inside your Authorization Server
- Now get the provision code for your API via the Kong Admin API, and hit the
/oauth2/authorize end point of your Kong Gateway (port 8443), including the provision key; note that you may need to look up the client secret for the application client id also via the Admin API to make this work
- Include client id, client secret, authenticated user id (from your custom IdP) and optinally scope in the
POST to /oauth2/authorize; these values will be added to backend calls to your API using the access token the application can now claim using the authorization code
- Kong will give you an Authorization Code back, which you pass back to the application via an 302 redirect (you will need to read the OAuth2 spec for this)
- The application uses its client and secret, with the authorization code, to get the access token (and refresh token) from Kong's port 8443, URL
/oauth2/token.
听起来比最后要复杂.我为基于kong和node.js的wicked.haufe.io进行了此操作，并向Kong添加了一个开放源代码开发人员门户.以下两个项目中有很多代码，它们显示了可以与任何IdP集成的方法:
It sounds more involved than it is in the end. I did this for wicked.haufe.io, which is based on Kong and node.js, and adds an open source developer portal to Kong. There's a lot of code in the following two projects which show what can be done to integrate with any IdP:
- https://github.com/apim-haufe-io/wicked.portal-kong-adapter
- https://github.com/Haufe-Lexware/wicked.auth-passport
- https://github.com/Haufe-Lexware/wicked.auth-saml
我们目前正在调查是否也可以向wicked添加默认授权服务器，但是现在您必须自己滚动/分叉.
We're currently investigating to see whether we can also add a default authorization server to wicked, but right now you'd have to roll/fork your own.
也许这会有所帮助，马丁
Maybe this helps, Martin