Migrating from SCSP Proxy

Planning an SCSP Proxy Migration

Consider which of these steps apply to the implementation if installing Gateway to replace SCSP Proxy:

  1. Update applications to remove any Expect: Content‑MD5 headers, which are unsupported by Gateway and unneeded if scsp.autoContentMD5Computation is enabled (see Content-MD5 Checksums).

  2. (optional) Create domains, and update applications to write to them. (See Content Management API)

    • Keep using enforceTenancy=false in Swarm Storage. (See How enforceTenancy Works)

    • Update applications to start adding Content-type: application/castorcontext when creating (via POST) a domain or bucket. (See Managing Domains)

  3. (optional) Plan for a production-sized Elasticsearch cluster (See Elasticsearch Implementation) and add a Swarm Search Feed if the number of objects in the cluster is not too large to index.

Benefits of Search

Use Content UI and S3 (named objects only) with a search index, and Gateway metering can be enabled to track the content users' space and bandwidth usage, with optional quotas. (See Swarm Content UI)

Adding Authentication for Gateway

No configuration in IDSYS or policy is required when implementing Gateway to replace SCSP Proxy. Gateway's root policy.json provides full anonymous access, and the idsys.json is empty (no users) by default.

Enable PAM/LDAP users by configuring the root idsys.json and edit the root policy.json to permission GetObject, PutObject, etc. as needed if needing to grant specific read/write access to untenanted objects.

See Content Gateway Authentication

© DataCore Software Corporation. · https://www.datacore.com · All rights reserved.