koopjs / koop-provider-marklogic

A Koop Provider that can be used to exposed data in MarkLogic via Esri feature services
https://koopjs.github.io/koop-provider-marklogic/
Other
6 stars 11 forks source link

Add additional security controls #45

Closed jkerr5 closed 1 year ago

jkerr5 commented 6 years ago

Koop currently authenticates to MarkLogic as a single user and the feature service exposed by Koop does not have authentication enabled.

Investigate if/how to enable authentication for feature services. How does this work with Esri tools that consume the feature service?

tdiepenbrock commented 4 years ago

We want to implement the koop auth provider spec, most easily seen by example at https://github.com/koopjs/koop-auth-direct-file. This implements Esri's token service (https://developers.arcgis.com/rest/services-reference/generate-token.htm).

To accomplish this we'll need to modify our provider to validate user credentials supplied in the Esri service calls against marklogic somehow, potentially by calling the REST ping service. We will need to do the following tasks:

jkerr5 commented 4 years ago

This looks good to me. Thanks for the research and documenting what we need to do.

On Wed, Apr 8, 2020 at 6:59 PM Tom Diepenbrock notifications@github.com wrote:

We want to implement the koop auth provider spec, most easily seen by example at https://github.com/koopjs/koop-auth-direct-file. This implements Esri's token service ( https://developers.arcgis.com/rest/services-reference/generate-token.htm).

To accomplish this we'll need to modify our provider to validate user credentials supplied in the Esri service calls against marklogic somehow, potentially by calling the REST ping service. We will need to do the following tasks:

-

modify server.js to register an auth module that implements the koop auth provider spec. Most likely we will configure the module's name in config/default.json.

a separate DatabaseClient should be created for every unique user subject and cached for a period of time equal to the jwt expiration time. Presumably this will happen somehow via the auth module's authorize() and/or authenticate() functions.

A singleton Agent should be shared across all DatabaseClient instances. This will make the DatabaseClient instance a lightweight object suitable for caching. DatabaseClient currently uses the yakaa client ( https://www.npmjs.com/package/yakaa) by default, although we may switch shortly to the builtin Node Agent. Create the Agent just like this example:

var http = require('http'); var Agent = require('yakaa'); var keepAliveAgent = new Agent({ keepAlive: true });

Pass the keepAliveAgent in as the agent parameter to the marklogic.createDatabaseClient() function.

-

query.js should no longer create a new DatabaseClient for every request. Rather, it should use the cached client for the current subject.

It is VERY important that we NOT call releaseClient() method on the DatabaseClient. This will destroy the shared Agent as well, which will effectively break the entire application except for the first request.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/koopjs/koop-provider-marklogic/issues/45#issuecomment-611074334, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB7YAQAHYUJHUBCQERJF43RLSUNNANCNFSM4ELH6LNA .

tdiepenbrock commented 4 years ago

Commits made, still in feature/45. We need test cases now. Three classes of test cases are needed:

a) configuration-related: does the app work properly with/without auth plugins configured, misconfigured plugins, etc

b) authentication-related: does the token service work, does it properly accept/reject calls with/without valid tokens

c) authorization-related: do users only get to see what they're allowed to see

mfgumban commented 4 years ago

Test cases have been added for all auth strategies: none (default), MarkLogic, and file-based.

jkerr5 commented 1 year ago

This is complete