Page Comparison

...

...

Jira Legacy
server System

...

JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key MODKBEKBJ-358

Module characteristics important for request processing

Module characteristics defined in ModuleDescriptor-template.json. Here is the module descriptor from mod-authtoken:

...

Multi-tenant context execution problem

Image Added

The system is aware of 3 tenants:

• Tenant A
• Tenant B
• Tenant C

There is also some relation between the tenants so that in some cases Tenant A can be replaced with Tenant B and in another cases with Tenant C.

Module 1 can be executed in the context of Tenant A only

Module 2 can be executed either in the context of Tenant B or Tenant C but not Tenant A

To execute Modules in proper context there has to be a component to resolve the correct tenant before the request gets to the modules.

Module characteristics important for request processing

Module characteristics defined in ModuleDescriptor-template.json. Here is the module descriptor from mod-authtoken:

{
  "id": "${artifactId}-${version}",
  "name": "authtoken",
  "provides": [
    {
      "id": "authtoken",
      "version": "2.0",
      "handlers" : [
        {
          "methods" : [ "POST" ],
          "pathPattern" : "/token"
        },
        {
          "methods" : [ "POST" ],
          "pathPattern" : "/refreshtoken"
        },
        {
          "methods" : [ "POST" ],
          "pathPattern" : "/refresh"
        }
      ]
    }
  ],
  "requires" : [
    {
      "id" : "permissions",
      "version" : "5.2"
    },
    {
      "id" : "users",
      "version" : "15.0"
    }
  ],
  "filters" : [
    {
      "methods" : [ "*" ],
      "pathPattern" : "/*",
      "phase" : "auth",
      "type" : "headers"
    }
  ],
  "launchDescriptor": {
    "dockerImage": "${artifactId}:${version}",
    "dockerPull": false,
    "dockerArgs": {
      "HostConfig": {
        "Memory": 357913941,
        "PortBindings": { "8081/tcp": [ { "HostPort": "%p" } ] }
      }
    },
    "env": [
      { "name": "JAVA_OPTIONS",
        "value": "-XX:MaxRAMPercentage=66.0 -Dcache.permissions=true"
      }
    ]
  }
}

...

• handlers
• filters

There should be exactly one handler for each path. That will be of request-response type by default.

...

1. UI sends POST /note-types request with new note type details to OKAPI
2. The request is authorized by Auth module (Auth-Token)
   1. user issued the request verified to be an active one - (A) IS USER ACTIVE
   2. user permissions checked - (B) ARE PERMISSIONS VALID
3. OKAPI sends the request to Notes module
4. Notes module receives the request and processes it as follows:
   1. calls Configuration module to get the maximum number of note types allowed in the system - (C) INTERNAL CALL TO CONFIGURATION
      1. configuration request passes OKAPI and Auth as usual and gets to Configuration module which retrieves the limit and sends it back Notes module
   2. the maximum number of types limitation applied, if successful the process continuesthe process continues
   3. new note type has to be populated with user creator details, so Notes calls Users to get the details of the current user - (D) INTERNAL CALL TO USERS
      1. user request passes OKAPI and Auth as usual and gets to User module which retrieves user by id and sends it back Notes module
   4. new note type has to be populated with user creator details , so Notes calls Users to get the details of the current user - (D) INTERNAL CALL TO USERS
      1. user request passes OKAPI and Auth as usual and gets to User module which retrieves user by id and sends it back Notes module
   5. new note type populated with user creator details and saved
   6. "Created" response returned to UI

OKAPI log: okapi-post-note-type.log

Image Removed

Summary

1. 1. and saved
   2. "Created" response returned to UI

OKAPI log: okapi-post-note-type.log

Image Added

Summary

• tenant resolution can be integrated into the request flow as filter at "pre" phase
• create a POC to test the approach with tenant resolution module acts as a filter
  • POC should also include some basic logic to support Consortia business requirements at least for
    • mod-kb-ebsco-java and
    • mod-notes
  • examine any possible issues with replaced tenant
    • in particular the potential difference between tenant value in x-okapi-tenant and x-okapi-token headers

Reference information:

• Okapi Guide and Reference
• Okapi Security Model
  • Sample responses of calls issued during authorization
    • User permissions: perm-users-response.json
    • Expanded user permissions: perm-user-expanded-response.json
    • Expanded extra permissions: perm-extra-expanded-response.json
• Diagram source files
  • Simple case: get-notes.puml
  • Advanced case: post-notes.puml

...