OmniPasskey combines a customer-facing management interface with Shibboleth sign-in so organizations can deliver secure, standards-based passkey enrollment and authentication without building the full workflow themselves.
What OmniPasskey includes
Self-Service
User registration and recovery
End users can register passkeys, view the passkeys attached to their account, and remove lost or retired credentials through a Shibboleth-protected web interface.
Authentication
IdP passkey sign-in
Shibboleth sign-in can use the passkeys that users register through My Account, including passwordless and MFA journeys configured by the organization.
Operations
Policy, analytics, and audit
Administrators and helpdesk operators use Manage Credentials, System Logs, and Dashboard for support and oversight. Administrators also set policy through Manage Rules and Manage Settings.
Deployment model
OmniPasskey combines a Shibboleth-protected management interface with a Shibboleth IdP plugin. Passkeys registered in the management interface are immediately available for sign-in.
Users register and manage passkeys through the OmniPasskey web application and authenticate through the Shibboleth IdP.
Apache, Shibboleth SP, the OmniPasskey frontend, and the registration server work together to deliver self-service, admin, and helpdesk experiences.
Passkeys, policy settings, device rules, and system activity stay consistent across registration, management, and sign-in.
The IdP plugin provides passkey authentication, optional username collection, optional inline registration, and MFA integration.
Shibboleth continues to provide the surrounding authentication and attribute framework while OmniPasskey adds passkey capability.
Follow the implementation path
Understand the product model
Review the deployment shape, user roles, credential lifecycle, and optional capabilities such as inline registration and usernameless sign-in.
Install the platform
Initialize the shared database, install the management interface with either the container or package path, then install the IdP plugin.
Align the configuration
Set hostnames, relying-party values, authorization rules, backend connectivity, branding, and IdP flow behavior so the deployment works end to end.
Prepare operational teams
Enable the right admin and helpdesk roles, tune passkey policies, and train operators on the daily management tasks available in the UI.
Who this guide is for
| Audience | Primary outcomes |
|---|---|
| Identity and access teams | Deploy the platform, connect it to Shibboleth, and keep authentication behavior aligned across the management app and the IdP. |
| Infrastructure and web teams | Provide Apache, Shibboleth SP, TLS, database connectivity, and the service boundaries required for secure customer-facing operation. |
| Operations and support teams | Handle passkey lifecycle management, user support, reporting, policy enforcement, and troubleshooting. |
Key capabilities
Built for customer operations
- Shibboleth-protected New Passkey, My Account, and My History experiences
- Manage Credentials, System Logs, and Dashboard views for administrators and helpdesk staff
- Global registration policy and per-device-type rules
- Optional inline registration after password authentication
- Shared data model for consistent registration and sign-in behavior
The examples in this site use app.example.edu for the management interface and idp.example.edu for the Shibboleth IdP. Replace those values with your production hostnames throughout your deployment.