↓Skip to main content

Building a Multi-Server Management UI for FIDO Device Onboard (FDO)

·9 mins

A journey from single-server administration to comprehensive multi-server FDO management

Introduction #

FIDO Device Onboard (FDO) is revolutionizing how we securely onboard IoT devices at scale. However, as FDO deployments grow, organizations often find themselves managing multiple FDO servers across different roles - Manufacturers creating ownership vouchers, Rendezvous servers facilitating device discovery, and Owners managing device certificates and configurations.

We set out to build a web UI that could simplify this complexity, making it easy to manage multiple FDO servers from a single interface. This is the story of how we transformed a basic single-server administration tool into a comprehensive multi-server management platform.

The Challenge: Managing Multiple FDO Servers #

In real-world FDO deployments, you typically have three distinct server roles:

  • Manufacturer Servers: Generate and manage ownership vouchers for devices as they’re manufactured
  • Rendezvous Servers: Facilitate the initial connection between devices and their owners during onboarding
  • Owner Servers: Manage device certificates, voucher ownership, and final device configurations

Before this UI, administrators had to:

  • Keep track of multiple server URLs manually
  • Switch between different browser tabs or tools for each server
  • Remember which APIs each server role provides
  • Manually test connections to verify server health

We knew there had to be a better way.

The Vision: One UI, Many Servers #

Our goal was simple: create a single interface where you can manage all your FDO servers, regardless of their role or location.

Key requirements included:

  1. Support for all three FDO server roles
  2. Easy server switching with a single click
  3. Role-based navigation showing only relevant APIs
  4. Connection health monitoring
  5. Works standalone or as an OpenShift Console plugin
  6. Backward compatible with existing single-server deployments

The Journey: From Simple to Sophisticated #

Phase 1: Understanding the Landscape #

We started with a basic single-server UI that could:

  • Display ownership vouchers
  • Upload device CA certificates
  • Show rendezvous information

It worked well for simple deployments, but users with multiple servers found themselves juggling multiple browser windows and losing track of which server they were viewing.

Phase 2: Introducing Server Context #

The breakthrough came when we implemented a server context system. This allows the entire UI to “know” which server you’re currently working with and automatically configure all API calls to use that server.

The centerpiece is a server selector in the application header. With a single click, you can:

  • See all your configured servers at a glance
  • Switch between servers instantly
  • View each server’s role and connection status
  • Jump to server management

Server selector dropdown showing multiple servers with role badges and connection status

Phase 3: Smart Role-Based Navigation #

Different FDO server roles provide different APIs. A Manufacturer server has voucher and rendezvous info APIs, but doesn’t have the device CA API. An Owner server has everything except rendezvous info.

We implemented intelligent navigation that shows only the menu items relevant to the selected server’s role:

  • Manufacturer: Health, Vouchers, Rendezvous Info
  • Owner: Health, Vouchers, Device CAs, RV TO2 Addresses
  • Rendezvous: Health, Device CAs

No more confusion about which APIs are available on which servers - the UI tells you automatically.

Navigation menu showing role-specific APIs for Manufacturer server

Navigation adapts based on server role - here showing Manufacturer role with Vouchers and Rendezvous Info

Navigation menu showing role-specific APIs for Owner server

Same interface with Owner role selected - now showing Device CAs and RV TO2 Addresses instead

Phase 4: Server Management Made Easy #

We built a comprehensive server management interface where you can:

Add New Servers: Simply provide a name, URL, and role. The UI tests the connection automatically before saving.

Add server form with name, URL, role selection, and connection test button

View All Servers at a Glance: A table showing all your servers with:

  • Server name and URL
  • Role (with color-coded badges)
  • Connection status (healthy/unhealthy)
  • Quick actions (edit, test connection, delete)

Server management table showing all configured servers with roles, status, and actions

Test Connections: One-click health checks verify your servers are responding correctly.

Phase 5: Solving the Context Switching Problem #

Early testing revealed a subtle but critical issue: when users switched servers and tried to upload certificates, the files were still going to the original server!

This was our “aha” moment. We realized that every part of the UI needed to respect the server context - not just read operations, but uploads, edits, and deletes too.

We systematically updated every component that communicated with FDO servers to use the current server context. Now, everything - from viewing vouchers to uploading certificates - always uses the server you’ve selected.

Phase 6: Deployment Flexibility #

We designed the UI to work in two deployment modes:

Standalone Mode: Uses browser local storage to save your server configurations. Perfect for development or when running outside of OpenShift.

OpenShift Console Plugin Mode: Reads server configurations from Kubernetes Custom Resource Definitions (CRDs). Administrators can manage servers via kubectl or the OpenShift Console, and the UI automatically discovers them.

This flexibility means the UI works for everyone - from developers testing locally to production deployments on OpenShift.

Key Features #

Multi-Server Management #

  • Add, edit, and delete servers with an intuitive interface
  • Server selector in the application header for instant switching
  • Persistent server selection - the UI remembers which server you’re using
  • Connection health monitoring with real-time status indicators

Role-Based Interface #

  • Automatic API discovery - the UI adapts to each server’s role
  • Color-coded role badges (Manufacturer: Blue, Owner: Green, Rendezvous: Purple)
  • Dynamic navigation showing only available APIs
  • Role-aware operations - upload vouchers only to servers that support it

Ownership Voucher Management #

  • List all vouchers with GUID, protocol version, and rendezvous info
  • View voucher details including device information
  • Upload new vouchers with multi-file support
  • Update existing vouchers by replacing the PEM file
  • Delete vouchers with confirmation dialogs

Device CA Certificate Management #

  • View all device CA certificates with expiration dates and fingerprints
  • Upload certificates in bulk (PEM, CRT, CER formats)
  • Delete certificates safely with impact warnings
  • Certificate details showing full certificate information

Rendezvous Information Management #

  • Configure rendezvous endpoints for device discovery
  • Manage multiple RV entries per server
  • Edit and delete rendezvous configurations

RV TO2 Address Management #

  • Configure TO2 (Transfer Ownership 2) addresses for device handoff
  • Manage transport protocols and endpoint configurations
  • Edit and update TO2 settings as deployments evolve

User Experience Enhancements #

  • Real-time error handling with toast notifications
  • Connection alerts when servers become unavailable
  • Loading states with PatternFly skeleton loaders
  • Confirmation dialogs preventing accidental deletions
  • Multi-file upload with progress tracking
  • Empty states guiding users when no data exists

The Technology Stack #

We built this UI using modern web technologies optimized for enterprise applications:

  • React 18 for a responsive, component-based architecture
  • TypeScript for type safety and better developer experience
  • PatternFly 6 for enterprise-grade UI components and accessibility
  • OpenAPI Code Generation for type-safe API clients
  • Express.js Mock Server for local development and testing

The PatternFly design system was crucial - it provided:

  • Accessibility (WCAG 2.1 AA compliant) out of the box
  • Consistent UX patterns familiar to OpenShift users
  • Enterprise-quality components (tables, modals, forms, alerts)
  • Responsive design that works on any screen size

Real-World Impact #

This UI solves real problems for FDO administrators:

Before: “I have three FDO servers for testing, staging, and production. I keep a text file with URLs and have three browser windows open. When I upload vouchers, I sometimes forget which tab is which and upload to the wrong environment.”

After: “Now I have all three servers configured in the UI. The server selector shows me exactly which one I’m working with. The manufacturer badge is blue, so I know instantly I’m on the test server. I upload vouchers confidently knowing they’re going to the right place.”

Before: “Our rendezvous server doesn’t have the voucher API, but our old UI showed the voucher menu anyway. Clicking it just gave errors. Very confusing.”

After: “When I select our rendezvous server, the UI only shows Health and Device CAs - exactly what that server supports. The interface guides me to what I can actually do.”

Before: “We run on OpenShift and our security team manages FDO servers as CRDs. I had to ask them for URLs every time something changed.”

After: “The UI automatically discovers all FDO servers in our namespace. When the team adds a new server, it just appears in my server list. No configuration needed.”

Development Mock Server #

To make local development easy, we created a full-featured mock FDO server:

  • All FDO APIs implemented with realistic responses
  • File-based persistence - data survives server restarts
  • Isolated instances - each mock server gets its own data directory
  • Multi-server simulation - run multiple mocks on different ports
  • Pre-loaded sample data for immediate testing

Developers can start coding immediately with:

npm run start:dev:mock

This starts both the mock FDO server and the UI development server, ready to go.

Lessons Learned #

1. Context is Everything #

Building a truly context-aware application means every interaction must respect the current context. Missing even one operation (like we initially did with uploads) breaks the user experience.

2. Design for Flexibility #

Supporting multiple deployment modes (standalone and OpenShift plugin) from day one made the architecture more robust. The storage adapter pattern made this seamless.

3. Role-Based UIs Are Powerful #

Showing users only what’s relevant to their current context (server role) reduces cognitive load and prevents errors. Dynamic navigation based on server capabilities was a game-changer.

4. Test with Real Workflows #

The upload-to-wrong-server bug only appeared when testing realistic workflows - switching servers then immediately uploading. Automated tests caught compilation errors, but user testing caught UX issues.

5. Developer Experience Matters #

The mock server transformed development. Engineers can test multi-server scenarios locally without deploying real FDO servers. This accelerated development significantly.

What’s Next #

We’re continuing to enhance the UI based on user feedback:

  • Bulk operations: Select multiple vouchers or certificates for batch actions
  • Certificate expiration warnings: Proactive alerts for expiring device CAs
  • Search and filtering: Advanced filtering across all resource types
  • Export functionality: Download vouchers and certificates in various formats
  • Certificate chain visualization: Understand CA relationships at a glance
  • Audit logging: Track who made what changes when
  • RBAC integration: Fine-grained permissions for OpenShift deployments

Conclusion #

What started as a simple single-server UI evolved into a sophisticated multi-server management platform. By focusing on real user needs - managing multiple FDO servers across different roles - we created a tool that makes FDO administration faster, safer, and more intuitive.

The journey taught us that great UIs aren’t just about features - they’re about understanding user workflows and removing friction. Whether you’re managing two FDO servers or twenty, switching between them should be effortless. Whether you’re a manufacturer uploading vouchers or an owner managing device certificates, the interface should guide you to success.

We’re excited to see how the FDO community uses this UI to streamline their device onboarding workflows. If you’re working with FIDO Device Onboard, we’d love to hear about your experience and use cases.

Try It Yourself #

The UI is open source and ready to use:

  1. Clone the repository:

git clone https://github.com/mmartinv/go-fdo-server-ui-prototype
  1. Install dependencies:
npm install
  1. Start the mock server and UI:

npm run start:dev:mock
  1. Open your browser: Navigate to http://localhost:9000

Add your first server, explore the interface, and see how multi-server FDO management can be simple and intuitive.

Questions, feedback, or want to contribute? Open an issue or pull request on GitHub

About FIDO Device Onboard (FDO) #

FIDO Device Onboard is an automatic onboarding protocol for IoT devices developed by the FIDO Alliance. It enables devices to securely connect to their management platforms without pre-configured credentials, solving the “unboxing problem” for IoT at scale. Learn more at fidoalliance.org.