Build exactly the UI you need.
Deploy it in days, not quarters.
Describe what you need. The platform builds, secures, and deploys it — with the same enterprise-grade security as every other part of EmpowerNow. Custom admin screens, partner portals, tenant-specific workflows — production-ready, not a side project.
Your team builds real React apps and deploys them into the platform as first-class plugins — same authorization, same audit trail, same security as the core product. No watered-down extension API. No iframe sandbox. AI agents can build and deploy them too.
Enterprise UI extensibility is broken.
Most platforms give you two choices: fork the product, or extend it with ungoverned iframes and scripts that bypass your authorization fabric. Both paths create security and maintenance nightmares.
Internal URLs in the browser
Extensions call microservices directly. Service mesh addresses, internal ports, and privileged credentials end up in JavaScript bundles. One XSS exploit exposes the entire backend topology.
Separate, weaker auth
UI extensions get their own RBAC model — disconnected from the authorization fabric that governs APIs and automation. What the PDP denies via API, the iframe allows via UI.
No integrity verification
Extensions load arbitrary scripts at runtime. No hash verification. No tamper detection. No version compatibility contract. The supply chain attack surface is wide open.
Fork or wait
Need a custom admin surface? Fork the codebase and maintain it forever — or submit a feature request and wait. Neither option scales for customer-specific or tenant-specific UI needs.
What this means for your organization
New screens and workflows go live in days, not quarters. Describe what you need, review it, deploy it. Projects finish instead of stalling in backlogs.
Every custom screen runs under the same security rules as the rest of the platform. No shortcuts, no weaker auth model, no separate security review.
Build screens tailored to each team, tenant, or partner — not one-size-fits-all admin pages. Custom doesn't mean compromised.
Everything your custom screens do is logged, signed, and provable — same audit trail as the core platform. Compliance never wonders what happened.
Why this is different
Most identity platforms ship a UI. EmpowerNow ships a governed plugin platform where extensions are first-class citizens in the authorization fabric.
| Capability | EmpowerNow Experience | Traditional platforms |
|---|---|---|
| Extension model | First-class React plugins with PDP/Membership/BFF | Ad-hoc iframes or forked codebase |
| Authorization model | Same PDP as APIs + 4 protection tiers | Separate UI RBAC, disconnected from API auth |
| Backend access | BFF proxies all calls. No internal URLs in browser. | Extensions call microservices directly |
| Bundle integrity | SHA-256 hashes on manifests | No verification |
| AI workloads | ARIA Shield (BFF) + MCP Gateway (tools) = dual PEP | LLM keys in client code |
| Agent-built extensions | MCP tools: scaffold → validate → deploy → register | Manual development only |
| Governance | Same proof chain as API-driven flows | UI actions bypass audit |
How it works
Plugins are real React apps — routes, widgets, data views — mounted in a shared shell. The BFF is the control plane for the browser. Credentials and internal URLs never reach client code.
The BFF is the control plane for the browser. Plugins see /api/..., not http://microservice:8003/.... Backend trust, token exchange, and service credentials stay server-side.
Same AuthZEN PDP as APIs and automation — not a separate, weaker UI-only RBAC.
Secure by architecture, not configuration
Every layer enforces boundaries that cannot be bypassed by plugin code.
No credentials in the browser
Plugin code loads via same-origin BFF proxy. CSP stays strict. No internal service URLs, no CDN trust chains, no token leakage. Every API call is stamped with plugin identity.
Declared permissions, server-enforced
Manifests declare which APIs each plugin may call. The BFF enforces the allow-list. Undeclared endpoints are denied by default. SHA-256 integrity hashes reject tampered bundles at load time.
Dual-PEP for AI workloads
Where plugins include AI features, ARIA Shield enforces budgets and classification on the BFF path. MCP Gateway governs tool execution. No model keys in client code.
A fleet of governed plugins — not a single app
Every major capability ships as a plugin. The pattern is repeatable: customer extensions use the exact same architecture as first-party features.
MCP Admin
Server management, tool registration, and policy configuration for the ARIA MCP stack — delivered as a plugin.
Partner Portal
14-view portal for B2B partner onboarding: signup, dashboards, claims, directory, invitations, and verification.
OAuth Vault
User-facing connector management — connect, delegate, disconnect. The BFF as secure proxy for the zero-trust vault.
SAP AccessPulse
Self-service SAP access governance: request builder, real-time SoD pre-check, approval tracker, emergency access. No SAP GUI.
Identity Core & domain plugins
Policy studio, catalog studio, reporting — all as plugins sharing one shell and one auth fabric. Customer extensions use the same architecture.
Your custom plugins
Customer extensions live in dedicated repos and deploy as first-class plugins — same BFF, same PDP, same proof chain as everything above.
AI agents can build plugins too
Describe a new admin surface in natural language. A coding assistant scaffolds it, validates security, deploys with integrity hashes, and registers it with the PDP — all governed, all audited. No unsigned code reaches production.
Technical deep-dive Under the hood: Experience plugin runtime
Manifest schema
Each plugin declares: identity (id, version, display name), contributions (routes with path/component, widget slots for dashboard integration), proxy needs, and authorization config (PDP application ID, resource/action on routes, optional tab-level control). Plugins without proper authorization configuration surface as "Not Configured" in the access matrix. Manifests live in ServiceConfigs/BFF/config/plugins/manifests/*.yaml.
Build and deploy pipeline
Standard pipeline: npm run build → dist/index.esm.js → copy to ServiceConfigs/BFF/plugins/<id>/<version>/ → update manifest with integrity hash → restart BFF. Customer extensions live in dedicated repos; artifacts land in ServiceConfigs, not inside core experience/ trees.
Plugin SDK surface
Intended surface: api.fetch (governed HTTP), useQuery (React Query integration), sse.subscribe (server-sent events), authz.evaluate (inline PDP check), plus logging and telemetry hooks. The narrow SDK reduces the attack surface — ungoverned fetch to arbitrary URLs is caught and blocked.
Host compatibility
engine.experience (semver) concept: plugins declare which Experience host versions they support. The host rejects incompatible plugins at load time, reducing upgrade breakage. Tenant-scoped manifest visibility where deployed.
Infrastructure alignment
Traefik routing separates SPA catch-all from API, auth, and stream paths — preventing naive SPA routing from intercepting backend calls. BFF handles bundle proxy (same-origin ESM), manifest serving, and PDP-backed route authorization. All actions from plugins participate in the same event, policy, and audit patterns as API-driven flows.
Explore the connected platform
Connector & Tool Factory →
The tools and connectors that plugins consume through the BFF.
AuthZEN Authorization →
The PDP that authorizes every plugin route and API call.
Zero-Token SPAs →
The BFF pattern that keeps tokens out of the browser.
Zero-Trust OAuth Vault →
Credential security for the OAuth Vault plugin and all vault operations.
See the plugin platform in action
Watch us describe a plugin in natural language, scaffold it via MCP, deploy it with integrity hashes, and show it authorized by the same PDP that governs APIs and agents.