This diagram illustrates the architecture of Gluu Gateway and some of its components:
The following sections explain the numbered points in the diagram:
1. Admin UI#
The first step is setting up configuration and adding security plugins. Gluu Gateway (GG) will provide its
Admin UI on port
:1338. Use this UI to add your API or Web application (such as Upstream Service/API/Web) with
kong service object,
kong route object,
create OpenID Connect client,
kong consumer object and configure the
2. Security configuration using UI#
The GG UI uses the Kong Admin APIs to configure Kong's Services, Routes, Consumers and Plugins.
3. Security configuration using Kong API#
Instead, you can directly use the Kong Admin APIs to configure the Kong's Services, Routes, Consumers and Plugins. You can find API descriptions in the Kong Docs and GG plugins docs for Gluu plugins configuration API.
4. The UI uses the oxd server to manage the OP Client#
The UI uses the oxd server endpoint during plugin configuration to create and manage the OpenID Connect Client.
5. Upstream API/Web Application registration#
The Upstream Service is the Rest API/Web application to protect using Kong and the plugins, as discussed in point 1, above. The Kong Service is the object where the Upstream Application is registered. You can register multiple upstream applications. As shown in diagram, there are three different upstream applications registered in Kong. Upstream Apps should be locally hosted and not publically accessible. However, the Kong proxy endpoint should be opened for end-users or client applications. Check the Services and Routes docs for upstream application registration in Kong.
6. OpenID Connect Server configuration#
This is the last configuration step. The UI creates the OP Client, which can be managed using oxTrust, the Gluu Server UI.
Do not update the client using the OP server, always use the oxd server's
/update-site endpoint to update the client, since GG uses the oxd server with both the client and OP server.
7. Client Application requests a token using the oxd server#
The client application sends a request to the application endpoint (i.e. the Kong proxy endpoint :443). The admin has to provide the OP Client's
client_secret to the client application for it to use these credentials to get the OAuth token and send a request to access registered resources in GG.
The client application can use the oxd server endpoint to get the token. In this case, it needs to use the oxd server endpoints.
8. Client Application request for Token directly to OP server endpoints#
This is same as the previous step, but this time the client application directly communicates with the OP server using
client_secret to get tokens.
9. Client Application request to protected resources#
Now the token is with the client application. It will send a request to the Kong proxy endpoint with the token in the
10. Kong executes the configured plugins#
At this point, Kong executes all configured plugins and uses the oxd server to validate the token with the OP Server. Using the
OAuth Plugin, for example, the plugin uses the
/introspect-access-token endpoint to validate the token.
11. The oxd server sends a request to the OP Server#
The oxd server sends a request to the OP server for authentication and authorization. Using the
OAuth Plugin, for example, the oxd server sends a request to the OP server's introspection endpoint to validate the token.
12. Send Upstream response to Client Application#
After successful client authentication and authentication, Kong sends an upstream response to the client application.