System Overview

System architecture and Connectivity

Sentinel is designed to integrate seamlessly with PeopleSoft environments, enhancing security management, compliance reporting, and workflow automation without modifying core PeopleSoft functionality. The architecture emphasizes security, scalability, and minimal footprint, typically deployed as a virtual machine (VM) appliance on customer infrastructure.

Application: Web-Based, Built for Chrome

Sentinel is a fully web-based application, delivered as a modern, browser-accessible interface for PeopleSoft administrators and security teams. It leverages HTML5, JavaScript, and responsive design to provide interactive dashboards, reports, and workflows. The application is optimized for Google Chrome, ensuring compatibility with Chrome's rendering engine (Blink), security features (e.g., sandboxing, secure cookie handling), and performance for handling large datasets like user/role audits or permission analyses.

• User Interface: Fluid-like UI (inspired by PeopleSoft Fluid) with drag-and-drop elements, real-time filters, and export options (CSV, PDF, Excel). Supports role-based access control (RBAC) for viewing/editing security data.

• Chrome Optimization: Built with Chrome DevTools in mind for debugging; supports Chrome's extensions for productivity (e.g., session management). Avoids legacy browser dependencies like ActiveX or Flash, ensuring cross-platform use (Windows, macOS, Linux via Chrome).

• Application Model: Runs as a single-page application (SPA) for faster navigation, with API-driven backend calls to fetch PeopleSoft data on-demand.

• Security Considerations: The web app enforces HTTPS-only access and supports integration with SSO (e.g., SAML via PeopleSoft or external IdP). Regular updates from Sentinel Software address browser-specific vulnerabilities.

Single Sign-On

The preferred and recommended login method is SAML 2.0 for exchanging authentication and The preferred and recommended login method is SAML 2.0 for exchanging authentication and authorization data between security domains—specifically, between an Identity Provider (IdP) (e.g., Okta, Azure AD/Entra ID, Ping Identity, OneLogin, or your enterprise IdP).

• Cross-domain single sign-on: Users authenticate once via their enterprise IdP and gain access to Sentinel without re-entering credentials.

• Centralized identity management: Leverages existing corporate credentials, reducing password fatigue and improving compliance.

• Stronger security: Supports federated authentication, attribute mapping (e.g., roles/groups), and protocols for secure assertion exchange (signed/encrypted as configured).

• Web-based scenarios: Enables SP-initiated (user accesses Sentinel directly) or IdP-initiated (starts from corporate portal) SSO flows.

Web Server

Nginx serves as the web server and reverse proxy for Sentinel, handling incoming HTTP/HTTPS traffic, load balancing (if scaled), and SSL/TLS termination. It's chosen for its lightweight footprint, high performance, and robust security features compared to alternatives like Apache.

• Reverse Proxy Role: Binds to external ports (80 for HTTP redirect, 443 for HTTPS) and proxies requests to the internal Sentinel application (typically on localhost port 8787 or similar). This isolates the core app from direct internet exposure.

• Encryption: Mandatory use of SSL/TLS certificates (e.g., Let's Encrypt, self-signed for intranet, or commercial like DigiCert). Nginx config handles traffic encryption/decryption, supporting TLS 1.3 for modern ciphers (e.g., AES-256-GCM) and perfect forward secrecy.

• Configuration Highlights: Includes rate limiting to prevent DDoS, access logs for auditing, and headers for security (e.g., X-Frame-Options, Content-Security-Policy to mitigate XSS/CSRF).

• Security Considerations: Encrypt all traffic (no plain HTTP in production). Regularly patch Nginx for CVEs (e.g., via yum/apt updates). In DMZ setups, restrict inbound traffic to ports 80/443 via firewall rules.

• During VM deployment, Nginx is pre-configured but customizable via /etc/nginx/nginx.conf or site-specific files.

• SSL Certificate: Generate/install certs: Use openssl or Certbot for auto-renewal. Example config snippet:text

server {
    listen 443 ssl;
    server_name sentinel.your.domain;
    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;
    location / {
        proxy_pass http://127.0.0.1:8787;
        proxy_set_header Host $host;
    }
}

Sentinel Database: PostgreSQL

PostgreSQL is the internal database engine for Sentinel, storing its own configuration, audit logs, cached PeopleSoft data, and custom reports. It's an open-source relational database chosen for reliability, ACID compliance, and extensibility (e.g., JSONB for semi-structured data).

• Schema and Storage: Sentinel uses PostgreSQL to persist data like user sessions, security baselines, and workflow states. Binds to localhost (e.g., 127.0.0.1:5432) for security, with daily backups to filesystem or external storage (e.g., S3-compatible or NAS).

• Performance: Supports indexing for fast queries on large PeopleSoft-derived datasets (e.g., PSOPRDEFN table mirrors).

• Version: Typically PostgreSQL 13+ (or latest stable), with extensions like pg_trgm for fuzzy searches in reports.

• Security Considerations: Use strong passwords for the sentinel_user role. Enable row-level security if needed. Encrypt data at rest (e.g., via LUKS on VM disk) and in transit (SSL for connections, though localhost-only by default).

PeopleSoft Access: ODBC to Oracle Database

Sentinel connects to PeopleSoft via ODBC (Open Database Connectivity) for read-only (or limited write) access to the Oracle database backend. This allows querying tables like PSOPRDEFN for user profiles, roles, and permissions without direct app server integration.

• ODBC Driver: Uses Oracle ODBC driver (e.g., Instant Client) to establish connections. Sentinel pulls data for analysis (e.g., risk scoring, SOD checks) and can push updates (e.g., role assignments) if configured.

• Client-Managed Account: Customers create a dedicated Oracle user (e.g., SENTINEL_READ) with granular permissions. No default or vendor backdoors – all access is client-controlled.

• Permissions: Minimum grants include SELECT on security tables (e.g., PSOPRDEFN, PSROLEUSER, PSAUTHITEM); INSERT/UPDATE for provisioning workflows. Avoid SYSADM-like privileges to minimize risk.

• Security Considerations: Encrypt ODBC traffic (Oracle Net SSL). Use least-privilege principle; audit grants regularly. Client manages password rotation and revocation – Sentinel Software has no access post-deployment.

Client Domain

Sentinel uses the client's custom domain (e.g., sentinel.yourcompany.com) for access, resolved via DNS to the VM's external IP. Deployment is flexible: in a DMZ for controlled external access or fully intranet for internal-only use.

• DNS Resolution: Client DNS server maps the domain to the Sentinel VM IP (e.g., A record: sentinel.your.domain → 192.168.7.8).

• DMZ Placement: Ideal for semi-external access (e.g., VPN users); isolates from core network with firewalls allowing only HTTPS ingress.

• Intranet Placement: For fully internal deployments; no public exposure, accessed via internal DNS.

• Security Considerations: Use split-DNS if DMZ-exposed (internal vs. external resolution). Implement WAF (e.g., ModSecurity with Nginx) for app-layer protection. Regular pen tests cover the domain endpoint.