zowe / zowe/api-layer

Storage in Caching service by caller

Open
#4,423 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement High Availability Priority: Medium size/L
Dominant language
Java
Stars
92
Forks
81
Avg merge
1d 9h
Merged PRs (30d)
46

Description

This issue is based on #4408.

The current implementation of calling Caching service to work with PAT is based on HTTP communication between GW and Caching service. The caller provide as part of the request serviceId and DN of service's certificate.

There are couple of weakness of this approach:

  • Caching service doesn't verify DN provided in header with a real certificate
    Any caller with a client certificate could write in the same storage (using a different certificate and the same DN).

  • DN depends on the certificate in usage (see header X-Certificate-DistinguishedName and x509 authentication scheme)
    If the certificate is updated, it should contain the same DN, otherwise all records are forgotten (using a different DN would lead to search for different records)

Using DN seems to be a fragile solution. The better solution should validating of certificate and storing just under the serviceId.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the HTTP communication between the gateway and Caching service described in the issue, including the serviceId, certificate DN, X-Certificate-DistinguishedName header, and x509 authentication scheme. Compare how caller certificates are validated and how storage keys are selected. Done means callers are validated by certificate and records are stored under serviceId without depending on certificate DN.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
authentication, backend, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.