Security & Trust on psLens

What SWS Installs in PeopleSoft

Mon, 01 Jan 0001 00:00:00 +0000

The psLens application connects to your PeopleSoft environments through a scoped, read-only subset of the SWS (Secure Web Services) framework delivered in the CHG_PSLENS Application Designer project. This page lists what installing the project changes in your environment, giving the administrator, DBA, or security reviewer the full footprint before anything is migrated. The step-by-step setup guide is at Installation.

The Install in One Paragraph

The CHG_PSLENS project is delivered as a standard Application Designer project. You import it into a development environment first, build the single whitelist table, test connectivity, and migrate it to TEST and PROD through your normal change-management path, the same way you move any other project. There is no installer, no agent, and no software on the database server. Plan for under an hour of PeopleSoft admin time for the first environment.

Code & Supply Chain

Mon, 01 Jan 0001 00:00:00 +0000

This page is for security reviewers who need to understand what is running inside psLens before approving its deployment. It covers four questions:

What code is actually running?
Can we audit it?
How is it built and shipped?
How are vulnerabilities found, disclosed, and fixed?

If you’re looking for the higher-level read-only / whitelist story, start with Security & Trust and come back here for the detail.

1. What’s Inside the Image

psLens is a single Go binary plus an embedded NATS server, packaged as a multi-stage Docker image distributed from ghcr.io/cedarhillsgroup/pslens. There is no separate database, message broker, or external worker process; one container is the whole application.

Software Bill of Materials (SBOM)

Mon, 01 Jan 0001 00:00:00 +0000

This page documents all third-party software components compiled into the psLens binary or embedded as client assets.

A machine-readable Software Bill of Materials in standard CycloneDX v1.6 format is generated automatically during the build process and is publicly accessible:

Download CycloneDX SBOM (JSON)

Licensing Posture

psLens uses only standard, permissively licensed open-source libraries.

Zero copyleft. There are no GPL, LGPL, AGPL, SSPL, or reciprocal licenses in the application.
Permissive licenses only. All runtime dependencies are licensed under Apache 2.0, MIT, BSD-2-Clause, BSD-3-Clause, or SIL Open Font License (OFL).
Safe for enterprise and on-premises deployment. Deploying or self-hosting psLens does not impose any requirement to disclose proprietary configuration, code, or schema.

Compiled Runtime Dependencies

The following external Go modules are compiled directly into the psLens server binary (cmd/server):

Authentication & Access

Mon, 01 Jan 0001 00:00:00 +0000

This page covers how end users authenticate to psLens, what access controls exist (and which deliberately don’t), and how to front psLens with your existing identity provider today.

For SSO, see SSO Today.

1. How Users Log In Today

psLens ships with optional email magic-link authentication. It is off by default in the shipped config.yaml and must be turned on for production deployments.

When auth.enabled: true:

User visits any psLens URL → redirected to /login.
User enters their email address.
psLens emails a one-time verification code to that address (only if the address is on the configured AuthorizedUsers allowlist).
User enters the code at /verify-code.
Session created in NATS KV, identified by an HTTP-only psLens_auth cookie.

Property	Value
Mechanism	Email one-time code (no passwords)
Session storage	NATS KV bucket `auth-sessions`
Session TTL	1 year (configurable)
Cookie	`psLens_auth`, HTTP-only
User allowlist	`AuthorizedUsers` in `config.yaml`, case-insensitive
Public endpoints (no auth required)	`/healthz`, `/static/*`, the auth flow itself

There are no end-user passwords for psLens to store, leak, hash, or rotate.

Data Handling & Logging

Mon, 01 Jan 0001 00:00:00 +0000

This page is for compliance reviewers and DPOs who need a precise answer to “what data does psLens hold, where, and for how long?”, and for security teams checking encryption and audit-trail posture.

For PII handling, jump to Personal Data (PII).

1. What psLens Stores

psLens persists three categories of data, all inside the customer’s own dedicated instance. There is no shared multi-tenant backend.

Where	What	Retention	Notes
`/data/nats` (NATS JetStream KV)	Alert history	Rolling window (configurable; short by default)	Alerts are about current problems. History is for trend review, not long-term audit.
`/data/nats`	Report output (Markdown)	90 days	So you can revisit past audit findings; configurable
`/data/nats`	Recently-viewed objects per user	Session-scoped	Navigation convenience; not an audit log
`/data/nats`	Encrypted DB / SWS credentials	Until deleted	AES-256-GCM, key from `PSLENS_MASTER_KEY` env var
`/data/nats`	Auth sessions (if `auth.enabled`)	Up to 1 year TTL	See Authentication & Access
`/data/projects`	Uploaded PS project archives (`.zip`)	Until deleted	Used by Project Compare; you control the upload set
`/app/config.yaml`	Configuration (DB names, SWS endpoints, optional credentials)	Until you change it	Bind-mounted from your filesystem; secrets preferably via env vars

That is the complete persistent footprint. Everything else (query results, page renders, search hits) is generated on demand and not written to disk.

Deployment & Operations

Mon, 01 Jan 0001 00:00:00 +0000

This page consolidates the operational story that an IT or DBA reviewer needs in one place. It overlaps with Installation and Deployment Options; those are the how-to references, and this page is the what-to-expect security-review companion.

1. Deployment Model

One container per customer. Each customer gets a dedicated psLens deployment: separate process, separate NATS instance, separate /data volume.
No shared multi-tenant backend. There is no Cedar Hills Group SaaS plane that customer instances talk to. Your psLens instance talks to your PeopleSoft and (optionally) your SMTP, and that is it.

Two hosting options:

Mode	Operated by	Where it runs
Managed	Cedar Hills Group	fly.io, in the region you choose at provisioning
Self-hosted	You	Docker, docker-compose, Kubernetes, or systemd on a Linux VM. Your cloud, on-prem, or air-gapped.

The choice is reversible. You can start managed and migrate to self-hosted (or vice versa). The data volume is portable and the configuration travels.

Compliance & Vendor

Mon, 01 Jan 0001 00:00:00 +0000

This page is for procurement, legal, and vendor-risk reviewers. It states current posture plainly, including where certifications do not yet exist.

If you’re filling out a vendor questionnaire (SIG, CAIQ, custom), the Security Questionnaires section is the right place to start.

1. SOC 2 — Current Posture

Cedar Hills Group is not SOC 2 certified today. Certification is on the roadmap. No committed date.

In the interim, this site documents the controls a SOC 2 Type II report would cover, so a reviewer can map them to their own framework. The relevant Trust Service Criteria and where they’re addressed:

HECVAT & Higher Education

Mon, 01 Jan 0001 00:00:00 +0000

This page documents how psLens aligns with the Higher Education Community Vendor Assessment Tool (HECVAT v4), FERPA compliance requirements, and university information security evaluations.

Institutions evaluating psLens can request our pre-populated HECVAT Lite or HECVAT On-Premises assessment workbook by contacting security@cedarhillsgroup.com.

1. FERPA and Student Data Boundaries

psLens is designed exclusively for PeopleTools system administration, security auditing, and operational monitoring.

No Student or Financial Data: psLens does not query, replicate, or store student education records, financial aid data, payment information, or course grades.
Enforced Table Whitelist: All queries execute against an institution-managed table whitelist (PS_CHG_PSLENS_WL) on the PeopleSoft application server. Queries targeting non-whitelisted records (e.g., student tables like PS_STDNT_ENRL or PS_ACAD_PROG) are rejected before execution.
In-Memory Operator Auditing: While PeopleTools security tables contain administrative operator IDs (PSOPRDEFN) and operator email addresses (PSUSEREMAIL) for access auditing, this data is processed in memory during active user requests and is not permanently synced to external databases.

2. Authentication and Access Control (AAAI)

Single Sign-On (SSO): psLens supports native OpenID Connect (OIDC) Single Sign-On against campus identity providers, including Microsoft Entra ID, Okta, Google Workspace, and Keycloak.
Email One-Time Passcode (OTP): For deployments without SSO, authentication uses 6-digit email passcodes restricted to a verified institution email domain allowlist.
Credential Storage: PeopleSoft service account credentials used by psLens are encrypted at rest using AES-256-GCM. Decryption keys are loaded from environment variables or enterprise secret vaults (e.g., 1Password) at boot time.
Session Management: Web sessions are stored in HTTP-only, secure cookies with configurable inactivity timeouts.

3. Data Residency and Hosting Models (DATA & DCTR)

Institutions can choose between two deployment models based on risk tolerance and data residency policies: