gluufederation / gluu-gateway Goto Github PK

Best not to show the client secret unless the user wants to see it.

In OAuth Mode, the oauth consumer plugin should add new headers with data returned from introspection including:

• OAUTH_SCOPES
• OAUTH_EXPIRATION
• OAUTH_CLIENT_ID

A developer may have an existing client, so we need to add a way in konga to configure it.

If the client is sending UMA access tokens, it would improve security if the admin has to specifically allows this.

We are using the Gluu Server for OAuth client authentication.

This OAuth tab section should be removed... it's useless.

We should have a stop command for /etc/init.d/gluu-gateway

This makes no sense to the user? What is an UMA PAT? Use a different client if this is for oxd client authentication.

During get_token_by_code call we overwrite configuration object each time. It perfectly works with one single user, but if there are many users then we will get race condition in this place, for example:

1. user1 - code1
2. user2 - code2
   With global configuration overwrite user2 can get code1 due to race condition. Please pass parameters by reference or otherwise use own wrapper instead of global configuration object.

https://github.com/GluuFederation/gluu-gateway/blob/cda9dfc3914095c40f9f23d98e235869829f6bb5/kong-openid-rp/kong/plugins/kong-openid-rp/helper.lua#L35-36

Please refer for valid json object for UMA GluuFederation/oxAuth#688

Example

{
  "rule": {
    "and": [
      {
        "or": [
          {"var": 0},
          {"var": 1}
        ]
      },
      {"var": 2}
    ]
  },
  "data": [
    "http://photoz.example.com/dev/actions/all",
    "http://photoz.example.com/dev/actions/add",
    "http://photoz.example.com/dev/actions/internalClient"
  ]
}

I offer to do:

1. Add server-jre-8u162-linux-x64.tar.gz to to /opt/dist/app
2. Add command to installJRE. Here is method from CE setup: https://github.com/GluuFederation/community-edition-setup/blob/master/setup.py#L1120
3. Add to /etc/profile

export JAVA_HOME=/opt/jre

If the client is expired, Konga should register a new client.

In the instructions we should add a note to enable "pre-authorization" and to extend the client expiration date. That will take care of the warnings and the expiration problem.

The source for the scope expression should be hidden. If the user explicitly request to see it, it should be expose a pop-up text area (not one long line).

There should be a link to the "SECURITY" view of the API, which should display graphically the existing scope expression.

Email should not be required. You may only get a pairwise sub. Create user with even that alone.
For any other required fields (for LDAP), use random GUIDs, For a dynamically enrolled client, you will not get any userinfo.

We need to supply a nicer favicon for Gluu Gateway

1. User create oauth2-consumer with mix_mode

2. request to /photo path with oauth2_access_token in the header

3. introspect_access_token and cache it

4. control pass to RS plugin

5. get_rpt and check_Access = granted then cache RPT token {access_token: “AT1”, rpt: “rpt1”, permission: {path:”/post”, method:”GET”}}

6. Next time user request /picture path with the same oauth2_access_token

7. mode mix_mode then replace the header with rpt

8. check the cache. the cached path is /photo but requested path is /picture then here use the same RPT which is already in the cache i:e associated_rpt

The package should download the latest GLUU-SUPPORT license, so if any changes are made, they are included in the respective version. The source is here:

https://raw.githubusercontent.com/GluuFederation/gluu-gateway/master/LICENSE

This is licensed software available for use by Gluu support customers.

We need to enforce a license check before allowing a user to proceed with using the software. During license enforcement, we must confirm that the license's product parameter includes api_gateway.

GG setup asks for oxd https URL but gives http method as default.

It raises question--the http port should not be active at all on oxd. If it is, disable it.

Also, there is now a standard post installation process. See this thread

If Konga asked for profile as an OpenID Connect scope, why isn't the user being dynamically generated? Why doesn't the username display in the profile section? Also is the username noted in the logs?

Something went wrong is occur with old browser cache

Kong defines a few headers:

https://getkong.org/plugins/oauth2-authentication/#upstream-headers

We will need to add

* X-Consumer-ID, the ID of the Consumer on Kong
* ADD THIS TO PLUGIN & KONGA: X-Consumer-Custom-ID, the custom_id of the Consumer (if set)
* X-Consumer-Username, the username of the Consumer (if set)
* ADD THIS FOR OAUTH2 CLIENTS ONLY: X-Authenticated-Scope, the comma-separated list of scopes that the end user has authenticated, if available (only if the consumer is not the 'anonymous' consumer)
* OMIT: X-Authenticated-Userid, the logged-in user ID who has granted permission to the client (only if the consumer is not the 'anonymous' consumer)
* X-Anonymous-Consumer, will be set to true when authentication failed, and the 'anonymous' consumer was set instead.

Remove client secret

As Kong loads config data to the database, there needs to be a way to "clear" the data. It could be just a command line script that drops database and re-adds it.

As far as I can tell, there is no way to get back previous security setting or to change the configuration. This will not work--being able to view and change the security is essential.

Dashboard shows plugins:

But none are here:

The Kong OAuth auth plugin should not be used.

We need to write a lua -auth plugin to support using the Gluu Sever for client registration, authentication and introspection. There are many -auth examples in the Kong plugins folder, including LDAP, HMAC, basic and more.

On successful client authentication, Kong should introspect the access_token and cache it until it's expired.

NOTE: We do not want to deal with any front channel issues until we complete the OpenID Connect RP plugin. This OAuth2 client is for back-channel only authentication! Scopes have no meaning here!

Currently when you add an OAuth client, you get this:

In the Gluu Gateway, the client should be created directly against the Gluu Server OpenID Provider using Discovery and Dynamic Client Registration. The only grant type should be client_credentials.

The Register Client form should look like this.

As this is a "back channel only" client, redirect_uri is not relevant. If it's required for client registration, use https://localhost.

Success screen should look like this:

View of clients should look like this

I introduced shorter jargon for “kong_acts_as_uma_client” … now it’s just “Mix Mode”
versus “OAuth Mode” or “UMA Mode”. The checkbox labels should be updated.

# netstat -antlp | grep 1338
tcp6       0      0 :::1338                 :::*                    LISTEN      16187/node

This should be 127.0.0.0:1338

Rename kong-uma-rs to gluu-oauth2-rs

In OAuth-mode, the admin can specify which scopes are required--exactly as in UMA. The scopes claim may be present in Oauth token introspection response JSON.

For example, a person authorizes a client access token for the calendar scope. Using the Konga UI, the admin can set a policy that requires the calendar scope to call an upstream api.

Note: UMA scopes are different then OAuth scopes.

In the OAuth2 client authentication section of the consumer configuration, we should add a method to Enable or Disable API restriction. If enabled, the admin can click on a link to launch a modal window to search for and select available API's. The client can only call specified API's if client restriction is enabled.

After clicking on "security" button. it's open UMA-RS plugin section with blank page.

Add allow or deny configuration, when the path is not protected by UMA-RS.

Change to

This plugin enables the use of an external OpenID Provider for OAuth2 client registration and 
authentication. It needs to connect via `https` to Gluu's `oxd-https-extension` service, which is an OAuth2 
client middleware service.

Never hard code a link to a specific docs version.

In this case, the text should read.

Protect API paths by requiring specific UMA Scopes for certain methods.
 

Update setup script by new OXD server config file path.

A person must accept the GLUU-SUPPORT license before answering the setup wizard questions.

Ticket scopes and scope expressions are mutually exclusive

Minify CSS and JS files, So it will help to load Konga UI fastly.

These clients have different purposes? Why are they both called konga_client. Names like this should always be descriptive.

If you edit a "consumer", there is a plugins tab:

Why is UMA-RS in the "logging" section?

And when I click on the + to add an UMA_RS, I get this cryptic form:

This makes no sense to me. Can we signal to Kong not to allow the UMA RS plugin to be configured on a per client basis? This is not how it was meant to work. By definition, the consumer is not the RS (it's the UMA Client, OpenID Connect RP, or OAuth Client... but never the RS!)

Consider the diagram below

Sequence Diagrams:

• OAuth Plugin Access Phase
• UMA RS Plugin Access Phase
• OAuth Plugin Config

Notes:

• Client must explicity specify whether it is OAuth, UMA or Mix mode.
• In Mix Mode there is no support for claims gathering--need_info response is suppressed.
• In Mix Mode, UMA RS Plugin tries to obtain RPT for client and caches it
• In Mix Mode, OAuth Client plugin checks for an associated RPT token, and if present replaces the OAuth token with the RPT token.

Looks like error at the npm part.

Configuring postgres...
ALTER ROLE
CREATE DATABASE
CREATE DATABASE
Installing konga node packages...
Creating konga oxd client used to call oxd-https endpoints...
Installation failed. See:
  gluu-gateway-setup.log
  gluu-gateway-setup_error.log
for more details.

Error log:
gluu-gateway-setup_error.log

Are there any other plugins that are also missing?

We should print the Gluu Support license and ask the user:

Do you acknowledge that use of the Gluu Gateway is under the GLUU-SUPPORT license? [y|N]: 

Defaults to not accepting the license.

Need to update kong-uma-rs plugin according to updated oxd-server JSONLogic.

Are there Docker images to run this gateway within kubernetes?