Riptide Application Manager — Platform Overview

The Problem

Building a new .NET application means solving the same infrastructure problems before writing a single line of business logic:

Identity and access control. Who are your users? Enterprise employees authenticate through Azure AD or Entra ID. External users might use a public identity service or manage their own credentials. Some applications serve multiple populations simultaneously. Each implementation is different, maintained independently, and audited separately.

Authorization. Even when identity is handled by an external provider, the question of what a user is allowed to do is left to each application. Every team builds its own roles, permissions, and admin interfaces. When an organization operates multiple applications, role management is duplicated in each one.

Organizational isolation. Organizations are composed of departments, divisions, or business units that often need strict data isolation. A department's users, data, and administrative scope should be contained within that boundary. Building multi-tenant isolation correctly is difficult; building it differently for every application compounds the difficulty.

Configuration management. Applications need settings that differ across environments — feature flags, connection strings, service endpoints, business rules. Teams manage configuration through a mix of files in source control, environment variables, and manual edits. There's no standard approach and no central visibility into what's deployed where.

Security and compliance. Every application that handles sensitive data needs security headers, rate limiting, audit logging, data classification, and — increasingly — the ability to demonstrate compliance with regulatory frameworks. Teams implement these concerns at varying levels of rigor. When each application manages its own security posture independently, gaps are inevitable and hard to detect.

Cross-cutting concerns. Structured logging with correlation IDs, performance monitoring, PII handling — every team implements these independently, with varying levels of rigor.

The cumulative cost is significant. Before a team writes their first line of business logic, they spend weeks or months building identity management, authorization, configuration infrastructure, and operational tooling. And because each team builds it independently, the organization can't leverage shared investment or consistent security practices.

What Riptide Provides

The Riptide platform combines two things:

1. The Riptide Platform SDK — .NET libraries that handle the common infrastructure every application needs: identity, authorization, logging, configuration, monitoring, persistence, and dependency injection. Developers add NuGet packages and configure them. The infrastructure is handled.

2. Application Manager — a centralized server that provides identity brokering, role-based access control, configuration management, and administrative tooling across all connected applications. Administrators manage users, roles, identity providers, and application configurations from a single interface.

Together, they eliminate the repeated infrastructure work that slows down every new application project.

Identity: Choose Your Model, Change It Later

The SDK's identity component supports three modes, selectable through configuration — no code changes required:

Self-Contained Mode

The application manages its own users, passwords, and sessions internally. Authentication uses BCrypt-hashed passwords with secure session management.

When to use it: Internal tools, proof-of-concept applications, or situations where external identity infrastructure is unavailable.

{
  "Identity": {
    "Mode": "SelfContained"
  }
}

Single Sign-On Mode

The application delegates authentication to an external identity provider using OpenID Connect. The SDK handles the OIDC handshake, token validation, and claims extraction.

When to use it: Applications integrating with an organization's existing identity provider (Entra ID, Okta, Auth0, or any OIDC-compatible service).

{
  "Identity": {
    "Mode": "SingleSignOn",
    "Providers": {
      "AzureAd": {
        "Authority": "https://login.microsoftonline.com/{tenant-id}/v2.0",
        "ClientId": "your-client-id"
      }
    }
  }
}

Identity Lite Mode

The application connects to Application Manager for centralized identity and authorization. Application Manager handles user management, role assignment, capability enforcement, session tracking, and identity provider federation.

When to use it: Organizations operating multiple applications that need consistent user management, shared role definitions, centralized administration, and unified audit trails.

{
  "Identity": {
    "Mode": "RiptideAuth",
    "RiptideAuth": {
      "ServerUrl": "https://appmanager.example.com",
      "ApplicationName": "permits-portal",
      "SharedSecret": "your-shared-secret-here"
    }
  }
}

The Key Point

All three modes use the same SDK, the same application code, and the same authorization attributes. Switching modes is a configuration change, not a rewrite. A team can prototype with Self-Contained, integrate with Entra ID when ready, and move to Identity Lite when centralized management becomes valuable. The application code doesn't change.

Security: Defense in Depth, Through Configuration

The SDK's Security component provides a layered security architecture that applications adopt by adding two lines to their startup code. Like identity, the security posture is controlled through configuration — not custom code in each application.

What You Get

Calling AddRiptideSecurity() and UseRiptideSecurity() activates a middleware pipeline that handles security concerns automatically:

// Program.cs
builder.Services.AddRiptideSecurity(builder.Configuration);

var app = builder.Build();
app.UseRiptideSecurity();

This single integration provides:

1. Security headers — HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy. The Server and X-Powered-By headers are stripped. Cache-Control is set to prevent caching of sensitive responses. All configurable.

2. Rate limiting — Per-IP fixed-window rate limiting using .NET 8's System.Threading.RateLimiting. Returns 429 Too Many Requests with Retry-After headers. Configurable limits and window sizes.

3. Security context — Populated from claims on every request. Captures the authenticated user's identity, tenant, roles, device compliance state (from Entra ID token claims), and data classification level (from endpoint attributes). Propagated into HttpContext.Items so the Logging component's PII sanitization picks it up automatically.

4. Policy enforcement — A policy engine that evaluates security policies on endpoints at runtime. Developers annotate controllers with attributes; the middleware enforces the policies.

5. Mutual TLS — Client certificate validation for service-to-service communication. Supports thumbprint pinning, issuer validation, and chain verification. Extracts certificate identity into claims.

6. Audit logging — Configurable audit trail with storage provider abstraction, retention policies, request/response body capture (opt-in), and path exclusions for health and infrastructure endpoints.

Zero Trust Attributes

The SDK provides declarative attributes for endpoint-level security policy:

[ZeroTrust(MinimumTrustLevel = TrustLevel.High)]
public async Task<IActionResult> AccessSensitiveData()
{
    // Only users on compliant, MDM-managed devices reach this code
}

Trust levels are computed automatically from authentication state and device compliance claims:

[DataClassification(DataClassificationLevel.Confidential)]
public async Task<IActionResult> GetEmployeeRecords()
{
    // PII sanitization and audit logging adjust automatically
    // based on the classification level
}

Data classification levels (Public, Internal, Confidential, Restricted) propagate into the logging pipeline. The Logging component's DataSanitizationService reads the classification from the security context and adjusts PII handling accordingly — confidential endpoints get stricter sanitization without the developer writing filtering code.

Custom Security Policies

For requirements beyond the built-in attributes, the policy engine supports named policies:

[RequirePolicy("geographic-restriction")]
public async Task<IActionResult> FileAnnualReport()
{
    // Custom policy evaluates context and denies if requirements aren't met
}

Policies are evaluated by the IPolicyEngine and return Allow or Deny with a reason. Policy violations are logged but never leak internal details to the client — the response is always a generic "Access denied."

Compliance Assessment Engine

The SDK includes a compliance assessment engine with built-in templates for major regulatory frameworks:

Each template maps framework controls to SDK capabilities. The assessor evaluates whether the required capabilities are registered and properly configured — for example, whether the policy engine is active, whether security headers are enabled, whether audit logging is turned on. The result is a severity-weighted score (Critical controls weigh 4×, High 3×, Medium 2×, Low 1×) that reflects the application's actual security posture against each framework.

Organizations can register custom templates alongside the built-in ones for internal compliance requirements.

Configuration

Security is configured entirely through appsettings.json:

{
  "Riptide": {
    "Security": {
      "Enabled": true,
      "EnablePolicyEnforcement": true,
      "DefaultClassification": "Internal",
      "Headers": {
        "Enabled": true,
        "EnableHsts": true,
        "ContentSecurityPolicy": "default-src 'self'",
        "RemoveServerHeader": true
      },
      "RateLimiting": {
        "Enabled": true,
        "PermitLimit": 100,
        "WindowSeconds": 60
      },
      "Audit": {
        "Enabled": true,
        "StorageProvider": "Database",
        "RetentionDays": 2555,
        "ExcludePaths": ["/health", "/ready"]
      },
      "Compliance": {
        "Enabled": true,
        "EnabledTemplates": ["SOC2", "HIPAA", "FedRAMP"]
      }
    }
  }
}

The Key Point

Like identity, security is a configuration concern rather than a coding concern. A team adds two lines to their startup, configures the security section in appsettings.json, and gets defense-in-depth security — headers, rate limiting, zero-trust policy enforcement, data classification, audit logging, and compliance assessment — without writing security code. When the SDK's security implementation is improved or a vulnerability is patched, every application using the SDK benefits from the fix. Security quality is consistent because the implementation is shared.

Application Manager Features

Identity Brokering

Application Manager federates authentication across multiple identity providers. It doesn't replace your existing IdP — it accepts authentication assertions and normalizes them into a common user identity. A single application can simultaneously support:

• Enterprise users authenticating through Entra ID
• External users authenticating through a public identity service
• Occasional users who receive a time-limited magic link via email
• Legacy users with locally managed passwords during transition

Adding or changing identity providers is an administrative task, not a development task.

Role-Based Access Control

Identity providers tell Application Manager who someone is. Application Manager determines what they can do.

Roles are scoped to applications and composed of granular capabilities. In application code, authorization is enforced with a single attribute:

[RequireCapability("permits:approve")]
public async Task<IActionResult> ApprovePermit(Guid permitId)
{
    // Only users with the permits:approve capability reach this code
}

Developers define capabilities; administrators assign them to roles and roles to users through the admin interface. Roles can be populated manually or synchronized from identity provider groups.

Tenant Isolation

Each tenant operates as an independent administrative boundary:

• Tenant administrators manage only the users, roles, and data within their tenant
• Data queries are filtered at the database level
• Global administrators can oversee all tenants

Configuration Management

Centralized, versioned configuration management for all connected applications. Files are organized hierarchically, support version history, and can be rolled back. SDK applications fetch configuration at startup and can be notified of changes.

Security and Compliance

Application Manager operationalizes the SDK's Security component (described above) by providing a management interface for compliance across all connected applications:

• Compliance dashboard — An application-by-framework matrix showing compliance scores at each intersection. Drill into any application to see control-by-control results, score trends, and full audit history.
• Automated assessments — Assessments run on-demand or on a configurable schedule. Historical results demonstrate compliance improvement over time.
• Custom frameworks — Drop a template file into the configuration tree and it appears alongside SOC 2, HIPAA, FedRAMP, and GDPR without a restart.
• SecurityAdmin role — Access to compliance features is gated behind a dedicated role, ensuring only authorized personnel can view or trigger assessments.

Audit Trail

All operations are logged: user logins, role changes, configuration updates, session activity, administrative actions. The trail is queryable, filterable, and retained for configurable periods supporting compliance requirements.

The SDK Beyond Identity and Security

Beyond the Identity and Security components detailed above, the SDK provides components for the remaining operational concerns common to all .NET applications:

Structured Logging — Correlation IDs, structured formats, configurable providers (console, file, DataDog), PII sanitization driven by the Security component's data classification levels, and business event logging.

Performance Monitoring — Metrics collection and distributed tracing using W3C Trace Context, with support for OpenTelemetry and DataDog.

Configuration Management — Multi-provider configuration loading (local files, Azure Key Vault, Application Manager), hot reload, and validation.

Persistence — Database context lifecycle management and EF Core integration with standardized patterns.

Dependency Injection — Attribute-based service registration with multi-tenant tracking through correlation IDs.

These components work together — and with Identity and Security. A single request automatically gets a correlation ID, structured log entries, performance timing, trust-level evaluation, data classification, and audit trail integration — without the developer writing instrumentation code for each concern.

Adoption Paths

New Application

Add the SDK packages, configure the identity mode, and start writing business logic. Connect to Application Manager in Identity Lite mode for centralized management from day one.

Existing Application

Adopt incrementally. The logging and monitoring components provide immediate operational benefits without changing the identity model. Migrate to the SDK's identity component when ready — starting with Self-Contained to validate, then moving to SSO or Identity Lite.

Multiple Applications

Application Manager provides the most value when managing multiple .NET applications. Users are provisioned once and granted access to specific applications. Roles are defined per application but managed centrally. Configuration changes deploy from one interface. The audit trail spans all applications.

Technical Foundation

What This Is Not

• Not a replacement for your identity provider. Application Manager consumes identity providers; it doesn't compete with them. It extends them with centralized authorization and administration.
• .NET-specific. The SDK is a .NET library. Other languages can use Application Manager's REST API directly but don't get the integrated SDK experience.
• Not a complete operations platform. CI/CD, infrastructure provisioning, network security, and database administration remain your responsibility. The SDK and Application Manager address application-level concerns.

Contact

Email: sales@riptide.solutions