Security & Trust

psLens gives your team a window into PeopleSoft metadata. It cannot write to your database, it cannot query outside a whitelist you approve, and your instance does not share anything with anyone else’s.

The Short Version

• Read-only by design. psLens never writes to PeopleSoft. There is no code path that issues INSERT, UPDATE, or DELETE against your environment.
• No direct database credentials required. psLens connects to PeopleSoft through the SWS framework, which exposes a bounded REST API. Your database passwords stay on your side.
• Query surface is whitelisted. psLens can only query PeopleTools metadata tables that are explicitly allowed. Anything off-list is rejected before it reaches PeopleSoft.
• Dedicated instance per client. Each customer gets their own isolated deployment. No shared tenancy, no shared database, no cross-customer blast radius.
• Your PeopleSoft business data stays in PeopleSoft. psLens stores alert history and report output only, nothing else.
• Nothing is cached in the browser. Pages render server-side and stream over SSE. psLens writes nothing to LocalStorage, SessionStorage, or IndexedDB; closing the tab clears everything.

For the high-level picture of how psLens is deployed and how it talks to PeopleSoft, see the Architecture Overview. This page focuses on the security implications of that design.

How Queries Reach PeopleSoft

%%{init: {"flowchart": {"htmlLabels": true, "padding": 16, "nodeSpacing": 50, "rankSpacing": 60}}}%%
flowchart TD
    APP["psLens app<br/>(dedicated instance per customer)"]
    SWS["SWS framework<br/>(installed in your PeopleSoft environment)"]
    DB[("PeopleSoft database<br/>(read-only)")]

    APP -- "HTTPS + basic auth<br/>(token in config.yaml or env var)" --> SWS
    SWS -- "psoftQL, scoped to<br/>whitelisted tables" --> DB

    classDef ps fill:#e8f4fd,stroke:#0d6efd,stroke-width:2px,color:#000
    classDef ext fill:#fff5e6,stroke:#fd7e14,stroke-width:2px,color:#000
    class APP ext
    class SWS,DB ps

Every query psLens issues flows through this path. There is no second channel. If the SWS framework is not installed, psLens cannot see anything.

Read-Only by Design

psLens reads metadata. It does not change anything in PeopleSoft, and it has no code path that could:

• No administrative actions. Reports, alerts, and metadata browsing are all read operations.
• No PeopleCode execution. psLens inspects configuration; it does not run it.
• No project migration, no security grants, no user creation.

If you want to change something you see in psLens, you still do that in App Designer, PIA, or your existing change-management process.

Query Surface: The Table Whitelist

The SWS framework only responds to queries against tables that are explicitly whitelisted. psLens ships knowing which PeopleTools metadata tables it needs: PSRECDEFN, PSPNLDEFN, PSCLASSDEFN, PSAUTHITEM, process scheduler tables, Integration Broker tables, and similar (a known, published list).

A query that references any table outside the whitelist is rejected by SWS before it touches the database. This is enforced on your side of the connection, not the psLens side. Even if psLens were misconfigured, it could not reach into payroll, HR, financials, or any other transactional data.

When you add psLens to an environment, you see the whitelist and approve it. You can review or narrow it at any time.

Credential Handling

• The SWS endpoint uses HTTP basic auth over HTTPS.
• The auth token is stored in psLens config.yaml or injected through environment variables at deployment time.
• No PeopleSoft database username or password is ever needed by psLens.
• No single-sign-on tokens, session cookies, or end-user credentials are stored.

Rotating the SWS auth token is straightforward: rotate on the PeopleSoft side, update the psLens config or env var, restart the instance.

Deployment Isolation

Every psLens customer gets a dedicated deployment:

• One instance per customer. No shared app, no shared database, no shared filesystem.
• Hosted on fly.io by default, with deployment options to match your security requirements.
• Your data does not traverse a shared service. There is no psLens SaaS multi-tenant backend.
• If you prefer to host psLens yourself in your own cloud account or on-prem, that is supported — see installation for bare-metal and Docker options, including air-gapped environments.

What psLens Stores

psLens only persists two categories of data, and both stay inside your dedicated instance:

• Alert history. A rolling record of alerts that fired, for trend review. Retention is configurable; defaults to a short window because alerts are meant to surface current issues.
• Report output. The Markdown output of reports you have run, kept for 90 days so you can revisit audit findings or compare runs. See reports.

psLens does not copy PeopleSoft business data (employee records, financial transactions, HR data) into its own storage. Reports pull what they need at run time and summarize it; browsing and search fetch metadata on demand and display it.

What psLens Does NOT Do

• It does not write to PeopleSoft.
• It does not require a direct database connection.
• It does not store PeopleSoft business data outside of alert and report output.
• It does not share a database or application instance across customers.
• It does not phone home. Your deployment talks to your PeopleSoft environment; it does not report back to Cedar Hills Group.

Going Deeper

This page is the short version. If you’re preparing a vendor security review or filling out a SIG / CAIQ, these pages cover the topics your reviewers will ask about: current state, gaps, and roadmap, stated plainly.

• Code & Supply Chain. What code runs, source-review under NDA, dependency posture, vulnerability disclosure.
• Authentication & Access. Magic-link login today, SSO via reverse proxy, native SSO on the roadmap, why there’s no in-app RBAC.
• Data Handling & Logging. What is stored, encryption at rest and in transit, personal data handling, audit logging.
• Deployment & Operations. Network requirements, sizing, backup, upgrade, DR, monitoring.
• Compliance & Vendor. SOC 2 posture, GDPR / DPA, sub-processors, business continuity, source escrow.
• What SWS Installs in PeopleSoft. The objects, roles, and Integration Broker setup added to your environment, for the reviewer approving the install.

If a quick Q&A is all you need, the FAQ has one-paragraph answers cross-linked to the deeper pages above.

Questions Before a Demo?

If you have specific security or compliance questions (data residency, SWS role permissions on your PeopleSoft side, how to integrate with your existing SSO for the psLens login layer) raise them on the demo call or email chris.malek@cedarhillsgroup.com and we will answer in writing before you commit to anything.